PHP2Shell: Amazon's WAF Rules Trailed Its Own Honeypot

Amazon says its honeypots logged an attempt to exploit the PHP flaws called PHP2Shell on Saturday, Oct. 17, which it found by looking back and announced on Wednesday, Oct. 21, the day the flaws' embargo lifted. Amazon's own changelog shows that the first managed firewall rule aimed directly at one of the two flaws, CVE-2026-109618, is dated Thursday, Oct. 22, about a day after disclosure. By TradeFlock's calculation, that is five days from the earliest attempt Amazon later found to the first AWS signature built for that bug. A third PHP bug disclosed Friday is not fixed by this week's patches.

What PHP2Shell Is and Who Is Exposed

PHP2Shell is the name given to two critical flaws in the PHP runtime, CVE-2026-109618 and CVE-2026-109619. Both let an unauthenticated attacker run code on a server. The PHP project released fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 when its embargo lifted at 10 a.m. ET on Wednesday, Oct. 21.

The first flaw, described in PHP's advisory on out-of-memory corruption, lets a crafted file upload push PHP into running out of memory while request data is only partly set up. The second, set out in the advisory on stale global state, lets one request leave behind data that a later request on the same worker process reuses after its memory has been freed.

The US Cybersecurity and Infrastructure Security Agency urged organizations to patch immediately and said organizations that cannot update immediately, or that still run unsupported PHP 8.1 or earlier, should take PHP-based systems offline until patched. CISA said it had not seen successful exploitation as of publication.

Amazon Saw Attempts Before the Patch Existed

In a post by Amazon Integrated Security CISO CJ Moses, Amazon said its MadPot honeypot network recorded a PHP2Shell exploitation attempt on Oct. 17 from an IP address tied to a commercial anonymization network, four days before disclosure.

Amazon said it found proof-of-concept exploits from around 10 p.m. ET on Tuesday, Oct. 20, hours before the embargo lifted. It said it was unclear whether any of those attempts would have succeeded against real systems. TradeFlock has not verified Amazon's telemetry.

The Dates in AWS's Own Changelog

The AWS Managed Rules changelog lists the PHP rule group releases. Version 2.3, dated Oct. 21, added a rule called PHP2Shell_BODY for CVE-2026-109619. For CVE-2026-109618, that entry offered interim cover by pointing customers to a separate rule that blocks request bodies larger than 8 KB.

Version 2.4, dated Oct. 22, added PHP2Shell_BODY_Extended, which the changelog says "now detects CVE-2026-109618 directly." The two AWS documents do not fully agree on dates: the changelog dates version 2.3 to Oct. 21 while the mitigation guide notes it in an Oct. 22 update, and the guide notes version 2.4 on Oct. 23 while the changelog dates it Oct. 22. The changelog gives dates, not times.

Counted from the earliest attempt Amazon later found in its honeypot data, the direct rule for CVE-2026-109618 arrived five days on, by TradeFlock's calculation. Counted from disclosure, the gap was about a day, with the 8 KB rule as a stopgap in between. Amazon's threat post urged detections that do not depend on one CVE's signature because "the first exploitation will often come before those signatures exist."

Where AWS Says Its Firewall Stops

AWS's WAF mitigation guide says one of the two vulnerabilities "is largely outside the reach of any web application firewall."

It flags more gaps. Customers who pinned the rule group to version 2.3 have the rule for CVE-2026-109619 but not the one for CVE-2026-109618, and version 2.2 or earlier has neither. Both rules inspect a request body only up to a limit, which AWS says is a fixed 8 KB on Application Load Balancer. And neither rule catches what AWS calls header amplification, where a few kilobytes of upload headers expand into far more memory inside PHP while staying under size caps.

For applications that accept file uploads, AWS says its firewall "reduces risk but does not close the vulnerability."

A Third PHP Bug the Patch Does Not Fix

On Friday, Oct. 23, the PHP project posted PHP's Oct. 23 informational advisory on CVE-2026-115560, a separate code execution path. PHP said it applies only under "an unusual combination of configuration and application code," where an app switches its session serialize handler at runtime while session upload progress is still enabled.

PHP recommends setting session.upload_progress.enabled to 0 until its next regular bugfix release and said it will publish a full advisory then. AWS's guide says the PHP2Shell_BODY rule in version 2.4 and later already blocks the request pattern tied to the new bug.

What PHP Teams Should Check This Week

Based on the PHP, CISA and AWS documents: upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart every worker. Confirm that any AWS web ACL uses the default PHP rule group version or version 2.4 or later. Turn session upload progress off and keep it off. Review logs from Oct. 17 onward.

Amazon said AI-assisted analysis makes it cheaper to turn a patch into a working exploit, echoing Interpol's warning on AI and cybercrime. Investors are backing defenders, as with Kevin Mandia's startup Armadin.

PHP has not dated the fix for CVE-2026-115560. Until then, firewall rules are a bridge, not a fix.

Cover image: Brian Hankins / Wikimedia Commons, public domain (cropped).