AWS says PHP2Shell exploit attempt came four days before disclosure
AWS says its MadPot honeypot captured a PHP2Shell exploit attempt on October 17, four days before disclosure. PHP users are being urged to install fixed releases immediately and review activity from that date, although the evidence does not establish a confirmed victim compromise.
Amazon Web Services says it detected a PHP2Shell exploit attempt in its MadPot honeypot telemetry on October 17, four days before the October 21 public disclosure of CVE-2026-109618 and CVE-2026-109619.
The timeline follows PHP’s release of fixes for the two critical RCE flaws. AWS recommends that investigations review activity from at least October 17, while the PHP project urges users to install fixed releases immediately. Both say upgrading is the only complete remediation for the two critical remote-code-execution flaws.
AWS traced the October 17 attempt to an IP address associated with a commercial anonymization network. The company said the targeting suggested threat-actor activity, but it does not know how the actor obtained exploit information before disclosure.
On October 21, AWS identified multiple proof-of-concept exploits, the earliest at around 02:00 UTC. It then recorded more attempts against MadPot from other anonymized infrastructure between 02:00 and 08:00 UTC. After patches were released at 14:00 UTC, AWS said additional proof-of-concept exploits appeared within hours and reached its sensors almost immediately. It described PHP2Shell as broadly exploited in the wild.
The telemetry records attempts against honeypots, not confirmed intrusions into victim systems. AWS said it was unclear whether any of the attempts would have succeeded in real-world systems. The opened official records do not identify a compromised organization or quantify affected systems.
The PHP project says versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix the flaws. It says every PHP installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest assessed risk for mod_php.
CVE-2026-109618 can allow code execution when an out-of-memory interruption leaves partially initialized request data that cleanup later treats as valid. CVE-2026-109619 can allow code execution when request-owned state survives after its backing memory is freed and is reused by a later request.
AWS recommends reviewing web-server logs for suspicious activity, checking for unexpected process execution or file modification, and searching form uploads for POST requests containing PHP_SESSION_UPLOAD_PROGRESS. The PHP project says temporary configuration changes may reduce exposure to specific attack paths, but they do not make an installation safe.
More news
PHP patches critical RCE flaws as Dutch government sites go offline
Critical Splunk Enterprise flaw rated CVSS 9.8 is under active attack as CISA sets a June 21 patch deadline
Dmytro Spodarets·Jun 21, 2026
CrowdStrike documents four agentic-AI hacking campaigns
