The two PHP runtime flaws that US and allied agencies urged everyone to patch last week have moved from theoretical to exploited. On 26 October CISA placed CVE-2026-109618 and CVE-2026-109619, the pair nicknamed “php2shell”, in its Known Exploited Vulnerabilities (KEV) catalog and revised its PHP alert to match. Federal civilian agencies now have until 29 October to fix them, and anyone running PHP on an internet-facing server should treat the same three-day window as their own.
What changed since the first warnings
When we first covered these flaws, no agency had reported confirmed attacks. That changed on 26 October. CISA only lists a CVE in KEV when there is evidence of exploitation, so the catalog entry is the agency’s signal that attacks are happening, even though neither the alert nor the catalog entry describes them.
Nothing CISA has published says who is exploiting the flaws, against which sectors, or at what scale. The catalog marks use in ransomware campaigns as “Unknown”. Read that as no public evidence either way, not as a sign that ransomware crews are uninterested.
Two details in the catalog entries stand out. The remediation due date is 29 October, three days after listing. And both entries are flagged for forensic triage: under Binding Operational Directive 26-04, agencies are expected not only to patch but to check whether an attacker got in before the fix went on. That expectation is the practical message for private-sector defenders too. Patching closes the door; it does not tell you whether someone already walked through it.
The two flaws in brief
Both bugs are in PHP itself, and CISA says they affect every PHP installation that serves web requests, which is why the exposure is so wide.
- CVE-2026-109618, catalogued as a PHP memory corruption vulnerability, is described by CISA as an out-of-memory corruption flaw.
- CVE-2026-109619 is catalogued as a stale internal request-state vulnerability; CISA gives no further technical detail.
CISA’s catalog maps them to weaknesses including use after free (CWE-416), improper handling of exceptional conditions (CWE-755) and access of an uninitialised pointer (CWE-824). The agency’s summary for each is the same in effect: an attacker with no credentials can reach code execution over the network.
Who is exposed
CISA says every PHP installation that serves web requests is affected, across Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. It notes that the PHP project rates the mod_php configuration as the riskiest of these.
The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. There is no fix listed for PHP 8.1 or anything older, and CISA’s guidance for those branches is blunt: take the systems offline until they can be moved to a supported, patched release.
The harder problem is PHP you do not know you run. CISA warns that PHP is frequently embedded inside other software, so a host inventory that looks only for system packages will miss copies shipped inside appliances, management consoles and commercial web applications. For those products, the supplier’s own advisory, not the PHP release notes, decides which builds are affected and which carry the fix.
What to do now, in order
- Patch internet-facing PHP today. Move each server to the fixed release in its branch. Do the public web tier first, then internal applications.
- Retire or isolate unsupported branches. Anything on PHP 8.1 or earlier, or anything that cannot be updated in time, should come off the network until it can be, per CISA.
- Chase embedded copies. Ask every supplier whose product exposes a web interface whether it ships PHP, and apply their update when it lands. A web application firewall may blunt some attempts in the meantime, though CISA frames it only as partial protection.
- Hunt for earlier compromise. Look for PHP worker or web server processes spawning shells or pulling down tools, which is the behaviour CISA tells defenders to watch for. CISA’s SIGMA rule for this activity is in its public cisagov/SIGMA_Rules repository on GitHub. Review web server and PHP logs from before the patch date, not just after.
- Treat a hit as an incident. If a host shows signs of exploitation, isolate it and preserve its logs before rebuilding, so the timeline survives.
What remains unclear
CISA has not said when exploitation began, whether it predates the 21 October disclosure, or whether it targets particular hosting setups. It has also not said whether the attacks rely on one flaw or chain both. Until that detail appears, the conservative assumption is that any unpatched, internet-reachable PHP server may already have been probed, and the forensic check matters as much as the patch.
Source: Cybersecurity and Infrastructure Security Agency (CISA).