PHP Patches Critical RCE Vulnerabilities, Organizations Urged to Take Unpatched Sites Offline

Organizations running internet-facing PHP applications have been advised to take them offline if they cannot immediately patch two critical vulnerabilities. That is how bad this is: the NSA recommended taking affected systems offline until they can be fully mitigated, while CERT-EU urged organizations unable to patch to consider isolating their applications from public networks.

The patches are now available. PHP released emergency updates on October 21, fixing flaws that can let attackers execute code on web servers without logging in. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

The vulnerabilities are collectively known as PHP2Shell, and like any major vuln it already has a vanity site. Behind the branding are two memory-safety flaws in the PHP engine, tracked as CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on the CVSS v4.0 scale.

Cloudflare reports that it has already observed attack traffic, including attackers modifying payloads to try to evade its protections. The scramble to patch is underway while attackers are testing their options.

Ahead of the release, security researcher Andrew Case summed up the concern: “Its basically impossible to overstate how bad this is going to be..”

Nearly Half of PHP Sites Run End-of-Life Versions#

PHP still runs an enormous amount of the web. W3Techs data for October 21 puts it at 69.3% of websites whose server-side programming language the service can identify. WordPress, Drupal, Joomla, and MediaWiki are among the applications built on it.

PHP 7 accounts for 27% of PHP websites, PHP 5 for 7.7%, and PHP 4 for 0.1%. That puts more than a third on branches older than PHP 8.

Even “we’re on PHP 8” is not much reassurance. Among PHP 8 sites, 15.2% use PHP 8.1 and 5.8% use PHP 8.0. Both have reached upstream end of life.

Combining those figures puts approximately 48.5% of PHP websites in W3Techs’ survey on branches that no longer receive routine security updates from the PHP project. That is a calculation from its major-version and PHP 8 subversion shares, not a count of confirmed vulnerable servers. Some installations receive security backports through their Linux distribution or a long-term-support vendor.

Still, nearly half is a grim starting point for an emergency patch rollout. For an older application, updating PHP can mean untangling compatibility problems that have been put off for years. Those problems do not get easier when the alternative is taking the site offline.

The attack can reach PHP before your application runs#

PHP’s advisory puts all installations serving web requests at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. Researchers identified affected paths reaching back to PHP 5.4.

The highest risk is Apache’s mod_php. PHP has confirmed an exploit in which an unauthenticated request triggers the attack before any application code executes. A carefully maintained application can therefore be exposed through the runtime underneath it.

The two flaws involve PHP mishandling memory when requests fail:

• CVE-2026-109618 involves out-of-memory errors interrupting work before internal data is fully initialized. During cleanup, PHP can then treat that unfinished data as valid.
• CVE-2026-109619 involves internal state surviving after the memory it references has been freed. A subsequent request handled by the same worker can use those stale references.

The exploitation requirements vary. PHP-FPM exits its worker after certain startup failures, blocking the demonstrated mod_php startup sequence. But researchers also confirmed a PHP-FPM code-execution path involving operations during application execution. Running FPM is not a reason to skip the update.

Wiz’s research also describes remote memory disclosure that can expose passwords, authentication tokens, API keys, and other secrets without first achieving code execution.

Researchers from Calif, OpenAI, and Wiz worked on the discoveries. Wiz says AI models helped turn complex, longstanding weaknesses into working exploits and adapt them across applications in hours. Calif’s account adds some useful history: a related issue had surfaced in a 2024 audit, but exploitation had not been proven. Knowing PHP’s older vulnerability history helped its researchers decide where to look.

The leak gave defenders an untidy head start#

The public warning began with an October 20 Hacker News post naming the two CVEs and claiming an October 22 disclosure date. Its evidence was, in the poster’s own words, “source: trust me, bro.”

The post also claimed a maximum 10.0 severity score. PHP’s official rating is 9.2. The initial leak exposed the existence of the flaws and their identifiers, rather than a technical explanation of how they worked.

PHP subsequently announced an October 21 release at 14:00 UTC, warning that it could publish sooner if technical details or evidence of active exploitation emerged. Administrators were left preparing for a critical update before the full advisory was available.

Cloudflare’s Dane Knecht said ahead of the release that initial WAF rules were available to all customers, including those on free plans, and that early attacks were emerging. He stressed that the rules are temporary: “This is a STOPGAP only.”

The fix has to reach the PHP runtime#

Updating WordPress, a plugin, or an application framework alone will not fix PHP2Shell. Administrators need to update the PHP runtime serving web requests, then restart the relevant services and long-running workers. Managed-hosting customers should confirm that their provider has applied the fix.

For older branches, check the distribution or support vendor for backported fixes. PHP has also taken the unusual step of publishing minimal source backports for PHP 7.4, 8.0, and 8.1. These are a route for people building from source, not a return to regular support for those branches.

PHP’s advisory includes temporary configuration changes, but warns that they only reduce exposure to particular attack paths. WAF protections buy time. A patched runtime is the only complete fix.

There is another deadline close behind this one: PHP 8.2 reaches end of life on December 31. Organizations patching that branch today have just over two months to move to a version that will keep receiving upstream security fixes.