Most web vulnerabilities live in a plugin, a framework or one badly written application. The pair of bugs now called PHP2Shell sit lower down, in the PHP engine itself. PHP is the interpreter behind a large share of the web's content management systems, storefronts and admin panels. This week the PHP project shipped emergency fixes for CVE-2026-109618 and CVE-2026-109619. Both are memory-handling flaws that, according to their National Vulnerability Database records, can end in remote code execution (RCE): an attacker running their own code on the server.

The php.net changelog now carries a banner that is rare for the project: "Security advisory: Critical remote code execution vulnerabilities, update now." CyberScoop reports that each flaw is rated 9.2 on the CVSS version 4.0 severity scale, which tops out at 10 and puts both firmly in the critical band.

What actually broke

Both bugs come from how PHP handles request memory when something goes wrong. The NVD records were filed by [email protected] and published October 21; we read them through the NVD API. They describe two related failures:

  • CVE-2026-109618 involves PHP's out-of-memory handling. When the engine runs out of memory it uses longjmp(), a low-level C mechanism that jumps straight out of the current code path, to abort the request. The record says some contexts can leave request memory uninitialized before an allocation. The cleanup routine that follows may then read or branch on that memory, and the record says multiple out-of-memory strategies can consistently trigger the condition and lead to code execution.
  • CVE-2026-109619 is a stale-state problem. Global state that temporarily points into request memory may not be correctly reset, or may be repopulated after being reset, so it can refer to memory that has already been freed. NVD says subsequent requests may read or branch on that stale state before it is fully initialized, and that this, too, can lead to RCE.

The php.net changelog lists both fixes, tracked as GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, under one phrase: "Avoid state corruption via bailout." Put simply, the engine's emergency exit was leaving things in a state an attacker could take advantage of.

The second bug is worth singling out because, per the NVD description, the stale state is read by subsequent requests. PHP's memory model assumes each request starts with a clean slate, so a flaw that lets one request's leftovers reach the next cuts against the isolation that shared hosting and multi-tenant platforms rely on. That implication is our reading of the record, not a claim the sources make.

How big is the blast radius?

It is very large. Krebs on Security reports that nearly 70 percent of websites need to update their core software to fix the pair of bugs. Krebs cites Censys counts of roughly 2.58 million internet-facing hosts and 54.9 million web properties running PHP. Wiz told Krebs that every PHP version released in the last decade is affected by at least one of the vulnerabilities. CyberScoop reports that CERT-EU's advisory says the flaws could affect every version of PHP from 5 onward.

Other measurements point the same way. The Record cites a VirusTotal analysis showing 5.1 million IP addresses running PHP, of which at least 758,000 are on end-of-life versions. The Record stresses these figures show PHP's internet-facing footprint, not confirmed vulnerable systems. The end-of-life hosts matter most, because the patches cover only PHP 8.2 and newer, and older versions no longer receive updates from the PHP project. The Record also reports Cisco Talos estimates that roughly 50% of vulnerable PHP systems may not receive a patch.

The disruption has already started. Krebs, citing Reuters, reports that government websites in Europe and elsewhere went offline after the vulnerabilities were disclosed. Krebs's headline warns of many site outages as organizations update.

Is anyone exploiting it?

The sources describe a mixed picture, so here is the evidence as each one gave it:

  • Cloudflare told Krebs it has detected some exploitation of the flaws, and said it deployed web application firewall (WAF) rules at 03:02 UTC. The Record likewise reports Cloudflare seeing attempted exploitation. Krebs also writes that experts say working exploits exist and that the bugs are already being exploited in the wild.
  • CISA, in a release quoted by CyberScoop, said it had not observed exploitation of the vulnerabilities at the time of publication.
  • Fastly and Huntress told CyberScoop that what they saw was mostly reconnaissance, meaning probing for vulnerable systems. Huntress said it had not observed or independently confirmed successful in-the-wild exploitation on live customer systems. Fastly's Kelly Shortridge said the gap between disclosure and widespread, repeatable exploitation is typically hours to a few days for flaws of this severity.

Treat reconnaissance as a warning, not a reprieve. With a target this large, defenders should assume probing will turn into real exploitation attempts quickly. Public exploit code is circulating, but CyberScoop notes it has not been verified and that such code is sometimes laced with malware, so do not run it to test your own servers.

The release timing was unusual as well. CyberScoop reports that PHP moved the release up a day, ahead of a coordinated embargo that was meant to lift on Thursday. The Record adds that details leaked first, and the PHP Foundation said Chainguard published images containing the fix early on Wednesday; Chainguard's CEO told The Record he made that judgment call after seeing exploitation attempts.

A bug that was flagged, then stalled

The Record's account of how the flaws came to light is uncomfortable reading. The PHP Foundation said the problem drew serious attention in August after outside reviews using AI tools, and that from August 11 onward fixing it became the top priority for its security team. The Record reports that a researcher at Calif was credited with initially discovering the vulnerability and developing an exploit, and that OpenAI, Wiz and Trail of Bits also found the same bugs. Krebs likewise reports that Wiz worked with the PHP team, Calif and OpenAI on the response.

The PHP Foundation also said CVE-2026-109618 traces back to a 2024 external security audit, but officials took no action at the time. The Foundation said engineers struggled to choose between fixes that risked backward-compatibility breaks, new denial-of-service potential or changes to many third-party extensions, and that work stalled and restarted repeatedly over months.

That is a familiar story in open source. A finding goes into an audit report and the fix stalls on hard trade-offs. It is a reminder that "audited" does not mean "remediated."

The appliance problem: Palo Alto, Fortinet, Cisco

PHP also turns up inside vendor products, and the vendors are now working out which of theirs are exposed. Help Net Security collected the vendor positions:

  • Palo Alto Networks confirmed that all versions of PAN-OS and Panorama are affected and has not yet shipped fixed releases. The company says risk is highest where a management interface accepts connections from the internet. It rates the issue lower than the 9.2 base score (CVSS-B 8.7), because its scoring counts an availability impact only, and says it is not aware of malicious exploitation against its products.
  • Fortinet is investigating 12 products and has confirmed 12 others, including FortiOS, are not impacted. Separately, FortiGuard Labs says it released virtual patches for both CVEs in signature version 37.316, aimed at PHP servers in general. Fortinet's advisory lists no fixed versions or workarounds for the products still under review.
  • Cisco is investigating 18 products and 13 cloud services, lists none as confirmed vulnerable so far, and says there are no workarounds. Cisco's PSIRT says it is not aware of any malicious use of the vulnerabilities.

Fixes for embedded PHP depend on the vendor, so for these products the main defense in the meantime is controlling exposure.

What It Means for Defenders

Who is affected: anyone running PHP below the fixed releases. The NVD records list 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. The php.net changelog dates all four fixed releases October 22. Per Wiz and CERT-EU as reported by Krebs and CyberScoop, older and end-of-life branches should be treated as vulnerable too, and they will not get fixes from the project.

Patch now to one of these versions:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

If you're on PHP 8.1 or older: the PHP project is not patching those branches. Look for backported fixes from your operating system vendor or plan a migration to a supported branch. Until then, reduce exposure: put the site behind a WAF that has the new rules (Cloudflare has deployed them), restrict access where you can, and give these hosts priority for monitoring.

Don't forget indirect PHP: hosting control panels, bundled vendor software, container base images and distro packages all carry their own PHP builds. Inventory them and confirm the actual PHP version, not just the application version.

Network appliances:

  • Palo Alto PAN-OS/Panorama: no fixed release yet. Restrict management interface access to trusted internal IP addresses, and watch for Palo Alto's fixed versions.
  • Fortinet: if you use FortiGuard signatures, confirm they are at version 37.316 or later, and keep checking Fortinet's product review.
  • Cisco: products are still under investigation and there are no workarounds, so limit management-plane exposure and watch for advisory updates.

Watch the logs: Fastly and Huntress reported reconnaissance, and Cloudflare reported attempted exploitation. Look for unusual request patterns, unexpected PHP worker behavior and out-of-memory errors on PHP hosts. Investigate any web server or PHP process that spawns a shell or child processes it normally wouldn't, or writes files into the web root.

For CMMC and federal contractors: internet-facing PHP systems in scope for your System Security Plan need a documented patch action or compensating control. Unpatchable end-of-life PHP belongs in your POA&M with a migration date.

Sources