Technology & Science
AWS says PHP2Shell attempt reached a honeypot four days before disclosure
AWS says activity continued before patches were released and accelerated after disclosure. The company says it cannot tell whether the earlier attempts would have worked on real systems.
Executive summary
- The earliest attempt AWS reports was Oct. 17: Amazon Threat Intelligence says its MadPot honeypot network recorded an attempt to exploit the PHP2Shell flaws on Oct. 17, four days before public disclosure. The target was a decoy system; AWS has not reported a resulting compromise of a real PHP server.[1][2]
- AWS says more attempts followed before disclosure: AWS reports additional attempts from different anonymized infrastructure on Oct. 21, beginning about 12 hours before the patch release. It says the payloads varied and its analysis is ongoing, so it cannot determine whether these attempts would have succeeded against real systems or attribute them to a named actor.[1][2]
- The vulnerabilities have fixes; organizations need to check their PHP runtime: The PHP project released patched versions for supported PHP 8 branches on Oct. 21. It says all PHP installations serving web requests are potentially exposed. AWS recommends investigating activity from Oct. 17 onward; its listed IP addresses include shared anonymization infrastructure and should be investigated rather than automatically blocked.[3][1][4]
Amazon Threat Intelligence said its MadPot network recorded an attempted exploitation of PHP2Shell on Oct. 17, four days before the PHP project publicly disclosed two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The attempt targeted an AWS honeypot, a decoy system designed to attract and study malicious activity. AWS has not said that a customer or other real-world PHP server was compromised in this incident.[1][2]
AWS said the source address was associated with a commercial anonymization network. That can obscure an operator’s origin, but it does not identify the person or group behind the attempt. The company said it remains unclear how the actor obtained information about the flaws while they were under embargo.[1][2]
AWS said it saw multiple proof-of-concept exploits on Oct. 21, with the earliest appearing around 02:00 UTC, and further attempts against MadPot between 02:00 and 08:00 UTC. The public disclosure and patch release were scheduled for 14:00 UTC. AWS said the payloads and anonymization services varied, suggesting multiple actors, but its analysis was still underway and the observed attempts might not have worked against real systems.[1][2]
After the disclosure and patch, AWS said additional proof-of-concept code appeared within hours and was used against its sensors almost immediately. It described PHP2Shell as being broadly exploited in the wild, a characterization of activity its sensors observed rather than a tally of confirmed victim compromises. Reuters separately reported the pre-disclosure honeypot attempt and AWS’s caution that success against real websites was unknown.[1][2]
The PHP project’s Oct. 21 security release identifies fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. It says PHP installations that serve web requests are potentially affected, with the greatest risk in Apache deployments using mod_php. Administrators using older branches should check whether their distribution or hosting provider has supplied a backported fix; PHP 8.1 and earlier no longer receive ordinary upstream security releases.[3][4]
AWS advises organizations to begin reviewing logs from at least Oct. 17, not just from the public release date, and to check for suspicious requests, unexpected process execution or file changes. Its indicators include addresses on shared anonymization services, which AWS says are not exclusive to this activity. The company recommends investigating matches instead of treating an address alone as proof or automatically blocking it.[1]
The finding changes the timeline defenders should consider, but leaves key questions unanswered: AWS has not attributed the activity, established how the actor learned about the flaws, or said the early attempts compromised a live target. The immediate response remains to apply a vendor-supported fix and review the period before patching, while keeping sensor observations distinct from confirmed victim incidents.[1][2][3]