PHP Exploitation Is Confirmed, and CISA Wants Evidence Collected Before the Patch

PHP exploitation is now confirmed in the wild. On October 26, 2026, the US Cybersecurity and Infrastructure Security Agency added the two PHP2Shell bugs, CVE-2026-109618 and CVE-2026-109619, to its Known Exploited Vulnerabilities catalog and gave federal civilian agencies until October 29 to fix them. Both catalog entries carry a second requirement that most patch orders lack: agencies must run a forensic triage to find out whether they were already breached.

CISA Set a Three-Day PHP Deadline With a Forensic Triage Flag

CISA’s catalog lists both PHP flaws as allowing unauthenticated remote code execution, with a due date of October 29, 2026, three days after they were added. Each entry is marked “forensicTriage: Yes.” The agency also updated its October 21 alert telling organizations to patch PHP immediately. CISA did not say who is exploiting the bugs, TechCrunch reported. The deadline comes from Binding Operational Directive 26-04, which ties remediation speed to risk. Under its guidance, a vulnerability on an internet-facing asset that gives an attacker total control and can be exploited automatically gets a three-day window. The three-day due date on both PHP entries reflects that combination. The PHP project shipped fixes in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on October 21, as we covered in our report on how the fix stalled for two years.

CISA’s Triage Guidance Puts Evidence Collection Before the Patch

CISA’s BOD 26-04 implementation guidance lists six triage steps, and patching is the third. Agencies first scope which systems are affected and set up a communication channel that does not run over possibly compromised infrastructure. Then they preserve evidence, starting with volatile data held in memory, caches or in transit, which disappears when a machine restarts. The guidance tells agencies not to alter or remediate systems before collecting that evidence when they can avoid it, because patching may destroy the artifacts. Only then do they patch, contain the affected systems, analyze the evidence for signs of access or data theft, and write a triage report. That report decides the outcome. No evidence of compromise means heightened monitoring and normal remediation. A confirmed compromise goes to CISA’s incident reporting system and becomes a full incident response. CISA says the six-step timeline is a recommendation, and the binding requirement is that an adequate triage happens.

A Honeypot Recorded 35 PHP Shells in One Afternoon

The clearest public evidence of PHP exploitation comes from honeypot data published on GitHub by a researcher under the handle 0x4D31, which TechCrunch cited. On October 24, three decoy servers running PHP 8.4.26 under Apache mod_php recorded 35 shell processes launched directly by Apache workers. The traffic came from two IP addresses on commercial hosting networks. The report says that is two address clusters, not proof of two separate attackers. The first shell from one address appeared at 15:35 UTC, and the second address produced 32 shells between 16:46 and 18:57 UTC. Each attack followed the same four stages: push PHP toward its memory limit, leak memory through an oversized PHPSESSID cookie, apply more memory pressure, then send a final request tuned to the leaked addresses. The PHP errors fired at request startup, before any application code ran, so the target’s CMS or framework made no difference. Later commands from the second address checked the user, hostname and processor type of each machine it reached.

Why This Matters for Engineering Leadership

The instinct during a critical vulnerability is to patch everything as fast as possible, and CISA’s order shows why that instinct needs a rule attached. A server patched and restarted without first capturing its memory and logs can no longer answer whether someone got in between October 21 and the moment it was fixed. For any team running PHP, that means three actions this week. Pull Apache access logs and PHP error logs for every internet-facing PHP host back to at least October 21, and search them for oversized PHPSESSID values and memory-limit errors at request startup. Check process telemetry for shells or download tools whose parent is the web server. For hosts still unpatched, snapshot memory and disk before applying 8.4.27 or the matching release. The longer fix is a written plan, made before the next catalog entry, that says which systems get evidence captured first, who owns that call, and how much downtime the business will accept to get it. CISA asks agencies to write exactly that plan for their high value assets. Private companies are outside the directive, and the same reasoning applies to them.

FAQ