Amazon's Threat Intelligence team recorded an attempt to exploit the newly disclosed PHP2Shell vulnerabilities on October 17, 2026 — four days before the coordinated disclosure was scheduled.
Amazon MadPot honeypot: an anonymized probe on October 17
Amazon said the October 17 probe targeted its MadPot honeypot service and originated from an IP address associated with a commercial anonymization network. The activity was recorded from 103.216.220[.]92, an IP geolocated to Australia, and was flagged while the vulnerability details were still under embargo. "While the vulnerability was under embargo, the targeting of a honeypot from an anonymized IP address suggests the activity was conducted by a threat actor, though it remains unclear how the actor acquired exploit information prior to disclosure," CJ Moses, CISO of Amazon Integrated Security, told The Hacker News.
CVE-2026-109618 and CVE-2026-109619: what the flaws are and whom they touch
The two PHP core vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, carry CVSS scores of 9.2 and were discovered by researchers from Calif, OpenAI, and Google-owned Wiz. The flaws can be abused to achieve pre-authentication remote code execution and are present in every PHP release from the 7.x and 8.x series. The PHP Foundation said both issues sit in parts of PHP that nearly every request touches — memory management and error handling — and described fixing them as difficult without creating compatibility or performance problems across the ecosystem.

Nobody's watching your logs at 2 AM.
Full SOC coverage without building one. Nubivance deploys and manages Rapid7 InsightIDR and MDR for organizations that need detection and response, not another dashboard.
Get coverageExploit activity around the public fixes: Oct 21–22 and anonymized infrastructure
The coordinated disclosure had been scheduled for October 22, 2026 at 2:00 p.m. UTC, but a leak of the CVE identifiers and a proof-of-concept exploit prompted the PHP Foundation to move the release forward by one day. Amazon reported multiple proof-of-concept exploits coinciding with the day of the release, with the earliest flagged around October 21, 2026 at 2:00 a.m. UTC. Additional attempts from anonymized infrastructure followed over the next six hours; Amazon said the variety of payloads and use of anonymization indicate multiple actors.
Amazon recorded exploitation attempts on October 21 from the following IPs:
- 31.223.184[.]166
- 37.19.200[.]5
- 134.209.159[.]64
- 103.114.163[.]188
- 95.217.98[.]37
ELLIO reported the first PHP2Shell request against its sensors on October 21 at 8:36 a.m. UTC — less than an hour after Chainguard "unilaterally broke the embargo and published built images containing the fix," according to ELLIO. The PHP Foundation said Chainguard had received the patch in advance so its users could update immediately but that publishing the built images disregarded coordinated-disclosure processes.
Attack stealth and the size of the exposure
CrowdStrike warned that exploits leave virtually no digital traces: "There is no authentication to bypass, no session to steal, and no vulnerable endpoint to discover," the company said. CrowdStrike added that worker processes remain stable, responses return HTTP 200, and application logs show no anomalies because no application code runs — the only server-side trace may be a memory-limit fatal in the web server's error log, which defenders often dismiss as noise.
That stealth matters because the attack surface is vast. Cloudflare noted that "PHP is used by almost 70% of websites" and that php2shell affects the PHP runtime itself, potentially allowing attackers to execute code, expose customer data, or disrupt services across platforms such as WordPress and Magento. VulnCheck identified PHP on 2,608,039 internet-facing hosts: over 700,000 run PHP 3.x through 7.3; about 400,000 run 7.4, 8.0, or 8.1; and 403,000 run supported 8.2 through 8.5 branches.
Industry advisories, mitigations, and observed probes
International cybersecurity agencies urged rapid action. The U.K. National Cyber Security Centre and the U.S. Cybersecurity and Infrastructure Security Agency warned organizations to apply fixes or consider taking affected services offline. The FBI posted on X: "Monitor web servers for suspicious activity, including PHP processes unexpectedly launching command shells or downloading files. Ensure appropriate process-monitoring capabilities are in place to help identify potential exploitation." The NSA said the vulnerabilities can provide threat actors a direct path to a server's file system or database.
Responses from vendors and operators included tool releases, patches, and blocking activity: OpenAI released a Codex skill to check sites or local binaries for vulnerability; CloudLinux published fixed packages for ea-php52 through ea-php85 and every alt-php version; Pantheon reported blocking over 60,000 suspicious requests probing the vulnerability; and Cloudflare said it observed actors mutating payloads to try to bypass protections.
VulnCheck identified specific hosts that targeted honeypots using a "php2shell-scan/109618" user-agent, and listed two such hosts (85.11.167[.]243 and 45.198.224[.]169) weaponizing CVE-2026-109618, while 109.71.252[.]97 leveraged both flaws.
How technologists, policymakers, and web operators are responding
Technologists and security teams: Ilkka Turunen, Field CTO at Sonatype, urged immediate accountability — know where PHP is used, who owns remediation, and how quickly fixes can be deployed — noting many environments will need patching because PHP is bundled into operating system distributions and historic environments.
Policymakers and regulators: Agencies such as the NCSC, CISA, FBI, and NSA have issued public warnings and monitoring guidance focused on rapid mitigation or temporary service removal to limit risk.
Web operators and enterprises: Operators are seeing large-scale scanning and automated probing — Cloudflare and Pantheon reported observable attack traffic — and vendors from CloudLinux to a long list of security providers have published patches, guidance, or mitigations to support remediation.
Amazon's finding that exploit attempts began before public disclosure, combined with CJ Moses's observation that "AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit," leaves a pointed operational question: in an environment where patch details and binaries can rapidly fall into adversaries' hands, how will embargoes, coordinated disclosure, and rapid patch deployment be reconciled to preserve the lead time defenders have historically relied on?




