« Weather safety information will be broadcast on our social networks in the meantime as we restore our […] services. »
On Wednesday, October 21, Météo France made this announcement. It had just taken its forecast site and its Vigilance site offline. The reason: the presence of two “critical” vulnerabilities affecting PHP.
The sites of prefectures underwent the same treatment. The City of Paris, among others, also had to temporarily disconnect. As did the CNIL.
The incident obviously did not stay limited to public bodies. Orange, for instance, disconnected “a few websites, services and applications within several subsidiaries and entities.”
PHP signals a third vulnerability
In the Netherlands, the Tweede Kamer, the lower house of Parliament, also had to temporarily shut down its website. the national CERT did the same. It now says it is investigating “early signs of successful exploitation” of the two vulnerabilities. The situation could deteriorate quickly, it adds, as PoCs are public.
Eye Security acknowledges this, but does not think a generic exploit is possible. That said, it notes the risk of targeted attacks. But, according to it, no apocalypse is to be expected.
The German ANSSI (BSI) is less affirmative. It nonetheless asserts it is not aware of a “generalized and successful exploitation.” Despite rumors, it says, the patches are effective.
The PHP project has just tempered expectations: even with patched versions, a case of RCE can still occur. It has assigned a specific identifier to it (CVE-2026-115560). However, it requires an “unusual” combination of configuration and application code that leads to a mismatch in the session handler. In this context, there is no planned fix outside the regular release cycle.
The PHP patches rippled through Linux distributions
Current patches include patched versions of PHP 8.2, 8.3, 8.4 and 8.5, along with a minimal backport for three older versions (7.4, 8.0 and 8.1).
Canonical has patched the current Ubuntu (26.10), which uses PHP 8.5. It has done the same for the last three LTS versions (26.04, 24.04 and 22.04, which respectively use PHP 8.5, 8.3 and 8.1). For Ubuntu Pro subscribers, it has backported four more versions: 20.04 (PHP 7.4), 18.04 (7.2), 16.04 (7.0) and 14.04 (PHP 5).
The Debian project has integrated fixes for PHP 8.2 and 8.4, respectively in the Bookworm and Trixie branches. Freexian has backported on Sketch (PHP 7.0), Buster (7.3) and Bullseye (7.4).
At Red Hat, outside extended support, the fixes cover RHEL 8 (PHP 8.2 & 7.4), RHEL 9 (8.3 & 8.2) and RHEL 10 (8.4).
SUSE has been brought up to PHP 7.4, for openSUSE 15.6/15.7 and SLES 12/15.
70% of the web under threat? The attack surface in numbers
The two flaws lie in the core of PHP: the Zend engine, which compiles the source code into bytecode, executes it, and manages everything the language needs. Their position in the execution stack increases their criticality. There is indeed a possibility to trigger them even before any extensions are initialized or any line of application code is compiled.
In this context, a commonly cited statistic circulates: 70% of the web would be affected. The source, when provided, often points to W3Techs. This platform analyzes the market share of web technologies. Among sites where the server-side language is known, nearly 70% indeed use PHP.
| Branch | Version | Share | Distribution |
|---|---|---|---|
| PHP 8 Total: 45.3% |
PHP 8.6 | < 0.1% | |
| PHP 8.5 | 2.0% | ||
| PHP 8.4 | 5.5% | ||
| PHP 8.3 | 15.8% | ||
| PHP 8.2 | 12.5% | ||
| PHP 8.1 | 6.8% | ||
| PHP 8.0 | 2.6% | ||
| PHP 7 Total: 18.6% |
PHP 7.9 | < 0.1% | |
| PHP 7.5 | < 0.1% | ||
| PHP 7.4 | 13.7% | ||
| PHP 7.3 | 2.0% | ||
| PHP 7.2 | 1.6% | ||
| PHP 7.1 | 0.7% | ||
| PHP 7.0 | 0.7% | ||
| PHP 5 Total: 5.3% |
PHP 5.6 | 2.9% | |
| PHP 5.5 | 0.4% | ||
| PHP 5.4 | 0.8% | ||
| PHP 5.3 | 0.8% | ||
| PHP 5.2 | 0.4% | ||
| PHP 5.1 | < 0.1% | ||
| PHP 5.0 | < 0.1% | ||
| PHP 4 Total: < 0.1% |
All versions combined | < 0.1% | |
| Total of servers running PHP | ≈ 69.2% | PHP 8, 7, 5 and 4 | |
| Servers not using PHP | ≈ 30.8% | Other technologies / languages | |
Where the “botnet” Mirai resurfaces
On October 20, the day before the fixes were published, a PoC leaked. As a result, the PHP project issued an early alert.
AWS identified attack attempts after this leak. It states, however, that it detected one as early as October 17. It originated from an IP address linked to a commercial anonymization network.
Ellio also observed attacks before the fixes were published. The first clearly relied on the leaked PoC. Its user-agent included the string “php2shell” and the identifier of the first CVE (109618). It also contained the download session-tracking field specific to the other vulnerability (109619).
Shortly after the patches were released, attack attempts reused the information from the security bulletin. They focused on another vector besides upload sessions. Specifically, the memory-exhaustion vector. Ellio again found requests characterized by dozens of nesting levels and large bodies (hundreds of kilobytes). It observed payloads ranging from a RAT written in Go to an IIS webshell, and a 64-bit Mirai IoT botnet version for servers that could, among other things, open an interactive shell on a pseudo-terminal.
Two vulnerabilities, many attack paths
For memory-exhaustion, the first vulnerability was introduced with PHP 7.3 (December 2018) and targets the hash-table implementation. The idea is to send a POST request large enough—yet still appearing to fall within PHP’s limits—to trigger a memory exhaustion (OOM). When this condition occurs, Zend raises a fatal error. Execution stops, leaving partially initialized data that the cleanup process may then treat as valid, enabling arbitrary code execution.
All of this requires only a single request: it corrupts the data and the payload executes during cleanup. The second vulnerability uses the same data-corruption reuse mechanism but is less autonomous. It needs a poisoning step, followed by a targeted trigger against the same worker. In exchange, it reaches a larger set of internal states. The two recognized attack paths are found in code lines introduced with PHP 7.1 and 5.4. Malicious data are deserialized before any application code runs. Consequently, no application logic can block it, and every PHP endpoint (static forms, authentication routes, health probes, etc.) becomes an attack surface.
When patching is not possible, the main mitigation for the first vulnerability is to set memory_limit = -1. At the firewall or network edge, you can block requests that exceed a certain size threshold. This is not possible for the second vulnerability, where requests typically weigh a few hundred bytes. In that case, the best fallback is to disable upload-session tracking. Many European CERTs—Estonia cited as an example—confirm this.
The mitigations for the second vulnerability also apply to CVE-2026-115560.
From the Codex skill to Zeek rules, defense takes shape
Cloudflare did not wait for the patches to be released, deploying rules on its WAF to protect its clients. Its CEO says the attacks numbered in the thousands in the hours leading up to the announcement and in the tens of thousands in the final moments.
OpenAI, for its part, published a PHP version verifier as a Codex skill. Meanwhile, Corelight released detection packs for Zeek and Suricata.
The Suricata pack contains three rules. One targets “a unique and rare marker” in HTTP POST bodies. The others detect PHP versions by examining the banner in response headers and the standard HTML content produced by phpinfo().
The Zeek pack includes 9 alert types, among which are:
- An abnormally long field name
- Excessive repetition of a MIME header pattern in a multipart
- An abnormally large representation of a serialized integer token
- Suspect HTTP transactions correlated and tied to the same session within a defined time window
Who benefits from the killer PoC?
The CERT of Luxembourg recommends paying particular attention to:
- Sites, APIs, and applications exposed to the Internet
- Shared/multi-tenant hosting environments relying on persistent workers
- CMS, e-commerce platforms and administration interfaces
- Containers, VM images, appliances, and hosting control panels that bundle their own PHP runtime
Its Czech counterpart lists several signals to watch on affected servers. Among them:
- Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses
- Unusually large PHPSESSID cookies in responses
- unexplained restarts of PHP processes
In parallel, AWS suggests blocking multipart requests at the frontend for applications that do not need file uploads.
Abstract offers the same guidance. It also highlights indicators to monitor, including fatal errors containing the phrase Unknown on line 0 — indicating memory exhaustion upstream. It also notes reproducing an RCE, in two requests, from CVE-2026-109619 on a fully patched PHP 8.2 host. According to it, the patch resolved issues with stale-state consumers but not the producer. The session-tracking mechanism for uploads still writes the filename under an attacker-controlled identifier, advocating disabling this mechanism.
watchTower says it managed to reproduce the CVE-2026-109618 flaw. CrowdStrike also claims a functional PoC remains reliable despite worker restarts. And on ARM, it circumvents ASLR (address space layout randomization) using only HTTP requests.
The same PoC claims are echoed by JFrog. It notes, however, that counterfeit PoCs—“for hoaxes,” propagated by malicious actors who exploit confusion—are circulating.
ESET observed exploit attempts, but “still limited.” It notes scanning activity, but no widespread or significant compromise at this stage.
Border equipment vulnerabilities too
Numerous CERTs emphasize the need to watch gateways and other edge devices.
At F5, the BIG-IP is affected at two levels: the control-plane configuration utility and the data plane APM/SSLO. No patch is available yet.
Citrix lists several fronts where NetScaler management portals rely on PHP across multiple interfaces. The company plans fixes for October 27.
Cisco currently lists two families of affected products. For the URWB (Ultra-Reliable Wireless Backhaul) equipment, a fix is scheduled for February 2027. For the Expressway and Expressway Select gateways, the date is yet to be determined.
Sophos catalogs a vulnerable component: the MyUTM portal. It is a hosted license-management service for SG UTM firewalls, which reached end-of-life in June 2026. While a patch is awaited, MyUTM has been disconnected.
For its DSM operating system, Synology has patched up to PHP 7.4. It has provided updates for two other affected packages: Mail Station and Synology Calendar.
At QNAP, half a dozen products are impacted, starting with QTS. No patches are available yet. But there is a call to disable the PHP server if it is not used.
