For most of last week, the story around PHP2Shell went like this: the two bugs were severe, attackers were trying them, and the attempts mostly weren't working. That changed over the weekend. On Monday, Oct. 26, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added both flaws, CVE-2026-109618 and CVE-2026-109619, to its Known Exploited Vulnerabilities (KEV) catalog. Federal civilian agencies have until Thursday, Oct. 29 to deal with them. That is a three-day window.
We covered the emergency patch release when PHP shipped fixes on Oct. 21. This article covers what has happened since: confirmed exploitation, the KEV listing and the deadline that came with it. We won't repeat any proof-of-concept material.
What changed: from "failed attempts" to confirmed RCE
Here's how the picture looked on Oct. 23, when The Record summarized the industry view. Amazon reported exploitation attempts going back to Oct. 17. Sophos withdrew an earlier report of a successful exploitation and said it had only seen attempts fail. Arctic Wolf linked attempts to the Potassium botnet, and Cobalt linked others to a Mirai botnet. Google's John Hultquist said he had no validated wide-scale exploitation, but he called the threat viable and "very serious."
One reason for the early skepticism was technical. Several incident responders told The Record that address space layout randomization (ASLR), an operating-system defense that shuffles where code and data sit in memory, was hanging up many attempts. Experts also said many of the public proof-of-concept exploits only worked in lab setups.
Then, on Oct. 24, Adel Karimi, detection and response lead at Perplexity, confirmed successful remote code execution against honeypots, according to The Hacker News. Karimi added a caveat. The honeypots used a favorable configuration: a single-worker mod_php profile, where PHP runs inside the Apache web server process. He said the result doesn't tell you how reliable the attack is anywhere else. Two days later, CISA listed both CVEs as exploited.
That caveat matters, but it doesn't help much in practice. "Unreliable across configurations" is not the same as "safe." It means some servers will fall and others won't, and from outside you usually can't tell which kind you're running.
The two bugs, in plain English
Both flaws were reported by PHP's own security team (the CNA, [email protected]) and published to the National Vulnerability Database on Oct. 21. Both carry a CVSS 4.0 base score of 9.2 (Critical). Both can be exploited over the network with no login and no user interaction, and both can lead to remote code execution.
- CVE-2026-109618, "PHP Memory Corruption Vulnerability." When PHP runs out of memory, it bails out using a C mechanism called
longjmp(), which jumps straight back to an earlier point in the program. According to the NVD record, in some code paths this jump leaves request memory uninitialized, and later cleanup code reads or makes decisions based on that garbage. NVD says several out-of-memory techniques can trigger this consistently, leading to RCE. The GitHub advisory is GHSA-w8hw-w9fx-j79w. - CVE-2026-109619, "PHP Stale Internal Request-State Vulnerability." This is a stale-state bug. Global state that points into memory freed at the end of one request gets read by a later request, which also leads to RCE. The GitHub advisory is GHSA-6wmf-4rv5-p3rp.
The CVSS vector for CVE-2026-109618 marks attack complexity as High and requires certain preconditions (AT:P). That is consistent with the mixed exploitation results so far: the attack is hard to pull off reliably, but not impossible.
Why the scale is so large
The Hacker News says PHP runs on roughly 70% of websites. Censys estimates more than 32.51 million internet-reachable PHP services still running an affected version. Many of them are likely not standalone web servers that someone remembers to patch. PHP is built into a lot of commercial products, and The Hacker News lists Citrix, Dell, Broadcom and Siemens among the many vendors that have published advisories. NVD references Siemens advisory SSA-566512.
For defenders, this is the hard part. Upgrading a PHP package you installed yourself is quick. Finding the PHP inside an appliance, a management console or a vendor-supported application, then waiting for that vendor to ship a fixed build, takes much longer.
What the KEV entry actually requires
The KEV entries list the vendor as the PHP Group and tell agencies to apply mitigations according to vendor instructions, in line with CISA's BOD 26-04 and its Forensics Triage Requirements. Both entries are marked forensicTriage: Yes. That means CISA expects agencies to check whether they've already been compromised, not just to patch. Ransomware use is listed as "Unknown," so CISA isn't claiming ransomware involvement either way. The entries also point to php.net and to a CISA alert from Oct. 21 on the PHP vulnerabilities.
The binding directive covers only federal civilian agencies. Everyone else should still treat a KEV listing with a three-day deadline as CISA's clearest way of saying the threat is real.
What It Means for Defenders
Who is affected: anyone running PHP on a release older than the Oct. 21 fixes. That includes self-managed web servers, hosting environments, containers built on older base images, and vendor products that embed PHP.
Patch to these versions or later (released Oct. 21):
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
On Windows, take the newer "-1" builds. As of Oct. 26, the PHP Foundation had released Windows builds 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1. These address a separate flaw, CVE-2026-111497, an out-of-bounds write in the Brotli decoder library. Per the PHP Foundation, it is reachable in Windows builds through the cURL extension when automatic HTTP response decompression is enabled, which is off by default in cURL but can be turned on by applications and HTTP client libraries. If you patched Windows hosts last week, you need to patch them again.
Check vendor products. Go through the advisories from vendors such as Citrix, Dell, Broadcom and Siemens (SSA-566512) and any other vendor whose products ship PHP. Apply their fixed builds or the mitigations they recommend. Don't assume an appliance is safe because the host operating system is patched.
Prioritize by exposure. Internet-facing PHP services go first. Exploitation attempts have been reported since at least Oct. 17, and Arctic Wolf and Cobalt tied some of the attempts to the Potassium and Mirai botnets.
Look backward, not just forward. CISA's forensic-triage flag tells you how to think about this. For any internet-facing PHP host that went unpatched during the exploitation window, our recommendation (not a CISA mandate for non-federal organizations) is to:
- review web server and PHP logs for unusual crashes or out-of-memory errors since mid-October;
- look for unexpected processes or files created by the web server account;
- consider rotating credentials, such as database passwords and API keys, that live on any host you can't clear with confidence.
Don't rely on ASLR. It hindered many early attempts, but experts quoted by The Record warned it is not a permanent barrier, and last week's "attempts are failing" consensus lasted only a few days. Treat it as a speed bump, not a mitigation.
Federal contractors and CMMC shops: the Oct. 29 date binds agencies directly, but customers and primes will likely ask contractors whether they patched on the same timeline. Record what you patched, when, and what you checked.
