PHP2Shell update: it was exploited before disclosure

The PHP2Shell story just got worse. Amazon's threat intelligence team confirmed yesterday that attackers were exploiting the two critical PHP vulnerabilities four days before the public even knew they existed. MadPot, Amazon's global honeypot network, logged a PHP2Shell exploitation attempt on October 17, 2026 — well ahead of the October 21 embargo lift. The official workaround that circulated after the leak? It doesn't fully work either.

What's new since our first report

When we covered PHP2Shell on October 21, the picture was alarming but incomplete: two critical RCE flaws in PHP's core (CVE-2026-109618 and CVE-2026-109619), CVSS 9.2, affecting roughly 70% of the web, found by AI models from OpenAI and Google. Here's what the past 24 hours added.

Zero-day exploitation confirmed

Amazon Threat Intelligence, in a blog post by CISO CJ Moses, disclosed that MadPot telemetry captured a PHP2Shell exploitation attempt on October 17, 2026 (UTC) — four days before the coordinated disclosure date of October 21 at 14:00 (UTC). The attempt originated from IP 103.216.220.92, tied to a commercial anonymization network.

Amazon couldn't confirm whether that pre-disclosure attempt would have succeeded against a real production system, or how the attacker obtained exploit knowledge before the advisory. But the implication is stark: someone had a working exploit while the vulnerability was still under embargo.

Then on release day itself, the timeline compressed further. Amazon identified multiple proof-of-concept exploits as early as 02:00 (UTC) on October 21 — twelve hours before the embargo was scheduled to lift. Between 02:00 and 08:00 (UTC), additional exploitation attempts hit MadPot from separate anonymized infrastructure, suggesting multiple independent actors rather than a single group.

"PHP2Shell is now being broadly exploited in the wild," Moses wrote.

NetSPI independently confirmed the same: "Exploitation has been confirmed in the wild since at least October 21, 2026."

The leaked workaround was never enough

When details leaked on Hacker News October 20, the going advice was to disable session.upload_progress. PHP's own security advisory, published alongside the patch, corrected that. A second, independent use-after-free sits in the SAPI-level multipart form parser itself and triggers on any multipart/form-data POST — regardless of whether session upload progress is on.

PHP core developer Gina Peter Banyard put it bluntly before the release: "The only thing I can say is that the only mitigation is patching/upgrading PHP. I sadly know too much."

Amazon's advisory echoes this: "There are no configuration-only workarounds that fully address both issues."

Indicators of compromise

Amazon published six IP addresses observed targeting MadPot:

Amazon noted these are shared anonymization infrastructure and should be investigated, not simply blocked.

Services going dark

The precautionary shutdowns spread beyond what we reported initially. BambooHR took its service offline across the United States, Canada, and Ireland, warning customers that payroll processing would be interrupted with no restoration timeline. In the Netherlands, MijnOverheid, DigiD, the lower house of parliament's website, the national cybersecurity center, and multiple education systems all went dark. The Philippines' NCERT and Malaysia's NC4 issued national alerts.

Why this matters

The four-day gap between first exploitation and public disclosure is the headline, but it's the wrong frame. The real story is that coordinated vulnerability disclosure — the process that has defined software security for two decades — is structurally fraying, and AI is pulling at both ends simultaneously.

On the defense side, AI models (GPT-5.6 Sol and Gemini 4 Argon, working with Wiz and Calif researchers) found bugs that had sat in PHP's memory management and error handling for over a decade. One researcher did in about a week what would previously have taken a team months. That's a net win for defenders — but only if patches get applied faster than exploits get built.

On the attack side, Amazon's Moses made the connection explicit: "AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit. As a result, more actors can act within hours or even minutes once technical details of a vulnerability are disclosed."

So the same capability that finds the bug also weaponizes the fix. The window between "patch available" and "mass exploitation" used to be measured in weeks. Then days. Now Amazon is telling security leaders to measure it in hours. A 7-day or 30-day patching SLA "assumes a delay that no longer exists."

The leak made everything worse. The Hacker News post on October 20 pulled the disclosure forward by a day, gave attackers a head start on building exploits, and spread incorrect information — a CVSS of 10.0 (official is 9.2) and a single-cause attribution that missed the second independent use-after-free path. Administrators who applied the leaked session.upload_progress mitigation and considered themselves safe were still exposed through the multipart parser vector. That's not carelessness; that's acting on the best information available at the time, and it was wrong.

The numbers behind the panic

The gap between earliest exploitation (Oct 17) and patch availability (Oct 21 14:00 UTC) is roughly 102 hours. For any organization running an unpatched PHP server with Apache mod_php — the configuration where a single unauthenticated request triggers RCE before any application code runs — that's a 4-day window where the attacker had the advantage and the defender had nothing.

What to watch next

Three things will determine whether PHP2Shell becomes a footnote or a generational security event:

1. CISA KEV listing. Neither CVE is in CISA's Known Exploited Vulnerabilities catalog as of this writing. Given Amazon's confirmation of in-the-wild exploitation, addition is likely a matter of days, not weeks. When it lands, U.S. federal agencies have a mandatory patching deadline — typically two weeks — that will cascade into enterprise requirements.

2. Confirmed compromises. We have exploitation attempts against honeypots and broad scanning, but no major provider has yet disclosed a confirmed successful intrusion resulting from PHP2Shell. The first organization to admit a real breach — especially one involving data exfiltration via the memory-reading primitive — will shift this from "patch urgently" to "incident response."

3. The next AI-found bug. PHP2Shell is the second major AI-discovered vulnerability in recent months (following OpenAI's Patch the Planet program). The pipeline is now proven: AI finds deep bugs in mature codebases, coordinated disclosure tries to buy time, but AI-assisted exploit development compresses that window. Expect a cadence of AI-disclosed critical vulnerabilities in foundational software — OpenSSL, glibc, nginx, language runtimes — that test whether the current disclosure model can keep up.

If you're running PHP and haven't patched, the investigation window starts October 17, not October 21. Check logs for unusual multipart requests followed by memory-limit errors or HTTP 500s, oddly large PHPSESSID cookies, and unexplained worker restarts. And assume any internet-facing unpatched PHP installation is potentially compromised — not because it definitely is, but because the cost of being wrong is a full server takeover with no authentication required.