The short answer
PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 are the upstream PHP2Shell fixes. PHP 8.1 and older have no upstream release. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1, and distributions or LTS vendors may ship their own fixes.
A source backport is not automatically a package you can install. It is patch material for a vendor. If you run an older branch, the question is not “does version 7.4.33 contain the fix?” It is “does the exact package build I have contain both fixes, and has the serving worker been restarted?”
What PHP actually published
The 21 October advisory says PHP 8.1 and older no longer receive updates from the PHP project. It also says the security team provided minimal source backports for 7.4, 8.0 and 8.1 because of the severity, and that distributions and LTS vendors may provide their own backports.
Those statements describe two different paths:
- Vendor package: a distribution or commercial LTS vendor rebuilds PHP with the fix and publishes a package revision.
- Source backport: patch material for a vendor or an organisation that builds its own PHP.
Neither path creates a new upstream release, and neither guarantees that a public binary exists for your operating system.
Why the version string can stay the same
Backporting usually keeps the upstream version number so that applications do not see an unexpected minor-version change. A package may report 7.4.33-2 or 8.1.31-1ubuntu1 while containing the security fix. The visible version alone cannot prove or disprove coverage.
Check the package changelog or vendor advisory for references to:
- CVE-2026-109618 and CVE-2026-109619;
- GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp;
- the package revision and build date.
If the vendor advisory does not name both records, do not assume the package is fixed.
How to verify a vendor package
- Record the exact package version, revision and build date from the package manager.
- Find the vendor’s advisory or changelog entry for that revision.
- Confirm it names both PHP2Shell advisories, not only one.
- Check that the package is the one used by the web SAPI, not a CLI-only build.
- Restart every PHP worker and clear OPcache.
- Verify the running process, not only the package database.
A distribution backport can be correct and still be inactive because an old FPM master or container layer is serving requests. The patch tracker covers the restart and verification sequence.
PHP 5.x, 7.x and 8.0
PHP 5.x, 7.x and 8.0 are past upstream support. The 7.4 and 8.0 source backports are for vendors and downstream builders; they are not a reason to keep an unsupported branch in production. PHP 8.1 is also past upstream support.
An unsupported branch will not receive future security fixes, including fixes for the separate CVE-2026-115560 session-upload issue. Use the backport as a bridge while you plan an upgrade to 8.2, 8.3, 8.4 or 8.5.
What to do now
- Ask the vendor for a package that explicitly references both PHP2Shell CVEs and the package revision.
- Test the package on a copy of the runtime, including the web SAPI and any long-running workers.
- Restart and verify the serving process.
- Put an upgrade to a supported branch on a dated plan. “Vendor backport” is a temporary support path, not a permanent substitute for an upgrade.
The verification guide shows how to identify the SAPI and package. The dossier keeps the CVE scope and evidence boundaries together.
Sources for this page
- Full text read
- Full text read
- Full text read
- Full text read
Revision history
| Time (UTC) | Recorded change |
|---|---|
| 30 October 2026, 14:45 UTC | Initial page for the end-of-life branches, based on the PHP advisory and coordinated disclosure. |
| 30 October 2026, 14:45 UTC | Current published version. |
Commands and configuration examples are illustrative. Confirm package names, service names and directive scope against your own platform and PHP version. This guide is not a substitute for the vendor advisory.