PHP patches critical unauthenticated RCE flaws affecting every release since PHP 5.4

What happened

On October 21, 2026, the PHP project shipped security releases fixing two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which researchers have collectively nicknamed PHP2Shell. According to a dev.to write-up from Coding Cat Dev, both flaws carry a CVSS v4.0 score of 9.2, allow unauthenticated remote code execution, and affect every PHP release from 5.4 through 8.5. A second dev.to post by Merradou confirms the patched versions: 8.2.35, 8.3.36, 8.4.27 and 8.5.12.

The underlying bug is not new. The PHP Foundation's security retrospective, cited in the Coding Cat Dev article, says an out-of-memory condition was first noticed in 2024 during an external audit by Quarkslab, funded through the Sovereign Tech Agency via OSTIF. Work on a fix then stalled for roughly two years, because nobody had demonstrated a working exploit and every candidate patch risked breaking backward compatibility or third-party C extensions.

What changed in 2026 was tooling. According to the article, security researcher Ryan Austin at Calif used OpenAI's GPT-5.6 Sol under OpenAI's Patch the Planet coordinated disclosure program to turn the theoretical condition into a working pre-authentication exploit chain. Separately, Wiz reported both CVEs using AI-driven vulnerability research agents built on Google Gemini and GPT models, and reportedly called the pair the most severe flaws ever found with AI assistance.

How the flaw works

The bug sits in the C-based PHP interpreter itself, in the Zend Engine paths that handle per-request memory management and error handling. Per the Coding Cat Dev breakdown: a crafted request that triggers PHP's memory limit during a narrow initialization window causes the engine to abort the request before certain internal pointers are fully set up. The shutdown cleanup routine then treats those partially initialized structures as valid pointers, letting an unauthenticated remote attacker corrupt engine memory before the application's own authentication checks ever run.

A Sansec Forensics advisory cited in the article says Calif demonstrated unauthenticated code execution against clean installations of WordPress, Laravel, Symfony, Magento, Drupal, Joomla, MediaWiki, Nextcloud, Roundcube and phpMyAdmin. Because the vulnerability lives in the PHP binary itself (php-fpm, mod_php or php-cgi), updating application code, plugins or Composer dependencies does not fix it. Only patching the runtime does.

An embargo that collapsed

The coordinated disclosure was scheduled for October 21 at 14:00 UTC, but the timeline fractured. According to the Coding Cat Dev post, CVE identifiers and a proof-of-concept video leaked on social media on October 20, prompting attackers to start probing. At 07:41 UTC on October 21, container vendor Chainguard published patched container images more than six hours early, which the PHP Foundation noted allowed anyone to binary-diff the patch against the previous build. Cloudflare recorded the first automated exploitation attempts two minutes later, and CEO Matthew Prince reported probes growing from thousands to tens of thousands within 45 minutes and to millions across Cloudflare's edge.

Citing BBC News, the article reports that government portals, the Wikimedia systems behind Wikipedia, Scottish public health boards, Edinburgh Council, the Finnish government and the Netherlands' NCSC all temporarily took services offline as a precaution.

How hard is it to exploit

Researchers at Sansec, Tenable and Bitdefender add an important caveat: unlike Log4Shell or Shellshock, reliable exploitation appears to require target-specific knowledge of a server's memory configuration and application state to hit the exact window. Many public proof-of-concept scripts reportedly fail against default PHP installations or depend on a separate local file inclusion bug. Even so, the consensus is that leaving an internet-facing PHP runtime unpatched is not acceptable while AI-assisted offensive tooling keeps improving.

How to check and patch

Merradou's deployment guidance: php -v only shows your command-line install, which may differ from the runtime serving web requests. Check every deployed instance, including containers, secondary servers, internet-exposed staging environments and forgotten legacy applications. Install the update, restart the relevant services or replace the containers, confirm the running workers use the patched build, and test critical flows afterwards. Note that vendors sometimes backport fixes into older packages without changing the upstream version number, so check the vendor's security notice rather than the number alone.

For end-of-life branches such as 7.4, 8.0 and 8.1, PHP.net publishes no official binaries and official Docker images will not be updated, but Debian, Ubuntu, CloudLinux and Remi's RPM repository have backported the patches, according to the Coding Cat Dev article.

Why it matters

This is a runtime-level flaw beneath every PHP framework, and PHP powers a huge share of the web — the Coding Cat Dev article puts it near 70%. It is also a clear demonstration that frontier AI models have changed the calculus of vulnerability research: a bug treated as theoretical for two years became a working exploit chain, and once an embargo broke, mass scanning began within minutes rather than days. The operational lesson is straightforward: verify what is actually serving your requests, patch every instance, and do not assume dependency updates cover flaws in the interpreter itself.