Amazon Threat Intelligence recorded active PHP2Shell exploitation on 2026‑10‑17, well before the public CVE‑2026‑109618 and CVE‑2026‑109619 advisory was lifted on 2026‑10‑21. Practitioners who operate PHP services need to treat the window between vulnerability discovery and public disclosure as a real risk period and adjust their response processes accordingly.
Early exploitation and the limits of embargoes
The first observed attempt originated from an IP address linked to a commercial anonymization network, indicating a threat actor was able to obtain exploit details while the vulnerability remained under embargo. Subsequent traffic from additional anonymized sources between 0200 UTC and 0800 UTC on 2026‑10‑21 showed varied payloads, suggesting multiple actors were testing the same flaw. The fact that exploitation predates the advisory demonstrates that coordinated disclosure does not guarantee a clean pre‑release window.
Accelerating exploit development
Proof‑of‑concept exploits appeared within hours of the embargo lift, and AWS sensors saw active attempts almost immediately. The source notes that AI‑assisted analysis can turn a patch diff or advisory into a working exploit quickly, reducing the traditional lag where only a few capable actors could produce exploits. For engineers, this means the time from patch release to a functional exploit can now be measured in minutes rather than days, eroding the safety margin of traditional patch‑and‑wait strategies.
Operational response recommendations
Amazon outlines several immediate actions: upgrade to the patched PHP versions, block multi‑part file uploads where patching is delayed, and monitor for POST requests containing the PHP_SESSION_UPLOAD_PROGRESS string. Log analysis should focus on unexpected process execution, file modifications on web servers, and traffic from the listed IP addresses (e.g., 103.216.220.92 on 10/17/2026). AWS leverages its MadPot honeypot network and a threat‑intelligence pipeline that processes over 200 billion events per minute to automatically detect and restrict malicious scanning attempts. Practitioners should consider integrating similar telemetry feeds into their own detection stacks and avoid relying solely on CVE‑specific signatures, as the first exploitation often precedes signature availability.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Adopt hour‑scale service‑level expectations for patching critical internet‑facing components. Initiate investigations from the earliest known exploitation date rather than the public disclosure date. Deploy behavior‑based detection that looks for anomalous multipart uploads, unexpected PHP session progress strings, and activity from anonymized IP ranges. Finally, treat honeypot or threat‑intelligence telemetry as an early warning source and incorporate it into automated response playbooks.
