PHP2Shell is fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Every earlier release back to PHP 5.4 is vulnerable. PHP 8.1 and older get no official fixed release — upgrade to a supported branch or use a vendor package with the backport. Distribution packages may carry the fix under an older version number.
On this page
Vulnerable and fixed PHP versions
| Branch | Vulnerable versions | First fixed release | Branch status (php.net) |
|---|---|---|---|
| 8.5 | 8.5.0 – 8.5.11 | 8.5.12 | Active support until 31 Dec 2027 |
| 8.4 | 8.4.0 – 8.4.26 | 8.4.27 | Active support until 31 Dec 2026 |
| 8.3 | 8.3.0 – 8.3.35 | 8.3.36 | Security fixes until 31 Dec 2027 |
| 8.2 | 8.2.0 – 8.2.34 | 8.2.35 | Security fixes until 31 Dec 2026 |
| 8.1 | all (up to 8.1.34) | no official release | End of life (31 Dec 2025) |
| 8.0 | all (up to 8.0.30) | no official release | End of life |
| 7.4 | all (up to 7.4.33) | no official release | End of life |
| 5.4 – 7.3 | all | none | End of life |
Any later patch release in a fixed branch (for example 8.3.37) also contains the fix.
Which version should I upgrade to?
- Already on 8.3, 8.4 or 8.5? Stay on your branch and install the latest patch release. That is the smallest, safest change.
- On 8.2? Install 8.2.35 now, but plan a move to 8.3 or newer: the 8.2 branch stops receiving security fixes on 31 December 2026.
- Choosing a target for an upgrade? PHP 8.4 or 8.5 give you the longest runway (security fixes until the end of 2028 and 2029). 8.3 is a conservative choice if your framework or plugins lag behind.
Distro backports: why an old number can be safe
Linux distributions freeze PHP at one upstream version for the life of a release and backport security fixes into it. Ubuntu 24.04, for example, ships PHP 8.3.6 — far below 8.3.36 — and fixes vulnerabilities by patching that 8.3.6 package. Its version string won’t change to 8.3.36.
So for packages from Ubuntu, Debian, RHEL, AlmaLinux, Rocky and similar distributions:
- A version below the cut-off is not automatically vulnerable — check the vendor advisory or package changelog for CVE-2026-109618 and CVE-2026-109619.
- A version above the cut-off is only trustworthy if it’s a real upstream build (official tarball, official Docker image, or a repository that tracks upstream releases).
How to check a package changelog.
End-of-life PHP
If you run PHP 8.1, 8.0, 7.4 or older, there is no official fixed release you can install. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1, aimed at people who already build PHP from source or depend on a long-term-support vendor. Google Cloud’s guidance is blunt: those versions should be upgraded to 8.2 or newer.
Your realistic options:
- Upgrade to a supported branch — the right answer for nearly everyone. Test your app on 8.3, 8.4 or 8.5 and switch.
- Use a vendor LTS package — some enterprise Linux distributions and commercial PHP LTS providers ship patched builds of older branches. Confirm the CVE IDs are listed as fixed.
- Build from source with the backport — only if you already maintain your own PHP builds and can keep doing so.
Shared hosting customers: switch your site to a newer PHP version in your control panel (it’s often a drop-down called Select PHP Version or MultiPHP Manager) — and ask your host to confirm their builds are patched.
How do I know if my host has patched?
Ask them directly and request the exact version or package release they’re running. A good answer looks like “we upgraded all servers to 8.3.36 and restarted PHP on 21 October”. Then confirm from your side using the steps in how to check your PHP version. Our WordPress guide includes a copy-paste email you can send.