In short: Whether your PHP package on Debian or Ubuntu is patched against PHP2Shell is shown by the exact package version, not by the PHP version. On 21 October 2026, Ubuntu published corrected packages for all supported releases, older ones via Ubuntu Pro. Debian has corrected php8.2 in bookworm and php8.4 in trixie. Compare the installed version with dpkg --compare-versions and then restart all PHP services.
The question behind the question
"Is my PHP package patched?" sounds like a yes-or-no question. In practice the answer depends on three things: which source does the package come from, which version is installed, and is that version actually running? This article answers the first two points for the official Debian and Ubuntu packages. How to check version and running processes in general is covered under Checking the PHP version and patch level properly.
We retrieved the information in the official Ubuntu security announcements and in the Debian Security Tracker on 25 October 2026. Both CVEs, CVE-2026-109618 and CVE-2026-109619, are listed there with the same corrected versions.
Corrected package versions on Ubuntu
Ubuntu published the fixes with two announcements. USN-8948-1 covers the current releases, USN-8948-2 the older ones that only receive security updates via Ubuntu Pro. For 16.04 and 14.04, Ubuntu additionally names the Legacy Support offering.
| Ubuntu release | Source package | Corrected version |
|---|---|---|
| 26.10 | php8.5 | 8.5.9-0ubuntu2.1 |
| 26.04 LTS | php8.5 | 8.5.4-0ubuntu1.5 |
| 24.04 LTS | php8.3 | 8.3.6-0ubuntu0.24.04.13 |
| 22.04 LTS | php8.1 | 8.1.2-1ubuntu2.28 |
| 20.04 LTS (Ubuntu Pro) | php7.4 | 7.4.3-4ubuntu2.29+esm5 |
| 18.04 LTS (Ubuntu Pro) | php7.2 | 7.2.24-0ubuntu0.18.04.17+esm14 |
It is striking that all versions keep the original PHP version. Ubuntu 24.04 stays at 8.3.6 even though the fix was taken from 8.3.36. Why this is so and how to deal with it is explained in the article Why php -v shows the same number. Affected are in each case, among others, the binary packages for FPM, CLI, CGI and the Apache module, such as php8.3-fpm and libapache2-mod-php8.3.
Corrected package versions on Debian
Debian takes a different route here and ships the new upstream versions. According to the Security Tracker, the status looks like this:
| Debian release | Source package | Previous version | Corrected version | Announcement |
|---|---|---|---|---|
| 12 bookworm | php8.2 | 8.2.32-1~deb12u1 | 8.2.35-1~deb12u1 | DLA-4848-1 |
| 13 trixie | php8.4 | 8.4.24-1~deb13u1 | 8.4.27-1~deb13u1 | DSA-6574-1 |
| forky, sid | php8.4 | 8.4.27-1 |
The announcement for bookworm appeared as a DLA, that is, via Debian LTS. For php8.2 in unstable, the tracker did not yet list a corrected version when retrieved. Anyone running test systems on unstable should keep an eye on this.
Older Debian releases do not appear in the two CVE entries when retrieved. If a server is still running such a release, for example Debian 11 with PHP 7.4, you cannot rely on a security update from the official archive. Three routes remain then: raising the operating system to a supported release, using a commercial long-term offering whose coverage for PHP2Shell you have confirmed in writing, or securing the server with interim measures until migration and restricting its reachability. In the long run only the first route is viable.
How to compare the installed version exactly
A glance at the version number is not enough, because Debian versions are sorted by their own rules. dpkg --compare-versions compares correctly. The following commands are purely read-only; adjust package names and target version to your release.
# Installed version and origin of the package
apt policy php8.3-fpm
# All installed PHP packages with version
dpkg-query -W -f='${Package}\t${Version}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null
# Exact comparison with the corrected version (example Ubuntu 24.04)
v=$(dpkg-query -W -f='${Version}' php8.3-fpm)
dpkg --compare-versions "$v" ge 8.3.6-0ubuntu0.24.04.13 && echo "korrigiert: $v" || echo "PRÜFEN: $v"
In the output of apt policy, look at the line with the package source. If it does not show your distribution's security archive but, for example, packages.sury.org or a PPA, the tables above do not apply. The version of that third-party source then counts, which we cover in the article The sury.org repository.
It is also worth looking into the changelog that ships with the package. How to find the CVE numbers there and record them as proof is described in the article Proving CVE numbers in the package changelog.
Typical pitfalls when checking
Only one package checked: PHP consists of many binary packages. If php8.3-cli is current but php8.3-fpm is not, the website stays open. Check all packages of a branch, especially FPM, CGI and the Apache module.
Package held: Packages that have been pinned with apt-mark hold stay put during the update. apt-mark showhold lists them.
Ubuntu Pro not active: On 20.04 and older, the fixes only arrive if Ubuntu Pro is set up. Without Pro, the system remains vulnerable despite an update run.
Outdated mirror: If the server fetches packages via an internal mirror or proxy, it only sees new security updates once that has been updated. If in doubt, check whether apt update actually reaches the security source.
Restart forgotten: New packages only take effect after the restart of all services that have loaded PHP. needrestart, if installed, shows services with outdated code.
A corrected package version only proves that the vulnerability is closed from now on. It does not answer whether the server was attacked beforehand. Preserve the logs from 20 October onward.
How does PHP SOS help?
- For every server, we determine the origin of all PHP packages and compare the version with the official announcements.
- We install updates, also via Ubuntu Pro, and restart all affected services.
- With the PHP patch service, you receive for each server a proof with package version, changelog hit and restart time.
- On systems with third-party sources or old versions, we clarify which route leads to a demonstrably corrected state.
Frequently asked questions
Which Ubuntu version contains the PHP2Shell fix?
According to USN-8948-1, Ubuntu 22.04, 24.04, 26.04 and 26.10 are supplied with regular updates. For 14.04, 16.04, 18.04 and 20.04, Ubuntu delivers the fixes via Ubuntu Pro according to USN-8948-2.
Why does Ubuntu 24.04 still show PHP 8.3.6?
Ubuntu adopts security fixes as a backport into the existing version. The upstream number stays 8.3.6; only the package version changes. According to USN-8948-1, the corrected version is 8.3.6-0ubuntu0.24.04.13.
Is Debian 12 bookworm still supplied?
Yes. According to the Debian Security Tracker, php8.2 in bookworm has the corrected version 8.2.35-1~deb12u1, announced as DLA-4848-1 under Debian LTS.
Does this also apply to PHP from the sury repository?
No. Packages from third-party sources such as sury.org have their own version levels and their own changelogs. The statements from Debian and Ubuntu apply only to their official packages.
Is an apt upgrade enough?
It installs the new packages, but running PHP-FPM or Apache processes keep the old code in memory. Only a restart of all services that load PHP makes the patch effective.