Amazon Says Attackers Hit PHP2Shell Four Days Before the Bug Went Public

Attackers were already probing for the PHP flaw known as PHP2Shell four days before it was supposed to become public, Amazon’s threat intelligence team said in a security blog post Wednesday evening.

The team found an exploitation attempt in telemetry from MadPot, Amazon’s network of honeypot sensors, dated Saturday, Oct. 17. The request came from an IP address tied to a commercial anonymization network. The two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were under embargo until 1400 UTC on Oct. 21, when PHP released fixed versions.

“While the vulnerability was under embargo, the targeting of a honeypot from an anonymized IP address suggests the activity was conducted by a threat actor, though it remains unclear how the actor acquired exploit information prior to disclosure,” Amazon wrote.

Exploits arrived before the patch

The timeline on disclosure day was just as compressed. Amazon said it saw multiple proof-of-concept exploits starting around 0200 UTC on Oct. 21, about 12 hours before the embargo lifted, and logged more attempts against MadPot from other anonymized infrastructure between 0200 and 0800 UTC. The payloads and infrastructure differed, which Amazon read as a sign of several separate actors. It also said its technical analysis is ongoing and that it is unclear whether those attempts would have worked against real systems.

Once the patch shipped, new exploits showed up within hours. Amazon now describes PHP2Shell as “broadly exploited in the wild.”

The post puts part of the blame for the shrinking gap on AI. “AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit,” the team wrote, adding that more actors can now move within hours or even minutes of technical details coming out.

What Amazon tells defenders to change

For admins running PHP on internet-facing servers, Amazon’s advice starts with patching. Upgrading to the fixed PHP releases is the only complete remediation for both CVEs, and Amazon said no configuration-only workaround fully covers them. Teams that cannot patch right away can consider blocking multipart file uploads, after checking what that breaks, and should look for POST requests containing the PHP_SESSION_UPLOAD_PROGRESS string in form uploads.

Amazon also recommends starting PHP2Shell investigations from Oct. 17 at the latest rather than from the advisory date, and measuring patch timelines for critical internet-facing flaws in hours. “A 7-day or 30-day SLA assumes a delay that no longer exists,” the post said.

The blog lists six IP addresses seen in the activity, one from Oct. 17 and five from Oct. 21. Amazon cautioned that they belong to shared anonymization services and told organizations to investigate hits on them instead of blocking the addresses outright. A separate AWS post covers AWS WAF rules for PHP2Shell as a stopgap while servers are patched.

Amazon said its systems analyze more than 200 billion events per minute and use MadPot data to block known exploitation attempts in real time.

Source: AWS Security Blog