PHP2Shell on PHP 8.1, 8.0, 7.x and older

Old versions are affected, whatever the CVE records say

The machine-readable CVE records for CVE-2026-109618 and CVE-2026-109619 list only the 8.2 to 8.5 branches and mark everything else as unaffected. That is a statement about which branches the PHP project fixes, not about where the bug lives. A scanner or dashboard that reads the records literally will report a PHP 7.4 server as clean.

Everyone else says the opposite. The PHP project's advisory says PHP 8.1 and older no longer receive updates and directs their users to vendors or source backports. Wiz reports that every PHP version released in the last decade is affected by at least one of the issues, going back to 5.4, and Calif dates its earliest affected path to PHP 5.4.0. CERT-EU lists the end-of-life branches as affected; CERT.LV, CERT-FR and the Dutch NCSC say PHP 5 onwards. Treat every PHP version below the fixed releases as vulnerable.

What exists for each branch

The source backports are minimal by design

The PHP security team provided the backports, in its own words, to help people building from source or without access to a long-term support vendor. They are deliberately smaller than the fix in the supported branches. From our reading of the code, the backports stop the vulnerable out-of-memory jump by ending the worker outright, reset the request state that the attacks rely on, disable the session upload progress hook, and tighten the multipart header parser. They do not add the configurable hard memory limit of the supported releases.

• If you build PHP yourself, apply the backport for your branch, rebuild, deploy and restart every worker.
• Expect session upload progress to stop working, because the backport switches it off unconditionally.
• Treat the result as a stop-gap that buys time to migrate, not as a supported PHP.

Distribution packages

Most production PHP below 8.2 comes from a Linux distribution, not from php.net, and that is the best news on this page. The PHP project gave Linux distributions and long-term support vendors the patches in advance, and distributions routinely backport security fixes into the version they ship without changing the upstream version number. An Ubuntu or Debian package still called 8.1 can contain the fix.

• Look up CVE-2026-109618 and CVE-2026-109619 in your distribution's security tracker and compare the fixed package version with what you have installed.
• Install all pending security updates for the PHP packages, then restart Apache, PHP-FPM and every PHP worker.
• If the tracker says your distribution release is no longer supported, it will not get a fix. You are in the "nothing exists" case below.
• Several third-party builders went further than the PHP project: Ondřej Surý's Debian and Ubuntu packages, Remi's RPM repository for Enterprise Linux 8 to 10, cPanel's ea-php74 to ea-php81 and DirectAdmin all published fixes for end-of-life branches on 21 October, and Plesk, CloudLinux (alt-php 5.2 upwards) and Freexian's Extended LTS for Debian 9 to 11 followed by 22 October. Ubuntu Pro covers PHP back to Ubuntu 14.04. See the platform guide.

Where nothing exists: contain, then migrate

For a branch with no fix from any source, there is no configuration that makes it safe. The authorities agree on what to do: CERT.LV says systems that cannot be updated to a safe PHP version must not be publicly reachable until the risk is removed; CERT-FR advises isolating end-of-life PHP and then migrating; CISA advises taking systems on PHP 8.1 and earlier offline until they can be patched or updated.

• Remove public access. Put the application behind a VPN, an IP allow-list or authentication at a reverse proxy, so that unauthenticated requests never reach PHP.
• Apply the stop-gap settings from the mitigations guide in the meantime, knowing they cover only the demonstrated paths.
• Check whether it was already reached. An old, exposed PHP server is the likeliest place to find an intruder. See the detection guide.
• Plan the upgrade with a date. Moving an application from PHP 7 to 8 is real work; PHP2Shell is the reason to start it now rather than after the next flaw.

If PHP is inside a product you bought

Appliances, control panels, network devices and management interfaces often embed their own PHP that the administrator cannot update. The Dutch NCSC maintains a public, admittedly incomplete repository of third-party products potentially affected by PHP2Shell, which CERT-EU and the UK NCSC both recommend consulting. Ask each vendor for a firmware or package update that includes the fix, and restrict network access to the management interface until you have it.