Someone was trying to exploit the PHP2Shell flaws, which researchers found with the help of AI, on 17 October 2026, four days before the PHP project published its fixes. Amazon’s security team described it in a post on the AWS Security Blog on 21 October. Wired’s Lily Hay Newman reported the finding late that evening, US Eastern time, which was early on 22 October in UTC.
PHP2Shell is a pair of critical PHP flaws found with AI
PHP2Shell is the name for two flaws in PHP, CVE-2026-109618 and CVE-2026-109619, which PHP’s advisory says “can allow unauthenticated remote code execution”: an attacker can run code on a server without logging in. The advisory says all PHP installations serving web requests are at risk, and Wiz, whose researchers found the flaws with Calif and OpenAI, says PHP powers 70% of all websites. Both flaws are rated 9.2 out of 10 on the CVSS v4.0 severity scale, according to PHP. Wiz says it used its own tool, Wiz Atlas, together with Google’s Gemini 4 Argon and OpenAI’s GPT-5.6 Sol throughout the research. PHP fixed them on 21 October, as covered in the earlier report on the flaws; more follow-ups are in the news section.
AWS saw an attack attempt four days before the fix
AWS runs MadPot, a network of honeypots: decoy servers that attract attackers so their methods can be studied. Its analysts found a PHP2Shell exploit attempt dated 17 October. It came from an IP address linked to a “commercial anonymization network”, which Wired explains as a proxy network or VPN.
The post, by CJ Moses, whom AWS describes as the CISO of Amazon Integrated Security, says attacking a honeypot from a hidden address “suggests the activity was conducted by a threat actor, though it remains unclear how the actor acquired exploit information prior to disclosure”.
AWS gives this timeline (times in UTC):
| When | What AWS reports |
|---|---|
| 17 October | First exploit attempt against MadPot, from one anonymised IP address |
| 21 October, from about 02:00 | Multiple proof-of-concept exploits identified (working demonstration code) |
| 21 October, 02:00 to 08:00 | More attempts on MadPot from other anonymised infrastructure; different attack code and anonymisation services suggest several actors |
| 21 October, 14:00 | Embargo (the agreed secrecy period before disclosure) lifted, patches released |
| 21 October, within hours of 14:00 | More proof-of-concept exploits appear and are used against AWS sensors almost at once |
Wired reports that proof-of-concept code “began emerging publicly on Wednesday”, 21 October, with some seeming to appear hours before the public disclosure at 10am US Eastern time (14:00 UTC).
AWS concludes: “PHP2Shell is now being broadly exploited in the wild.” That describes widespread attack activity. AWS gives no count of hacked sites.
AWS says critical patches now need hours, not weeks
Moses writes that the time from a patch to a working exploit is shrinking “for structural reasons”: AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit. He tells security leaders that a “7-day or 30-day SLA assumes a delay that no longer exists” and that patch times for critical internet-facing flaws should be measured in hours.
No confirmed break-ins and no known leak source
- No confirmed break-ins. Everything AWS describes hit its honeypots, and the post says “it’s unclear if any of these attempts would have succeeded in real-world systems”. It names no victim.
- No explanation of the early access. Huntress reported that details leaked online on 20 October, but that is three days after the first attempt, and no source links the two.
Wiz reported the flaws to PHP in August
According to Wiz’s write-up, its researchers reported the flaws to PHP on 24 August, and PHP began building a fix on 21 September. Wiz says it worked with the PHP team, OpenAI and many cloud and security companies, AWS among them, before disclosure.
PHP site owners and hosts are most exposed
Anyone who runs or hosts a PHP website is affected, and Wiz lists WordPress, Drupal and Joomla among the platforms exposed. A site that was patched on 21 October may still have been probed before then. Hosting companies and agencies that manage many PHP sites have more sites to check.
Patch, then check logs from 17 October
- Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a fixed build from your distribution. PHP’s advisory and AWS both say updating is the only complete fix.
- Search your logs from 17 October, not from 21 October. AWS says to start any investigation from the earliest known attack.
- Look for specific signs. AWS suggests POST requests containing
PHP_SESSION_UPLOAD_PROGRESS, unexpected processes and changed files. Wiz adds multipart requests followed by memory-limit errors or repeated HTTP 500 responses, oddly large or malformedPHPSESSIDcookies, and unexplained PHP worker churn (PHP worker processes stopping and starting for no clear reason). - Check the listed IP addresses, but don’t just block them. AWS published six addresses, including 103.216.220.92 for 17 October. They belong to shared anonymisation services, so AWS says to investigate rather than block.
- If you cannot patch at once, AWS suggests blocking multi-part file uploads, after checking what that breaks.
Our take
We wrote yesterday that, here, the AI-assisted defenders got there first. That still holds for finding the bugs, but someone else had the flaws, or a way to exploit them, at least four days before the fix. The honest unknown is how. We don’t think anyone should guess at the leak until PHP, Wiz or AWS explains it.
Our view is that AI sped up finding these bugs, but the fixing and secrecy process did not keep pace. Wiz reported the flaws on 24 August, PHP began building a fix on 21 September, and the patches came out on 21 October. Over those weeks many companies were told, details leaked, and attacks began.
The practical lesson is simpler than the debate about the risks of advanced AI: treat the disclosure date as a deadline you may already have missed. For PHP sites, that means patch, then look backwards.