PHP2Shell: the attacks began four days before the patch

Four days before PHP disclosed the two flaws, the first exploitation attempt was running. Amazon Threat Intelligence found it in the telemetry of its MadPot honeypot network, dated 17 October 2026. Close PHP2Shell the moment the version number is right and you have checked four days too few.

What Amazon saw before disclosure

Amazon Threat Intelligence published on 21 October that the earliest PHP2Shell exploitation attempt in its MadPot telemetry dates to 17 October 2026 — four days before disclosure, three days before the leak. The request came from a commercial anonymisation network and hit a honeypot, which Amazon reads as a sign of a threat actor rather than research. How the actor obtained exploit information beforehand is unclear.

From 02:00 UTC on 21 October, twelve hours before the 14:00 UTC release, MadPot saw several proof-of-concept exploits from further anonymised infrastructure. Payloads and origins differed, which points to several independent actors; whether any would have worked against real systems is left open. CJ Moses, CISO of Amazon Integrated Security, sums up the state after the release: "PHP2Shell is now being broadly exploited in the wild." Mechanism, fixed versions and interim measures are in yesterday's post.

How exploits arrived before the patch

17 October remains unexplained. The twelve hours before the release do not. The PHP Foundation laid out that chain in its postmortem of 21 October:

The Foundation objects not to the early fix but to its comparability: "Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release." Chainguard CEO Dan Lorenc does not dispute the timing, but he does dispute the reading: "I made the call to get these out early when exploits hit in the wild." The Foundation's own security team had identified no functional public exploit by release time, and calls the delay since the first signs in 2024 "a structural failure".

Status on 22 October: millions of attempts, no confirmed breach

No successful break-in through PHP2Shell has been confirmed. The number of attempts has. Cloudflare CEO Matthew Prince reports thousands across his network in the ten hours before the announcement, tens of thousands in the 45 minutes after, hundreds of thousands within two hours and millions by now. Cloudflare also sees attackers varying payloads and reading which requests the web application firewall blocks.

Volume is not success. Jake Knott of watchTowr says none of the circulating proof-of-concepts achieves code execution: they fail, measure timing differences, or crash the target process. VulnCheck saw at least one address trying, unsuccessfully, to drop a web shell. Germany's BSI states in version 1.1 of its 21 October warning that no confirmed exploitation is known so far. Neither number appears in the CISA KEV catalogue as of 22 October. JFrog also found fake exploits and prank malware in public repositories — test that code against your own systems and you may be testing something other than the flaw.

What this means for your investigation

Amazon recommends starting the investigation window on 17 October, not on patch day. In practice the first step is preserving evidence before rotation deletes it: web server logs and the process and file state of every reachable PHP system from 16 October.

• Requests: POST requests carrying the string PHP_SESSION_UPLOAD_PROGRESS in multipart/form-data bodies, plus clusters of HTTP 500 responses and crashed PHP workers.
• Processes: any shell, interpreter or download tool started by php-fpm, php-cgi, httpd or apache2, plus new files in the web root.
• Detection without signatures: Amazon recommends detections that do not depend on CVE-specific signatures — first exploitation regularly precedes the first signature.
• Indicators: Amazon publishes six addresses from its telemetry. They belong to shared anonymisation infrastructure and are not exclusive to this activity: a reason to investigate, not a block list.

103.216.220.92     17.10.2026
31.223.184.166     21.10.2026
37.19.200.5        21.10.2026
134.209.159.64     21.10.2026
103.114.163.188    21.10.2026
95.217.98.37       21.10.2026

On the deadline such cases set, Amazon's driest sentence matters most: "A 7-day or 30-day SLA assumes a delay that no longer exists." The reason is structural and not limited to PHP: AI-assisted analysis makes it cheaper to turn a patch diff or an advisory into a working exploit.

What helps — and why visibility decides

A deadline measured in hours assumes the inventory exists when the advisory lands. Between 17 and 21 October it was the only usable information there was.

blacklens.io uses Attack Surface Management to track which services and web applications are reachable from outside and which technologies run on them; internal systems are covered by the Sentry Agent. The Threat Center matches new CVEs against that inventory and shows, per hit, the EPSS score, KEV membership, available exploits and whether the match rests on the exact version or only on the product. Hunting on the host itself is not part of that; logs and monitoring on the system cover it.