By the Time CISA Says It, You're Late

Six days. That's how long it took to go from "we haven't seen successful exploitation" to "federal agencies, you have three days."

On Monday, CISA added both PHP2Shell bugs, CVE-2026-109618 and CVE-2026-109619, to its Known Exploited Vulnerabilities catalog and gave US federal civilian agencies until October 29 to deal with them. Both score 9.2. Both hand an unauthenticated attacker code execution on a PHP server. The Register's write-up closes on the right note: anyone still waiting for more proof before patching has waited too long.

I'd push it further. If your patch process needed CISA's confirmation to move, the process is the vulnerability.

What happened this week

Quick recap, because this story moved fast and some of the early reporting was wrong.

Researchers at Calif, OpenAI and Wiz found the bugs in August and September, and all three used AI models to do it. Both are memory corruption flaws in how PHP cleans up after a request dies badly. Hit PHP's memory limit at exactly the wrong moment and it leaves half-built internal data lying around, then trusts it later. On Apache with mod_php, an unauthenticated request can trigger that before any application code runs. Wiz says every PHP release in the last decade, back to 5.4, is hit by at least one of the two.

Read that again. Before any application code runs.

Your app's WAF rules, your input validation, the secure coding training you paid for. None of it is in the path.

Then the coordinated disclosure fell apart. CVE IDs leaked onto forums. A proof-of-concept video went up by mistake. Chainguard shipped built images containing the fix more than six hours before the embargo lifted, and the PHP maintainers blamed them publicly. Chainguard's CEO, Dan Lorenc, says his team rediscovered the same bugs in one night with an AI harness and a basic "find bad vulnerabilities in PHP" prompt, and that people were already getting hit.

He's right about that last part. AWS saw exploitation attempts on October 17, four days before a patch existed.

Proof showed up. Just not cleanly.

By Friday, nobody had publicly confirmed a successful compromise. The PHP Foundation said as much. Mandiant's CTO, Charles Carmakal, said there was no evidence of wide-scale success but that limited exploitation may already have started. He also noted that a lot of the public PoCs were vibe-coded junk that couldn't pop a shell, while some validated ones worked against default mod_php deployments. Not PHP-FPM.

On October 24, Perplexity researcher Adel Karimi logged 35 successful shell executions across three honeypots running PHP 8.4.26 under Apache mod_php. Two source IPs. Once in, the attackers tried to phone home with PHP, curl and wget. Nothing extra got pulled down. Meanwhile Delft University's threat intel lab has counted more than 50,000 exploitation requests from 600-plus IPs in 70 countries, and 171 of those IPs moved past scanning into sending exploit code or droppers.

Two caveats matter. Karimi's honeypots ran a single-worker setup that favours the attacker, so a working shell on a honeypot doesn't mean production boxes fall over at the same rate. And a couple of vendors walked back early claims this week. Sophos decided what it saw was scanning and failed attempts. Palo Alto Networks pulled a claim tying the bugs to a breach at a European government agency.

So the reliable picture looks like this. The exploit works under the right conditions. A lot of people are trying it. Nobody, CISA included, has said how many real servers are owned.

That uncertainty is exactly why waiting is a bad bet.

Confirmation is a lagging indicator

I've worked more than 600 incident-response engagements over 26 years. The timeline almost never starts when the client thinks it does. It starts weeks earlier with something quiet: a web shell nobody noticed, a scheduled task, an outbound connection from a box that has no business making one.

KEV is a good list. Use it. But it confirms things after the fact, by design. CISA still hasn't said who got hit or what it saw. By the time an agency is comfortable writing "known exploited," the people doing the exploiting have had days. Here, they had a four-day head start on the patch itself.

And the window keeps shrinking. Lorenc's point is the one I can't shake: being told a big project has a serious bug is now enough for someone with a decent model to find it and build an exploit in hours. Three separate research teams found these bugs with AI. Chainguard found them again overnight. Assume the people you're defending against have the same tools and fewer scruples.

The old patch logic went like this. Critical CVE drops, we assess, we wait for signs of exploitation, then we break the change freeze. That logic assumed weeks between disclosure and weaponization.

Those weeks are gone. That was last week.

Where PHP hides

Patching PHP is easy. Finding all of it is the hard part.

Your main website is the obvious one. The ones that hurt are the marketing microsite an agency built in 2019, the old WordPress install on shared hosting that still renews its cert every year, the client portal your MSP runs, the admin panel baked into a vendor appliance, the internal wiki. Plenty of PHP lives inside things nobody on your team would call "a PHP server."

Unsupported versions make it worse. If an appliance is running an old PHP branch with no patched build, you're stuck waiting on that vendor. The guidance on that is blunt: if you can't secure it, take it offline.

And your vendors run PHP too. Some of them hold your data. That makes this a third-party risk problem whether you planned for one this week or not.

What I'd do this week

Find it first. Pull every internet-facing host and check what's actually serving requests, not what the CMDB says. External attack surface scanning is the fastest way to catch the stuff nobody remembers owning.

Patch to the fixed builds: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, depending on your branch. Check your distro packages and container base images too, because that's where most of you actually get PHP.

Triage by exposure. Apache with mod_php is where validated exploits have landed. Based on Mandiant's testing, PHP-FPM looks less exposed for now. Use that to order the queue. Then patch FPM anyway.

Hunt like you're already hit. Look for your web server's user spawning shells or making outbound calls with curl or wget. Look for new or modified PHP files in web roots since mid-October. Worker crashes and segfaults in your Apache error logs around strange requests deserve a look. If you find something, preserve evidence before you rebuild. Wiping the box feels good and destroys your timeline.

Close the third one while you're in there. The PHP Foundation reserved CVE-2026-115560 for a third RCE flaw it considers unlikely in real-world apps, so it won't get an emergency fix. Setting session.upload_progress.enabled=0 shuts it down until the next regular release. One line of config. Make the change.

Ask your vendors directly. Do you run PHP in anything that touches our data? Which version? When did you patch? "We're monitoring the situation" isn't an answer.

Bottom line

If you sit on a board or run a company, ask one question this week: what triggers an emergency patch here?

If the answer includes "confirmed exploitation," change it. Critical, unauthenticated, internet-facing, widely deployed. That's the trigger. Proof shows up later, usually in an incident report with your name on it.

And if you're in Canada, CISA's October 29 deadline doesn't apply to you. Nobody's handed you a deadline at all. Pick one anyway, and make it sooner than Thursday.