PHP2Shell just landed on CISA KEV, and the deadline is Thursday
this morning we told you PHP2Shell had gone from “theory” to “honeypots full of shells.” this afternoon CISA made it official: both PHP2Shell CVEs are now in the Known Exploited Vulnerabilities catalog, with a federal fix-by date of October 29. that is three days. the sloth has taken longer naps than that, and the sloth is not running your public web tier.
what the KEV entries actually say
straight from the catalog, no sloth embellishment:
- CVE-2026-109618, “PHP Memory Corruption Vulnerability.” unauthenticated RCE through the out-of-memory corruption path.
- CVE-2026-109619, “PHP Stale Internal Request-State Vulnerability.” unauthenticated RCE through leftover request state, the one tied to session upload progress.
- date added: October 26, 2026. due date: October 29, 2026.
- required action: apply mitigations per vendor instructions under BOD 26-04, follow CISA’s forensics triage requirements, or discontinue the product if you cannot mitigate.
- forensic triage: yes. known ransomware use: unknown, for now.
- CISA notes this is an open-source component that ships inside lots of other products. translation: your appliance vendor, hosting panel and that one ancient intranet app all count.
why a three-day clock is the loud part
KEV deadlines are usually measured in weeks. a three-day window says CISA is treating this the way the honeypots are: as something being used right now. federal civilian agencies are bound by it. everyone else is not, but KEV is the list your auditors, insurers and vulnerability scanners all read, so “we were waiting for CISA” just stopped being an excuse. the forensics flag matters too. it is CISA saying patching alone is not the finish line: if a box was exposed and unpatched, go look for evidence of compromise.
the order of operations, again, because it matters
- find every PHP that serves web traffic. Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are all in scope per CISA. mod_php is the highest risk per PHP.
- if a box was exposed on a vulnerable build, capture memory and logs first. a restart wipes the 109619 state, and with it your evidence.
- patch: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. vendor builds (cPanel EasyApache, CloudLinux, TuxCare, Plesk) need confirmation from the vendor. 5.4 through 7.3 has no fix: migrate or isolate.
- restart every worker, not a graceful reload.
- prove it: check the running version on every host, not the package database on one of them.
forensic triage without a forensics team
you do not need a fancy DFIR retainer to do the basics. on each exposed host: save the web server error and access logs back to October 17, dump the process tree, list PHP files changed since October 17 in web roots, list cron jobs, local users and SSH authorized keys, and snapshot the disk if it is a VM. the signals from this morning still apply: the web server spawning sh, bash, id, curl or wget, bursts of “Allowed memory size” errors and worker segfaults, and multi-megabyte multipart POSTs to pages that never take uploads. CISA’s alert carries a Sigma rule for exactly this.
sloth take
the timeline on this one is a speedrun: leak, patch, “no confirmed exploitation,” honeypot shells, a bitcoin CTF cracked, and a KEV listing with a three-day clock, all inside a week. if your patch plan for PHP2Shell was “next maintenance window,” congratulations, CISA just scheduled it for you. Thursday. bring logs.
sources
- CISA Known Exploited Vulnerabilities catalog entries for CVE-2026-109618 and CVE-2026-109619 (added October 26, 2026, due October 29, 2026)
- CISA alert “Critical Vulnerabilities in PHP Require Immediate Patching” (updated October 26, 2026)
- BleepingComputer, “PHP2Shell security flaws now successfully exploited in the wild” (October 26, 2026)
- GovInfoSecurity, “Honeypots Now Recording In-the-Wild PHP2Shell Exploits” (October 26, 2026)
- PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 release notes
