Amazon says PHP2Shell attacks began four days before patches

Amazon Web Services says its MadPot honeypot network recorded a PHP2Shell attack attempt on Oct. 17, four days before patches and public disclosure for two critical PHP flaws. The finding means security teams investigating PHP2Shell attacks Amazon observed should begin their review before the Oct. 21 release date, although AWS says it does not know whether the early activity could have compromised a production system.

The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were patched on Oct. 21. Datadog assigns both a CVSS v4.0 score of 9.2. The flaws sit in PHP itself, rather than in an individual application, and affect PHP runtimes serving HTTP requests, including Apache modules, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed.

What did Amazon observe before the PHP2Shell patches?

AWS said the Oct. 17 request reached MadPot from an IP address associated with a commercial anonymization network. The company said that pattern indicated likely threat-actor activity, but it has not determined how the operator obtained exploit information while the vulnerabilities remained under embargo.

The embargo was due to lift at 1400 UTC on Oct. 21. AWS said it identified the first public proof-of-concept material at about 0200 UTC that day, then observed further targeting of its sensors from 0200 to 0800 UTC. Differences in payloads and anonymization services led AWS to assess that more than one actor may have been involved. Its technical analysis remains underway, and the company said it was unclear whether those attempts would have succeeded against real deployments.

That distinction matters. An attempted exploit, a probe and publicly available proof-of-concept code do not establish successful remote code execution or a breach. The PHP Foundation's executive director told Wired that, to the foundation's knowledge, there had been no successful remote-code-execution attempt.

Millions of attempts are not millions of compromises

Exploit traffic rose sharply around disclosure. Cloudflare CEO Matthew Prince said the company saw thousands of attempts during the 10 hours before the announcement, tens of thousands 45 minutes afterward, hundreds of thousands within two hours and millions later. Those figures describe observed exploit attempts across Cloudflare's network, not confirmed takeovers of servers.

AWS said additional proof-of-concept exploits appeared within hours of the patch release and were used against its sensors almost immediately. It characterized PHP2Shell as seeing broad exploitation attempts in the wild. Separately, SecurityWeek reported that WatchTowr had seen broad activity but said some circulating proof-of-concept code did not work, only tested timing differences or crashed targets.

What should PHP operators do?

Fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Datadog says patching is the only complete remedy. Organizations running older branches should check vendor advisories; PHP supplied source backports for 7.4, 8.0 and 8.1, according to Datadog.

• Inventory every HTTP-serving PHP runtime, including containers and products that bundle their own interpreter.
• Apply vendor or upstream updates, rebuild and redeploy images, then restart or replace workers running the old runtime.
• Review activity from at least Oct. 17, AWS said. It specifically advises checking form-upload POST requests containing PHP_SESSION_UPLOAD_PROGRESS.
• If an exposed system cannot be patched immediately, restrict public access and use reverse-proxy or other boundary controls to stop requests before they reach PHP. AWS also suggests considering blocking multipart uploads after evaluating the application impact.

AWS argues that the window for critical internet-facing defects should be measured in hours rather than seven- or 30-day remediation targets. That is AWS's assessment of the changing exploit cycle, not an explanation for who conducted the Oct. 17 attempt.

This story draws on original reporting from SiliconANGLE.