A flaw beneath the application
On October 21, the PHP project issued emergency releases for two critical vulnerabilities that can allow an unauthenticated attacker to execute code on a web server. The fixed versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The project said all PHP installations serving web requests were at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed; it considered mod_php the highest-risk configuration because a demonstrated exploit could run before application code.
The two faults sit inside the runtime rather than a particular website. CVE-2026-109618 involves out-of-memory handling interrupting PHP while request data is only partly initialized, after which cleanup can treat invalid data as valid. CVE-2026-109619 involves request-owned global state surviving after its backing memory has been freed. In both cases, the result can cross the boundary between malformed web traffic and server-side code execution.
The timeline became part of the incident
Cloudflare said the vulnerabilities, collectively called php2shell, affect PHP web servers from version 5.4 onward. The company had developed protections with the PHP Foundation and other researchers and enabled default web-application-firewall rules for its customers at 03:02 UTC on October 21, roughly nine hours before public disclosure. It also said vulnerability information leaked before the planned release and that it saw attackers mutate payloads while trying to evade defenses.
Reuters reported a steep rise in attempts after disclosure. Cloudflare counted thousands in the ten hours before the public announcement, tens of thousands during the following 45 minutes, hundreds of thousands within two hours and then millions. Those figures describe attempts observed across Cloudflare's network, not millions of confirmed compromises. Public reporting reviewed for this draft does not establish how many attacks succeeded.
Precaution became an outage
The response disrupted services even where no compromise was confirmed. Reuters reported temporary suspensions affecting banking, airline, rail, tax and government websites from Japan to Finland. Japanese organizations including Nomura, Mitsubishi UFJ, ANA and East Japan Railway paused some online services. Finland's state IT provider said it was gradually lifting precautionary blocks after patching and testing, and explicitly said its outages were not caused by exploitation or a breach.
That distinction is essential. A security emergency can produce three different events at once: exploit traffic, confirmed intrusion and defensive shutdown. Combining them into one claim would exaggerate the evidence. In this case, the verified operational harm includes organizations deliberately taking public services offline because the time available for safe patching and validation had collapsed.
Lessons from a shared runtime
The first lesson is inventory. Teams need to know which services execute PHP, which runtime and server interface each uses, who owns the upgrade and whether the branch still receives fixes. CERT-FR listed every PHP 5.x, 6.x, 7.x, 8.0.x and 8.1.x release as affected, along with unpatched versions in supported 8.2–8.5 branches. An application inventory that stops at “WordPress” or “custom site” misses the vulnerable layer underneath.
The second lesson is that compensating controls are bridges, not destinations. Cloudflare's WAF reduced exposure and used request-and-response signals to distinguish likely exploitation, but the PHP project's instruction was to update immediately. Operators should rehearse how to isolate an unpatchable service, preserve logs, rotate credentials if compromise is suspected and return it only after both the runtime and the application have been tested.
Finally, coordinated disclosure is an operational dependency. When details escape before fixes are ready, defenders lose the orderly sequence of inventory, staging, deployment and validation. Emergency plans should assume that sequence may fail. The useful measure is not merely patch speed, but how quickly an organization can reduce exposure without turning every critical web service into an improvised shutdown.
What remains uncertain
The reviewed sources do not establish how many systems were successfully compromised, whether the millions of observed attempts were unique attackers or targets, or the full number and duration of precautionary service suspensions. Attribution to specific attackers would be premature. Reports that AI assisted discovery or exploitation are not necessary to the core finding and should not be used to imply autonomous attacker responsibility without stronger evidence.
Sources & method
AI-assisted research and drafting, reviewed by the editor before publication. Reporting is attributed to the sources below; this is not an independent forensic investigation.
- Security advisory: Critical remote code execution vulnerabilities, update now · Original source · 2026-10-21
- Multiples vulnérabilités dans PHP · Original source · 2026-10-21
- Cloudflare deploys protections against php2shell vulnerability · Original source · 2026-10-21
- Millions of hacking attempts as companies, governments rush to patch PHP flaws · Reporting · 2026-10-22