The php2shell bugs are no longer a warning about what could happen.
Over the weekend, researchers confirmed that attackers had not merely probed the two critical PHP vulnerabilities patched on 21 October, but had got code to execute. Adel Karimishiraz, who leads detection and response at Perplexity and runs his own PHP honeypots, published an analysis on GitHub showing that malicious code reached his sensors and ran. His count: 35 shells opened across three honeypots running PHP 8.4.26, with the attacks originating from two IP addresses.
The trail was visible earlier. In the first 26 hours after the patches shipped he logged dozens of attempts, 30 out-of-memory events and 11 crashed worker processes — noisy, but not proof of execution. On Saturday evening he wrote that he might have seen code run. The write-up settled it.
On Monday, CISA added the pair to its Known Exploited Vulnerabilities catalog: the US government's formal acknowledgement that exploitation is happening in the wild, and a patch deadline for federal agencies.
The flaws are CVE-2026-109618 and CVE-2026-109619 — unauthenticated remote code execution in PHP itself, reaching from PHP 5 through PHP 8. The PHP team rates both 9.2 under CVSS 4.0; the researchers who reproduced them put them at 10.0. The distinction is academic. What matters is that there is no workaround. PHP core developers have said the mitigations circulating online — disabling session.upload_progress, blocking multipart/form-data — do not reliably prevent exploitation. The patch is the fix.
Volume was never in doubt. Cloudflare's CTO reported attack attempts on the day the patches landed and said WAF rules were deployed; Amazon's infrastructure saw attempts in the millions. Many organisations took sites offline preemptively last week to patch, and most are back online.
The long tail is the problem now. Censys's scanner counted roughly 4.2 million PHP version strings matching vulnerable releases in Germany on Friday. On Tuesday morning it still reported more than four million. Censys is careful about its own number: several Linux distributions backport fixes onto older version numbers, so a service can advertise a vulnerable banner while running patched code. The figure is an indicator, not a census — but it is a large indicator.
For anyone running PHP, the order of operations has not changed. Patch first, everywhere: every container image, every build pipeline, every staging and demo host nobody has opened since 2019. The affected range starts at PHP 5, so the exposure is as much about forgotten infrastructure as about current production.
Then read the logs. The probes began the day the patches shipped. Any request in the past week's access logs that matches known exploitation patterns deserves a second look, and any host that sat reachable and unpatched during that window deserves more than a look.
The uncomfortable part is the speed. Five days separated “millions of attempts, none successful” from “confirmed shells, catalogued by CISA”. That is the normal shape of a widely deployed, unauthenticated RCE in a language that runs a large share of the web — and it is why “we'll patch in the next maintenance window” stopped being an acceptable answer last Tuesday.
