AWS saw PHP2Shell attack attempts four days before public disclosure

Amazon’s threat-intelligence team says its MadPot honeypot network saw PHP2Shell attack attempts on 17 October, four days before the public advisory for two critical PHP vulnerabilities. The observation shows that defensive planning cannot assume exploitation begins only after a scheduled disclosure.[1]

The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, affect PHP’s handling of memory and request state and can allow unauthenticated remote code execution under relevant conditions. PHP released fixes on 21 October in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35.[2][3]

What the honeypot timeline establishes

AWS reports an initial attempt on 17 October. It also describes a proof of concept appearing at about 02:00 UTC on 21 October and further attempts between 02:00 and 08:00 UTC, before the advisory’s 14:00 UTC embargo expired. This provides a concrete sequence of observed activity rather than an estimate of how quickly an attacker might act.[1]

In its 21 October account, AWS cautioned that it could not establish whether the early attempts would have succeeded against real systems. That limits what can be concluded about those particular observations; it does not make the vulnerable software safe to leave exposed. The record supports early attempted exploitation, not an invented count of compromised organisations.[1]

The article also discusses AI as a factor that may accelerate exploit development. That is AWS’s assessment of the changing threat environment. The honeypot observations themselves do not prove that a particular attacker used AI to generate the traffic or that AI caused the pre-disclosure activity.[1]

Inventory and patching need to cover embedded PHP

PHP can sit inside a web application, a server image or a third-party product. Finding only the systems labelled “PHP” in an asset register can therefore miss dependencies. The UK National Cyber Security Centre advises organisations to identify PHP across their infrastructure, prioritise internet-facing systems and watch for updates from vendors that bundle it.[3]

AWS’s security bulletin describes updating to a fixed release as the complete remediation for the two original issues. Temporary configuration changes or a web application firewall can reduce exposure while patching proceeds, but should not be represented as an equivalent permanent fix.[4]

A separate issue, CVE-2026-115560, was disclosed on 23 October and is not addressed by the 21 October releases. It depends on an uncommon combination of configuration and application behaviour involving changes to the session serialisation handler at runtime. PHP’s additional advisory provides a mitigation for that case. This is a distinct follow-up issue, not evidence that the two original fixes were withdrawn.[2]

The operational lesson is to connect disclosure monitoring with a maintained dependency inventory and a tested update path. The four-day lead in MadPot’s observations shows why the time required to identify an affected service can matter as much as the time required to install its patch.[1][3]

Report an error or suggest a correction