Amazon saw PHP2Shell attack attempts four days before disclosure

Someone tried to exploit PHP2Shell four days before most defenders knew it existed. Amazon says its MadPot honeypot network logged an attempt against the two PHP flaws on October 17, 2026. The fixes and the public disclosure did not arrive until October 21 at 14:00 UTC. Amazon now says the bugs are being broadly exploited.

PHP fixed the two flaws, CVE-2026-109618 and CVE-2026-109619, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on Wednesday. Both are rated 9.2 and can let an attacker run code on a web server without logging in. Amazon's timeline means a server patched on Wednesday may still have been attacked before then.

What Amazon saw

MadPot is Amazon's network of honeypots, decoy servers built to attract attackers and log what they do. In the AWS Security Blog post, Amazon lays out what its sensors recorded.

Time (UTC)	What happened
October 17	MadPot logs the first attempt, from an address tied to a commercial anonymization network
October 20	The CVE IDs circulate on Hacker News and social media, Tenable reports
October 21, about 02:00	The earliest proof-of-concept exploit appears, about 12 hours before the fixes
October 21, 02:00 to 08:00	More attempts arrive from other anonymized infrastructure
October 21, 14:00	The embargo lifts and the fixes are released

The October 21 attempts used varied payloads and infrastructure, which Amazon says suggests more than one attacker. After the release, more exploits appeared within hours and reached Amazon's sensors almost immediately.

Amazon is careful about what it does not know. Its sensors are decoys, so it cannot say whether the early attempts would have worked on real systems. Amazon also writes that "it remains unclear how the actor acquired exploit information prior to disclosure." The October 17 attempt came three days before the CVE IDs leaked.

How the embargo broke down

An embargo is the quiet period when a project and its partners prepare fixes before anyone announces a bug. PHP2Shell's embargo did not hold.

According to Tenable and The Hacker News, the PHP Foundation first planned the release for October 22. It moved the date up a day after the CVE IDs leaked. The Register reports that the foundation also accused Chainguard, which publishes container images, of releasing patched builds before the agreed deadline. "Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release," the foundation said, as quoted by The Hacker News. The reports do not include a response from Chainguard.

How big the attack wave is

Cloudflare chief executive Matthew Prince posted counts on X. Cloudflare saw thousands of attempts in the 10 hours before the announcement. That rose to tens of thousands within 45 minutes after it and hundreds of thousands within two hours. Prince now puts it at "millions."

Hosting company Pantheon blocked more than 60,000 suspicious requests, The Hacker News reports. Cloudflare says attackers keep changing their payloads to slip past its firewall rules. None of these counts confirms a successful break-in. They show attempts that were blocked or recorded.

The Hacker News quotes Amazon security chief CJ Moses on why this keeps happening. "AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit."

What this means for developers

If you run PHP, your investigation window starts on October 17, not on the day you patched. Amazon puts it plainly: "Start investigations from the earliest known exploitation, not from the disclosure date."

• Patch first. Install 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart every PHP worker so the new code actually runs. Amazon says only upgrading fully fixes both flaws.
• Search your logs for the known pattern. Amazon says to look for POST requests that contain the string PHP_SESSION_UPLOAD_PROGRESS in form uploads. Security firm Hadrian says most attacks it sees abuse this session upload-progress path.
• Look for signs that code ran. Check servers for unexpected processes and changed files. The FBI says to watch for PHP processes that launch command shells or download files.
• Use stopgaps only while you patch. PHP's own list includes setting session.upload_progress.enabled=0 and restarting workers. Amazon also suggests blocking multipart file uploads if your app can live without them.
• Do not trust public exploit code. JFrog reports fake PHP2Shell exploits and prank malware on GitHub. Tenable warns that circulating code may hide malware.
• Investigate the listed IP addresses, but do not rely on blocking them. Amazon publishes six of them but advises investigating rather than blocking, since they belong to shared anonymization services.