PHP2Shell: Critical PHP RCE Vulnerabilities (CVE-2026-109618 & CVE-2026-109619)

On October 21, 2026, the PHP project shipped an emergency fix for two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619). We analyzed 6.7M of the world’s most-visited PHP sites to see how many sit in the blast radius. Shocker: 49% of all PHP sites are EOL.

We tracked patching for 24 hours after the release.

UPDATE: Our 24-hour follow-up is out. See the PHP2Shell patch status: 23% of PHP sites had been patched, while 77% were still running a vulnerable version.

What is php2shell (CVE-2026-109618 and CVE-2026-109619)?

On October 20, the PHP security team dropped notice of an emergency security release for Wednesday, October 21, 2026, at 14:00 UTC. Both flaws were rated CVSS 9.2 (out of 10). The pair is being tracked under the name of “php2shell” (CVE-2026-109618 and CVE-2026-109619).

PHP held back the full technical details, the exact affected versions, and the patched versions until the release itself. That embargo was deliberate: it gave defenders time to prepare without handing attackers a map. But it also started a countdown. Once a patch is public, its code change points straight at the bug, and attacks on unpatched servers usually follow within hours to days.

UPDATE: Less than 12 hours after the patch was released, millions of attempts have already been made to exploit the vulnerability, according to Matthew Prince, CEO of Cloudflare.

When was php2shell announced, and when was it fixed?

PHP announced the release on October 20, less than a day before it shipped.

Why is a PHP core flaw close to worst-case?

Remote code execution (RCE) means an attacker can run their own commands on your server without logging in (meaning, without any authentication). From there, the familiar outcomes follow: stolen data, web shells, ransomware, and a foothold to move deeper into the network. A CVSS score of 9.2 signals that this is reachable over the network, with no login and no user action, and that a successful attack means total compromise. It isn’t trivial to pull off (both CVEs are rated high attack complexity), but PHP says a demonstrated exploit already exists for mod_php.

What sets php2shell apart from the average CVE is where it lives. This is not a bug in one plugin or framework. It is in PHP itself, the runtime beneath roughly three-quarters of all websites whose server-side language is known.

Which PHP versions got a fix?

PHP’s supported branches, 8.2 through 8.5, received a fix. Everything older, 8.1 and down, is EOL and gets no regular update from the PHP project. Given the severity, PHP’s security team published minimal source backports for PHP 7.4, 8.0 and 8.1, aimed at people who build PHP from source or have no LTS vendor. Some distributions and LTS vendors, like CloudLinux, provide backported fixes. Note: Many servers can easily be ported to CloudLinux.

UPDATE: CloudLinux has released patched builds of its PHP versions, including EOL branches such as 7.4 and 8.0 (alt-php for CloudLinux 6 is not confirmed yet).

How many PHP sites are exposed? Our October 20 measurement (the day before the patch)

To size the problem, we analyzed the top 6.7M PHP websites. We identified PHP sites by their technology fingerprints and, where the server advertised it, read the PHP version from the response.

Among sites that reveal a version, the most common are PHP 8.3 (23%), 7.4 (20%), 8.2 (16%), 8.1 (9%), and 8.4 (9%). PHP 7.4 (EOL since 2022) is the second most common version on the web, and PHP 7.x and older together form the single largest group at about 34%.

One caveat: About 70% of sites do not advertise their version, so version-level findings describe the roughly 30% that do.

How big is the patching gap?

Among sites that do reveal their version, the split is nearly even: a little over half run a supported branch (which has a patch), and just under half run an EOL branch that doesn’t get a regular patch. Given the size of this vulnerability, we wouldn’t be surprised (but don’t count on it) if PHP decides to publish patches for older versions of PHP.

UPDATE: PHP did, in part. Its security team released source-only patches for 7.4, 8.0 and 8.1, for people who build PHP themselves.

When you project that version-share pattern onto the roughly 70% that do hide their version, the picture is sobering. On the order of 3.2 million of these top sites appear to run an EOL version of PHP! Their only real options are to upgrade, or to put compensating controls such as a web application firewall in front of the application. We imagine WAF providers like Cloudflare will also implement rules to protect their orange-clouded customers.

Cloudflare’s CTO, Dane Knecht, announced on October 20, 2026, on X that they’ll have this covered.

The several million sites on supported branches are not safe on day one either; they are simply the group that has a patch available. Whether they are actually protected comes down to how fast they apply it, which is the number we tracked after the release. See how fast PHP sites patched in the first 24 hours.

What should you do after the PHP security release?

Update PHP first. If you can’t update right away, PHP’s security advisory lists temporary mitigations that reduce exposure but don’t make a server safe. One of them, for CVE-2026-109619 only, is setting the following in your php.ini (not in .user.ini or with ini_set(), which PHP says won’t work):

session.upload_progress.enabled = Off

Restart every PHP worker after the change. On October 23, PHP suggested leaving this setting off until its next regular bugfix release, to block a separate, unlikely RCE path (CVE-2026-115560).

On cPanel servers, you can find your php.ini file at:

/opt/cpanel/ea-phpNN/root/etc/php.ini

Replace NN with your cPanel PHP version, e.g., /opt/cpanel/ea-php74/root/etc/php.ini

You may also want to update your cPanel bundled PHP as well:

/usr/local/cpanel/3rdparty/php/NN/etc/php.ini
Replace NN with your cPanel bundled PHP, e.g., /usr/local/cpanel/3rdparty/php/84/etc/php.ini

• Find out what you run. If you’re running cPanel, you can find your php.ini files using this command: locate php.ini | grep /opt/cpanel
• Stop advertising your version. Set expose_php = Off so your server stops volunteering its version in response headers. It is not a fix, but it removes an easy targeting signal.
• Assume probing has already started. Make sure logging and alerting are on so you can spot exploitation attempts.

How do you find every PHP version you run?

The hardest part of php2shell will not be applying the patch. It will be knowing which of your sites, subdomains, and half-forgotten staging servers still run an exposed or EOL PHP version in the first place.

Want to know where php2shell leaves you and where your data is being transmitted? See your exposure at MELURNA.

FAQs