PHP2Shell fixed versions: every PHP branch, one table

The PHP2Shell fixes are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, for CVE-2026-109618 and CVE-2026-109619. Any php.net build below the fixed number on its branch is affected. PHP 8.1 and older have no php.net release. If your PHP is not on a fixed number, ask your host or update the package, then restart the PHP workers.

Which PHP versions are affected, branch by branch?

Both GHSA records list the same affected ranges: below 8.2.35, below 8.3.36, below 8.4.27 and below 8.5.12. The table puts every branch in one place, with what the PHP project and the vendors said at our check on 24 October 2026.

Sources for the table: the PHP notices for every row except the 7.3 and older row, which is watchTowr's reading. The UK NCSC says organisations using any version of PHP are affected and tells owners of older versions to move to a supported release. The PHP changelog dates 8.5.12 and 8.4.27 to 22 October 2026, a day after the advisory.

Can a fixed package show an old version?

The version table above is for php.net builds. Distributions, control panels and hosts rebuild PHP and often keep the old branch number. Two examples from the vendors' own pages:

• Ubuntu 22.04's fixed PHP package is 8.1.2-1ubuntu2.28. It is a backport on the 8.1 branch.
• CloudLinux's first fixed ea-php83 build was 8.3.35-2, a number below 8.3.36 that already carried the fix. Its php.net-numbered 8.3.36-1 builds followed on 23 October.

So a version below the table can be fixed, and a version in the table's affected range is not proof of exposure either. Check the package changelog for both CVE ids; how the distro backport trap works has the Ubuntu and Debian detail. CloudLinux says its rebased native PHP 8.2 and 8.3 changelogs name no CVE ids, so there you check that the version is 8.2.35 or 8.3.36 or later (page read 24 October 2026). See the host-side detail for the other two traps: the command-line php -v is often a different binary from the web PHP, and a panel selector shows a branch, not a build.

What do the Linux distributions ship?

At our check on 24 October 2026. These rows move, so open the linked page before you act.

Debian's tracker listed php8.2 in unstable as unfixed when we checked. Debian 12 and 13 are the fixed rows above.

How do I fix it?

What do I do if a host manages PHP for me?

Send support this and keep the reply:

For [your domain], which PHP build serves web requests, and is it fixed for CVE-2026-109618 and CVE-2026-109619? Please give the package or build identifier, confirm that every PHP-FPM, CGI or Apache worker for my domain was restarted after the fix was installed, and tell me if I must change the PHP version setting or redeploy.

• Ask the question above and keep the written reply.
• If you are on 8.1 or older, ask whether the host backported the fix, and what the plan is to move you (what to do on end-of-life PHP).
• If the host has no answer yet, "nothing published" means ask again. It does not mean fixed or unfixed.

What do I do if I manage the server myself?

• Take the fixed package from your distribution, or build a fixed release, for the branch you run.
• Restart PHP-FPM, or Apache if you use mod_php, so no old worker keeps serving (restart steps after the update).
• Rebuild and redeploy any container image that bundles PHP. A fixed base image does nothing until your image is rebuilt from it.
• Check each virtual host, because one server can run several PHP versions.
• If you cannot patch today, the PHP project lists interim mitigations per CVE and says updating is the only complete solution. The PHP notice has them. Restrict access or take the site offline if you cannot apply them.

Longer walkthroughs: fix and patch the PHP runtime.

Am I affected? A three-state self-test

Our checker page says what an outside check can and cannot confirm.

Was it exploited before the fix?

Amazon Threat Intelligence reported a honeypot attempt on 17 October 2026, four days before disclosure, and more activity on 21 October. AWS says it is unclear whether the attempts would have worked on real systems. The exploitation page tracks this with dates.

If your PHP was exposed between 17 October and your fix, look for PHP files you did not add, new scheduled tasks and new administrator accounts. Updating PHP does not remove anything planted earlier. The UK NCSC advises checking for compromise if you cannot update at once.

What is the bug, without the exploit?

The PHP security advisory of 21 October 2026 describes two flaws. CVE-2026-109618 is remote code execution through out-of-memory handling: PHP can be interrupted while internal request data is only partly initialised, and request cleanup may then treat that data as valid. CVE-2026-109619 is remote code execution through stale global state: request-owned internal state can survive after its memory is freed, and a later request handled by the same worker may use it. The two CVEs explained in plain terms go further. The advisory says both can allow unauthenticated remote code execution, and that the risk is highest for mod_php, where an exploit was demonstrated in which an unauthenticated request triggers the attack before any application code runs. We do not reproduce exploit material. You do not need it to fix a site.

On 23 October the PHP project posted an informational advisory on session upload progress for CVE-2026-115560. It says the issue needs an unusual configuration and application code, suggests setting session.upload_progress.enabled=0 until the next regular bugfix release, and promises a full advisory with that release. It names no fixed version. We will add a row here when it does.

If you run WordPress, why a WordPress update is not enough is on its own page, and the other PHP2Shell guides cover hosts and containers. All the incidents of the month are on the October 2026 tracker.