PHP2Shell: Two Critical RCE Flaws Force an Emergency PHP Patch

No authentication required, maximum risk on the most common configurations, and attacks already observed before the patch even shipped. While checking our own infrastructure to write this article, we found an unprotected instance — fixed within the hour.

October 22, 2026 · SunuCyberSecurity Team

Sources: PHP security advisory, Canadian Centre for Cyber Security, BleepingComputer — full list at the end of this article

On October 21, 2026, the PHP project shipped an emergency patch for two critical flaws, nicknamed "PHP2Shell" by the researchers who found them. Tracked as CVE-2026-109618 and CVE-2026-109619, they let an unauthenticated attacker execute arbitrary code on any server exposing PHP — which, given PHP's ubiquity across the African web (WordPress, business applications, admin panels), covers a substantial share of the region's online infrastructure.

What these two flaws actually are

Both CVEs are classified as Use After Free (CWE-416) — a memory-safety bug category where a program keeps using a memory region after it has been freed, letting an attacker manipulate it to hijack execution. The common thread: PHP can leave its internal memory corrupted when a request terminates abnormally.

CVE-2026-109618 exploits that memory corruption through a chain of weaknesses to achieve code execution with the web worker process's privileges. CVE-2026-109619 relies on stale global state: a later request, handled by the same worker, can reuse state that was never properly reset — opening the door to memory disclosure and, again, code execution.

Both flaws are rated 9.2 out of 10 in CVSS v4.0 by PHP's own security team. Importantly, the risk isn't uniform across deployment modes. PHP rates the risk as highest on mod_php (the classic Apache module) — a demonstrated exploit lets the attack trigger via a plain unauthenticated request, before the targeted application's code even runs. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are affected too, with exploitability varying by exact configuration.

Affected versions and fixes

PHP 8.1 and earlier no longer receive fixes from the PHP project itself — some Linux distributions (through their own LTS repositories) may offer a backport, but that's not guaranteed. If your infrastructure still runs one of these branches, the real fix is the version upgrade, not a one-off patch.

Exploitation: what we know as of writing

The situation is moving fast and sources don't all agree. What's confirmed: before the patch even officially shipped, Cloudflare CTO Dane Knecht publicly stated that Cloudflare was already seeing attack attempts targeting both flaws — a strong signal that technical details leaked ahead of the patch. UK's NCSC, for its part, warned organizations to update immediately or cut public access to affected systems. The PHP project itself stayed cautious in its own advisory, not confirming widespread exploitation on its end at release time, while acknowledging the situation could change quickly.

A notable detail on discovery: both flaws were found with the help of AI tooling, by Wiz's research team working with OpenAI — a concrete illustration that AI is increasingly used for defense too, not just offense.

Update, October 22, later in the day: Cloudflare confirms it started filtering exploitation attempts as early as 03:02 UTC on October 21 — before the official patch even shipped at 16:00 — and observed attackers altering their payloads to evade its filtering rules. In France, CERT-FR published the official alert CERTFR-2026-ALE-014, recommending isolating affected machines and updating without delay.

The real-world impact: sites taken down as a precaution, not hacked

In France, the Interior Ministry took all its exposed sites offline — the Paris police prefecture and the prefectures of Seine-Saint-Denis, Hauts-de-Seine, Val-de-Marne, Essonne, Gironde, Bouches-du-Rhône and Savoie — explicitly stating it was acting "at ANSSI's request" (France's national cybersecurity agency). The Finance Ministry, Météo-France (which confirmed the link) and Les Echos did the same. Ameli (health insurance), CAF (family benefits), URSSAF, the tax portal, and the CNES (space agency) site were also disrupted or taken down, without always confirming or denying a link to the flaw. The City of Paris and the Lille metropolitan area also cut some services.

Elsewhere in Europe: Germany's federal digital administration (ITZBund), Belgium's Ministry of Foreign Affairs, several Finnish state services, the Port of Rotterdam, the Dutch public site Overheid.nl, and the Dutch football federation cut access as a precaution. The Wikimedia Foundation also removed several of its systems — a preventive measure, not the result of a confirmed breach.

One essential point: none of these organizations reported a confirmed intrusion. These are precautionary shutdowns, taken while a fix either didn't exist yet or had only just shipped — not proof of a successful breach. On remaining exposure, VulnCheck counts roughly 2.6 million internet-reachable PHP servers, nearly 700,000 of them (more than one in four) still running PHP 3 through 7.3 — too old to receive any official fix at all. Large organizations (ministries, banks, hosts like OVHcloud, which auto-patched its shared hosting plans) closed the gap in under 24 hours. It's the small ones — SMEs, nonprofits, small municipalities, often unaware they even run PHP — that remain exposed longest.

How we checked our own exposure — and what we found

Before publishing this article, we checked our own PHP infrastructure rather than just writing about the theory. First step: php -v from the command line — a reassuring answer, PHP 8.4.27, already the patched version, auto-updated the very same day the fix shipped.

But the command line doesn't tell the whole story. Digging into the actual nginx configuration, we found the server runs three PHP-FPM versions in parallel (7.4, 8.2 and 8.4) for various legacy services. One of our mail-administration panels pointed to the PHP 8.2 instance — and that specific instance was still on 8.2.30, older than the fix (8.2.35). The patched package was already available in the repository, just not installed yet.

Fixed on the spot (package update, service restart, external check that the panel still responded normally). The lesson is directly reusable: checking a server's "default" PHP version isn't enough — a server that's been through several migrations or hosts several tools can easily run an old, forgotten version alongside the up-to-date one, invisible until you check every PHP-FPM socket actually used by every site.

What to do now

Sources and methodology

Canadian Centre for Cyber Security, advisory AL26-026 (affected/fixed versions, CWE-416 classification, recommendations) · BleepingComputer (Cloudflare CTO statement, UK NCSC alert, Wiz/OpenAI discovery detail) · Journal du Coin (ANSSI's role, precise timeline, Cloudflare filtering from 03:02 UTC) · Clubic (affected French organizations) · L'Appel (VulnCheck figures, small-site exposure) · CERT-FR, alert CERTFR-2026-ALE-014. Our own infrastructure check was performed live on October 22, 2026 (SSH access, inspection of the real nginx/PHP-FPM configuration). Data as of October 22, 2026 — the situation evolves quickly; check the official PHP advisory and CERT-FR for the latest updates.

Related articles

Check your own exposure

A free scan, in a few minutes, no credit card.