Amazon’s Threat Intelligence team says it detected a PHP2Shell exploitation attempt on October 17 — four days before the two critical PHP flaws were scheduled for public disclosure.
Amazon’s MadPot sensors recorded an October 17 attempt
Amazon Web Services’ internal honeypot system, MadPot, flagged an exploitation attempt targeting the two PHP flaws now known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). The attempt originated from an IP address tied to a commercial anonymization network, which Amazon’s researchers say suggests activity by a “threat actor,” although it remains unclear how that actor acquired exploit information prior to disclosure.
Amazon also reports that multiple proof-of-concept (PoC) exploits were identified on October 21, around 12 hours before the vulnerability was due to be disclosed at 2pm GMT. The earliest of those PoCs appeared at approximately 2am GMT, with further attempts against MadPot sensors between 2am and 8am GMT from additional infrastructure. Variations in payloads and anonymization infrastructure led researchers to conclude multiple threat actors were likely involved; Amazon noted, however, that it was unclear whether the early attempts would have succeeded against real-world systems.
The flaws, their reach, and the patch set
The two bugs — CVE-2026-109618 and CVE-2026-109619, collectively dubbed PHP2Shell — can allow unauthenticated remote code execution (RCE) and potential server takeover on sites running affected PHP releases. PHP is used on roughly 69.7% of websites whose server-side language is known, according to W3Techs, and that includes many content management systems such as WordPress, Drupal, Joomla and Magento, as well as e-commerce and web services platforms.
PHP Foundation and the maintainers released fixes in the following versions: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The PHP project states that updating is the only complete fix for the two vulnerabilities. Official patches are available only for supported PHP branches (8.2 and later); PHP 8.1 and earlier — including all PHP 7 and PHP 5 releases — will not receive official fixes and are advised to migrate to a supported release urgently.
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 coverageLeak on Hacker News and immediate operational responses
Researchers at Calif and Google Cloud’s Wiz, with collaboration from OpenAI’s Patch the Planet project, discovered the bugs in August and scheduled public disclosure for October 21 so the PHP Foundation could publish patches. On October 20 a pseudonymous Hacker News user leaked information about the flaws before patches were ready, precipitating a rapid operational response.
That leak prompted a range of organizations to take precautionary steps: French public administrations, the Dutch National Cyber Security Centre, and the University of Vienna all took websites offline to prepare for and apply patches.
Exploitation volume, PoCs, and vendor mitigations
Multiple security vendors and threat intelligence teams have since reported exploitation attempts in the wild. Matthew Prince, co-founder and CEO of Cloudflare, said on X his company saw “thousands of attempts to exploit” the vulnerabilities within the 10 hours preceding disclosure, adding: “That jumped to tens of thousands in the 45 minutes post announcement, hundreds of thousands within two hours, and millions now.” Other firms reporting observations include Beelzebub, Ellio, Recorded Future, VulnCheck, WatchTowr and Wiz.
Independent researchers and some security teams released PoC exploits for the research community; Amazon said PoCs appeared hours before disclosure and were used against its sensors almost immediately after patches were published. While PoCs aid research, Amazon and others warned they also provide tools attackers can use to target unpatched systems.
Vendors have taken measures to blunt the immediate risk. Cloudflare said customers using its free or paid web application firewall (WAF) were protected by default against the vulnerability. The published mitigations for organizations that cannot patch immediately include disabling vulnerable functionality where possible; restarting PHP workers after configuration changes; strengthening perimeter defenses by restricting unnecessary multipart/form-data requests and enforcing limits on request body sizes, multipart sections and headers; and maintaining resource limits to reduce memory-exhaustion risk. The guidance from PHP and researchers stresses that these measures reduce exposure but do not replace patching.
What this means for security teams, public administrations, and vendors
- Security teams: Prioritize upgrading to the fixed PHP releases (8.2.35, 8.3.36, 8.4.27, 8.5.12) where possible; apply recommended mitigations immediately if you cannot patch, and monitor for PoC-derived indicators and anomalous multipart/form-data traffic.
- Public administrations: The leak-driven, pre-disclosure operational impact already forced some administrations offline; they will need rapid patching or temporary mitigations and a validated rollback plan for legacy PHP deployments that cannot be upgraded to supported branches.
- Vendors and service providers: Providers that control edge defenses (for example, WAF vendors) should verify protections are active for customers and communicate whether default rules shield against PHP2Shell; vendors hosting PHP stacks must inventory versions and accelerate migrations off unsupported branches (8.1 and earlier).
The record assembled so far shows early, pre-disclosure probing and a spike to large-scale scanning and exploitation attempts immediately after the patches were announced; whether these attempts have produced successful, real-world server takeovers remains to be seen. For organizations running PHP, the immediate imperative is clear in the PHP project’s own guidance: update to a fixed, supported release without delay.
