In short: If php -v shows the same version after the update, this is usually down to a backport: the distribution adopts only the security fix into its existing PHP version, and the number stays the same. Ubuntu 24.04 thus continues to report 8.3.6 even though the package is corrected against PHP2Shell. Settle the question via package version and changelog, and additionally check whether the website is really running with the new code.
A typical moment after PHP2Shell
The admin has installed the update, everything without errors. To check, they type php -v and see the same version as before. Did the update not work? Is the server still open? This question has been among the most common since 21 October 2026.
The good news: in most cases everything is fine. The bad news: there are also cases in which the same number really does indicate a problem. This article helps to tell the two apart.
Why distributions do not change the number
Enterprise and LTS distributions promise stability. Within a release, behaviour and interfaces are supposed to change as little as possible. A jump from PHP 8.3.6 to 8.3.36 would, however, bring numerous bug fixes and small behaviour changes that could disrupt applications.
That is why many package maintainers adopt only the specific security fix into their existing version. This process is called a backport. The upstream version, which PHP itself reports via php -v, stays the same. What changes is the package version assigned by the distribution.
Taking Ubuntu 24.04 as an example, it looks like this: PHP reports 8.3.6. The corrected package version, however, is 8.3.6-0ubuntu0.24.04.13 according to USN-8948-1. The latter part is what counts. With PHP2Shell, Debian decided differently and shipped the new upstream versions 8.2.35 and 8.4.27 for bookworm and trixie. The overview per release is in the article Debian and Ubuntu: Is my PHP package patched?.
It is worth taking such a package version apart once. Taking 8.3.6-0ubuntu0.24.04.13 as an example: the part before the hyphen is the upstream version, that is, what PHP itself reports. After it follows the distribution's revision. ubuntu0.24.04 refers to the release, and the last number counts the revisions. Every security fix raises this number. With Ubuntu Pro, an addition such as +esm5 appears as well, with Debian security updates one such as ~deb12u1. Anyone who can read these parts can see at a glance whether a package was changed after a security announcement.
Where the old number shows up everywhere
The unchanged number does not appear only in php -v. It also appears in places that are visible from outside or are evaluated by tools:
| Place | What it shows | Consequence |
|---|---|---|
php -v and php -i |
upstream version, build date | admins doubt the update |
| phpinfo page | upstream version | same effect in the browser |
X-Powered-By header |
upstream version, if expose_php is on |
external scanners report a vulnerability |
| Hosting panels such as Plesk | upstream version | display such as 8.2.34 despite the patch |
| Vulnerability scanners | comparison by number | false alarm with backports |
External scanners are a case of their own. Anyone who uses them may get findings after PHP2Shell for servers that were corrected long ago. Do not ignore these findings across the board; instead, prove the package version for each server and mark the finding as checked. Another reason to hide version information from outside is given in the article expose_php and server headers.
When the same number is a warning sign
There are three situations in which the unchanged number actually points to a problem:
- The package source supplies the upstream version. If PHP comes from a source that normally ships the current upstream version, such as Debian with PHP2Shell or third-party sources such as Remi and sury.org, 8.5.12, 8.4.27, 8.3.36 or 8.2.35 should appear after the update. If the old number is still shown, the package was not updated.
- You are checking the wrong installation.
php -vshows the command line. If the website runs via a different version, for example from a hosting panel or a software collection, the output says nothing about the website. - The package version has not changed. If the package version is also the same as before the update, the update did not arrive for this package, for example because it was held or the source is missing.
For non-technical readers it can be summarised like this: the version number describes the model, the package version the maintenance status. Two servers with the same PHP version can differ considerably in security. So do not ask your IT or service provider about the version, but about the proof of the patch.
How to settle the question in five minutes
The following commands are purely read-only. The examples assume Ubuntu or Debian and PHP 8.3; on RHEL systems, use rpm -q instead of dpkg-query.
# 1. What does PHP itself report, including the build date?
php -v
# 2. Which package version is installed, from which source?
apt policy php8.3-fpm
# 3. Does the changelog contain the CVE numbers?
apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961[89]"
# 4. Since when have the website's PHP processes been running?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
The build date in the output of php -v is an indication but not proof. Reliable proof comes from the changelog entry. How to find and record it if it is worded differently or missing is described in the article Proving CVE numbers in the package changelog.
After every check, note both numbers: the upstream version from php -v and the package version. Anyone who later asks why the server "still has 8.3.6" then gets a clear answer.
The general check via version, package and processes is summarised on the page Checking the PHP version and patch level properly.
How does PHP SOS help?
- For every server, we clarify whether an unchanged version number is a backport or a missing update.
- We assess findings from vulnerability scanners and document false alarms with package version and changelog.
- We check which PHP installation the website actually uses and whether its processes have been restarted.
- In the PHP patch service, we document upstream version and package version side by side.
Frequently asked questions
Is my server unpatched if php -v shows the old number?
Not necessarily. Many distributions adopt fixes as a backport into the existing version. Ubuntu 24.04, for example, still shows 8.3.6 even though the package is corrected according to USN-8948-1. What matters are the package version and the changelog.
Why does my security scanner report a vulnerability despite the update?
Many scanners only read the version number, for example from the X-Powered-By header. With backports this leads to false alarms. Check the package version and document the result instead of simply ignoring the finding.
Can php -v show a new number while the website does not?
Yes. php -v shows the command line. The website can run via a different installation or via processes that were started before the update. So also check the FPM service or Apache and their start time.
Does the build date in the output of php -v help?
It is an indication but not proof. A build date after 21 October 2026 fits a corrected package but does not prove that the fix is included. The changelog entry is the better evidence.