PHP on Linux: which version fixes what

What it is, and why it is on your server

PHP powers WordPress, Magento, Laravel and most of the shared-hosting web. Distributions ship a specific branch per release: Ubuntu 22.04 has 8.1, Ubuntu 24.04 has 8.3, Debian 12 has 8.2, and the source package name is stamped with the branch.

Why its advisories behave the way they do

• End of life is the finding. Each PHP branch gets two years of bug fixes and one more of security fixes. After that there are no advisories, which reads on a scanner as "no known vulnerabilities" and means the opposite.
• Your distribution and php.net disagree about support. Ubuntu 22.04 keeps patching 8.1 past its upstream end of life, because the LTS promise covers it. The same version number is supported on one system and abandoned on another.
• Multiple versions coexist. A server with a panel often has three PHP branches installed at once and different sites pointed at different ones. Patching the default does nothing for a site pinned to an older branch.

Check what you are actually running

The version that matters is the package version, not the upstream one. Distributions backport security fixes without changing the number before the dash, so a release that looks years old is frequently fully patched, and the revision after the dash is the only part that tells you.

dpkg-query -W -f='${Package} ${Version}\n' php8.3-cli php8.2-cli php8.1-cli 2>/dev/null

rpm -q php-cli

Run `php -v` for the default branch, and on a panel host check each site separately: the default is rarely what the sites are using.

Fixed versions, per distribution

Each distribution patches on its own schedule and under its own version scheme, so the same CVE has a different answer on each of them. These come from the distributions’ own advisory data, asked per release. Where a release has no fixed version, that is what the advisory says, not a gap in the data.

Advisory data last refreshed 26 September 2026. It is re-read daily.

What this page does not tell you

It does not tell you whether your server is affected. A CVE applying to a package is not the same as a CVE applying to your installation: the fix may already be backported into what you are running, the vulnerable module may not be loaded, or the service may not be reachable from anywhere that matters. Answering that needs the versions on your machine, not a list.

It also carries no count of how many servers are affected. SecAI monitors a small fleet, and a percentage drawn from it would be arithmetic on a sample too small to mean anything. When that changes, the number will appear here and the page will say when it started.

Read next