Amazon saw PHP2Shell exploited 4 days before disclosure

Amazon Threat Intelligence said on 21 October 2026 that it saw an attempt to exploit PHP2Shell on 17 October 2026, four days before the two underlying PHP flaws, CVE-2026-109618 and CVE-2026-109619, were publicly disclosed. The attempt hit a honeypot in Amazon's MadPot sensor network from an IP address tied to a commercial anonymization network. Amazon calls this a threat actor's activity but says it is unclear how the actor learned of the bug while it was under embargo.

What Amazon observed

The embargo was due to lift at 14:00 UTC on 21 October. Amazon says the earliest proof-of-concept exploit it identified that day appeared around 02:00 UTC, and that between 02:00 and 08:00 UTC it logged further attempts from other anonymized infrastructure. The payloads and anonymization choices varied, which Amazon reads as multiple actors. Once the patch shipped, it says more proofs of concept appeared within hours and were used against its sensors almost immediately, and that PHP2Shell is now broadly exploited in the wild.

Amazon also says technical analysis is ongoing and that it is unclear whether any of the attempts would have succeeded against real systems. It lists six source IP addresses, one dated 17 October and five dated 21 October, and warns that they are shared anonymization infrastructure, so teams should investigate hits rather than simply block them.

Why Amazon says this matters beyond PHP

Amazon draws two lessons. First, an embargo protects defenders only until someone else finds the same bug, so the disclosure date is not the earliest date of exploitation. Second, it argues the gap between a patch and a working exploit is shrinking because AI-assisted analysis makes it cheaper to turn a patch diff or advisory into an exploit, so more actors can act within hours or minutes. That second point is Amazon's assessment; the post gives no measurement of how much faster exploits now arrive.

What Amazon recommends

• Upgrade to the fixed PHP versions. Amazon says this is the only complete remediation for both CVEs and that no configuration-only workaround covers both.
• If you cannot patch at once, consider blocking multi-part file uploads in PHP deployments, after checking what that breaks in your application.
• Search for POST requests containing the string PHP_SESSION_UPLOAD_PROGRESS in form uploads, review web server logs, and check application servers for unexpected process execution or file changes.
• Investigate from at least 17 October 2026, not from the disclosure date.
• Invest in detection that does not depend on a signature for one specific CVE, since first exploitation often comes before signatures exist.

The catch

This is one vendor's telemetry from its own honeypots, which are decoys rather than customer systems. The post does not say whether any customer was compromised, how the 17 October actor got the details, or how many of the later attempts worked. It points to an AWS WAF mitigation post, which we did not read; Amazon describes it as a way to reduce exposure while you patch, not a substitute for the upgrade.

What to do

• Ask your platform team which PHP version your internal tools, admin panels and AI front ends run on, including those a vendor hosts for you.
• Set an hours-based target for critical internet-facing patches and check whether your current policy allows days.
• If a PHP system was exposed before 21 October, widen the log review window back to 17 October.