PHP2Shell patch tracker: fixed versions

The short answer

Both PHP2Shell vulnerabilities are fixed in four upstream releases, all published on 21 October 2026:

The coordinated disclosure says affected releases date back to PHP 5.4; every branch from 8.1 down is past upstream support. That makes the version table a starting point, not an inventory of every runtime in an estate: check the web SAPI, CLI, cron jobs and embedded PHP separately. For the older branches, see the backport guidance.

Windows packages were reissued on 26 October 2026 as 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1, bundling Brotli 1.2.1 for the separate CVE-2026-111497. If you downloaded a Windows build before that date, check which package you have.

Installing the release is not the end of the job. Every PHP worker that served requests before the update has to be replaced, and the runtime that actually answers HTTP requests has to be checked.

What “fixed” means in these releases

The 8.x changelog attributes both issues to the same pair of advisories:

• GHSA-w8hw-w9fx-j79w — CVE-2026-109618, RCE via OOM corruption.
• GHSA-6wmf-4rv5-p3rp — CVE-2026-109619, RCE via stale global state.

All four releases contain the Core fix described as “Avoid state corruption via bailout”. They also contain unrelated bug fixes; do not read a patch release as containing only PHP2Shell changes.

Version strings that mislead

A version number is evidence about a package, not proof about the process serving traffic.

• Distribution backports. Debian, Ubuntu, RHEL, Alpine and LTS vendors may keep an older visible version while shipping the fix in a package revision. Check the vendor changelog or advisory, not only php -v.
• CLI versus web SAPI. php -v reports the CLI binary. Your site may be served by PHP-FPM, Apache mod_php, php-cgi, FrankenPHP or LiteSpeed, each with its own package and restart path.
• Containers. Rebuilding an image does not replace a container that is still running the old layer. Redeploy and confirm the new image ID.
• Multiple runtimes. A host can run several PHP versions for different sites, panels or cron jobs. Patch and verify each one.
• Managed hosting. Ask for the exact package version and restart evidence in writing. A control-panel version selector is not proof that the fix is active.

Distribution backports and appliance builds are where the version string most often diverges. The separate PHP2Shell affected and fixed versions reference lists them alongside the upstream releases.

The verification guide covers how to find the serving SAPI and check the package behind it.

Restart is part of the fix

Old workers keep the old binary in memory. The restart step depends on the SAPI:

1. PHP-FPM: restart the FPM service or the specific pool, then confirm new worker PIDs and a cleared OPcache.
2. Apache with mod_php: restart Apache; a graceful reload may leave old children serving requests.
3. Containers: replace the container or pod; do not patch inside a running container that will be recreated from an old image.
4. Rolling deployments: drain old workers before removing them, then confirm the replacement workers report the fixed build.

If you cannot establish that every worker restarted, treat the host as still exposed.

What this tracker does not cover

CVE-2026-115560 is separate. It concerns session upload progress and still has no named fixed release as of 30 October 2026. PHP’s interim control is session.upload_progress.enabled=0 where the narrow configuration applies. The PHP2Shell releases above do not fix it. See the CVE-2026-115560 record.

Interim controls are not a patch. Disabling upload progress or adding WAF rules can reduce exposure, but they do not replace a fixed runtime. The mitigation guide explains the limits.

KEV status is not a victim count. CISA lists both CVEs in KEV catalog 2026.10.29, added on 26 October with a federal remediation deadline of 29 October. The listing records known exploitation; it does not publish a victim count.

How to fix PHP2Shell

This is the shortest reliable sequence. The checker gives a quick version answer; the EOL and backport guide covers PHP 8.1 and older.

1. Inventory every PHP runtime: web SAPI, CLI, cron, admin panels and embedded or appliance PHP.
2. Patch to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or to a vendor package confirmed to contain the fix.
3. Restart every worker and clear OPcache.
4. Verify the process, binary and package that serve requests — not just the control panel.
5. If a host was exposed while unpatched, preserve logs and rotate secrets before rebuilding.
6. Record the package version, restart time and verification output for the incident log.

The PHP2Shell dossier keeps the CVE scope, source links and exploitation status together. The response checklist covers the wider incident sequence.