October 17, 2026. An Amazon honeypot logs an exploit attempt against a PHP bug that nobody outside a small group is supposed to know about yet.
Four days later, PHP ships the fix.
Two CVEs. Not in WordPress, not in a plugin. In PHP itself.
what actually happened#
PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities that, in PHP’s own words, “can allow unauthenticated remote code execution.”
CVE-2026-109618, RCE via OOM corruption. Out-of-memory handling can interrupt PHP while internal request data is only partly initialized. Request cleanup may then treat that invalid data as valid.
CVE-2026-109619, RCE via stale global state. Request-owned internal state can survive after its memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.
Both are memory-safety bugs in the engine. The application on top does not matter much: per PHP, there is “a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.”
who is at risk#
Per the PHP security team: all PHP installations serving web requests. PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. They consider the risk highest for mod_php.
PHP 8.1 and older no longer get releases. Because of the severity, the PHP team published minimal source backports for 7.4, 8.0 and 8.1. Distributions and LTS vendors got the patches in advance, so check your vendor’s packages.
Wiz Research, who worked on the findings, goes further: “Every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4.” That is their claim; PHP’s advisory names the supported branches.
the timeline#
| When (2026, UTC) | What |
|---|---|
| Oct 17 | First exploit attempt in Amazon’s MadPot honeypots, from an IP tied to a commercial anonymization network. Four days before disclosure. How the actor got exploit details is unclear. (Amazon) |
| Oct 21, ~02:00 | Multiple proof-of-concept exploits appear. (Amazon) |
| Oct 21, 02:00 to 08:00 | More attempts against MadPot from other anonymized infrastructure, likely multiple actors. (Amazon) |
| Oct 21, 13:30 | PHP releases the fixes. (CERT-EU) |
An attempt on a honeypot is not a confirmed breach. But it means the clock started on the 17th, not on patch day.
the ai part#
This is the line from Wiz’s write-up I keep rereading:
“The underlying flaws had been present for decades, but demonstrating their exploitability required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve. Frontier AI models substantially reduced that barrier.”
And: frontier models enabled them “to develop and adapt working exploits across multiple applications in hours.”
Here it was defenders using AI, with a coordinated fix. But the lesson cuts both ways. “Too complex to exploit” used to be a quiet layer of defence for old, ugly code. That layer is getting thinner.
what a Security analyst does today#
1. Find every PHP that serves web traffic. Not just the obvious web servers. Containers, old intranet apps, vendor appliances, the box under someone’s desk. Check the version against 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, or your distro’s patched package.
2. Patch, then restart every worker. A patched binary that old workers never reloaded is not patched.
3. If you cannot patch today, PHP lists stopgaps that reduce specific paths but “do not make an installation safe”:
session.upload_progress.enabled=0in php.ini or the pool config, then restart (not viaini_set()or.user.ini)- on PHP 8.5,
fatal_error_backtraces=0 - a low
post_max_size(8M if you don’t take uploads), and request-size limits at the web server or proxy memory_limit=-1set where apps can’t override it, with a container or cgroup limit as the real boundary
4. Look back from October 17. Amazon’s advice, and the right one: “Start investigations from the earliest known exploitation, not from the disclosure date.” No IOCs have been published that I could verify. My read on where I’d look first, given how these bugs are triggered: PHP worker crashes and restarts, memory-limit fatal errors, and unusually large or many-part POST requests to PHP endpoints since the 17th. That is a starting point, not a signature.
Working the ticket? The full investigation playbook, from inventory to calling it a compromise: php2shell: an investigation playbook.
the part that stays#
Amazon put it plainly: “A 7-day or 30-day SLA assumes a delay that no longer exists.”
Most of us still run patching on calendars built for a slower world. An exploit attempt four days before disclosure. Proofs of concept hours before the patch. The SLA spreadsheet did not get the memo.
Honestly? I don’t know how many teams will still be finding forgotten PHP boxes in a month. I think a lot.
What’s the oldest PHP version still running somewhere you’re responsible for?
the bug was old. the speed was new.
sources#
- PHP, security advisory for 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (who is at risk, the two CVEs, mitigations): php.net
- PHP 8 ChangeLog (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp): php.net/ChangeLog-8.php
- Amazon Threat Intelligence, “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot”: aws.amazon.com
- CERT-EU, security advisory 2026-018 (release time): cert.europa.eu
- Wiz Research, “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet”: wiz.io
