PHP2Shell: Frontier AI Turns Decade-Old PHP Flaws Into Working RCE

On October 21, 2026 the core of the web took a hit: PHP shipped an emergency release after Wiz Research found two critical vulnerabilities in the engine core that are now circulating under the name PHP2Shell. The numbers in the involved companies' disclosures are no fear-mongering piece: Wiz puts PHP's reach at about 70 percent of all websites, VirusTotal counts roughly 5.1 million IP addresses serving PHP, and the vulnerabilities carry CVSS 9.2. What makes the incident bigger than PHP is one detail: frontier AI models were the step that turned decade-old theoretical flaws into practice.

The details in quick succession: PHP grouped four bugs under two CVEs, CVE-2026-109618 and CVE-2026-109619, both memory-safety problems reachable with unauthenticated requests. Wiz demonstrated that a single script is enough: one script that runs unauthenticated code on installed WordPress, Drupal and Joomla instances. Anyone depending on PHP infrastructure should check which version their servers run and confirm they are on the October 21, 2026 release or a vendor backport.

Affected are PHP releases from 5.4 to 8.5, in other words every release of the last ten years. The patched versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. If you sit on an enterprise distribution you usually get the fix backported through a vendor branch; if you manage the runtime yourself the practical answer is: update now.

The second scenario is quieter but just as expensive: without code execution, worker-process memory can be read out. Wiz demonstrated this with session data: passwords, authentication tokens, API keys and certificates from foreign request contexts. For a defender that means the impact range spans code execution down to silent data leakage, and the leak is harder to see than the code execution.

The version is not the real problem. The flaws sit in the PHP core, not in an application; the exploit chain runs below the application layer. That means your web application can be cleanly maintained and the server still remains attackable. Application logs show nothing because the problem never reaches the app. If you hunt for attack signals you have to look at the server and runtime level: unusual multipart requests, memory-limit errors, strings of HTTP 500 responses, unexpectedly large PHPSESSID cookies.

The real signal of the research lies elsewhere: Wiz describes explicitly that the vulnerabilities sat in the PHP codebase for over a decade and nobody exploited them because the exploit chain was too complex. Frontier models, Wiz used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol, mechanized that work, adapted the chain to multiple targets and turned it into a working script within hours. That mechanization is the turning point: the effort of exploiting long-known flaws drops radically.

The discovery timeline reads like a workshop report: on August 19, 2026 Wiz found the first vulnerability, on August 20 and 21 unauthenticated RCE on Drupal and WordPress was confirmed, on August 24 Wiz reported the findings to the PHP security team, on September 21 PHP acknowledged them and started coordination, on October 21 patched versions shipped. 63 days from first find to patch, with coordination and backporting work in between.

The disclosure window made everything harder: on October 20, 2026 PHP announced the emergency release for October 21. Before the release, exploit details leaked ahead of the official disclosure. Patchstack reports that by 07:34 UTC on October 21 it received notices of multiple active exploitation incidents from hosting partners, hours before the official patch release. Cloudflare, Fastly, AWS, Google Cloud, Microsoft and Vercel pushed mitigations, and PHP moved the release up.

For operators the instruction is short: patch PHP, not the CMS. The fixes concern the engine core, and versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12 are currently the only official fixes. Defenders who cannot roll the patch immediately got concrete detection hints in the Wiz and Recorded Future write-ups: unusual multipart requests, memory-limit errors, oversized PHPSESSID cookies, PHP worker churn.

Looking at the numbers shows why the severity rating is justified: VirusTotal counts roughly 5.1 million IP addresses serving PHP, and only about 1.1 million of those disclose a version. Among the version-disclosing servers, roughly 758,000 run end-of-life branches from PHP 5.4 to 8.1, only about 272,000 run a supported branch. Modat counts 4,384,302 PHP services on about 1.9 million hosts, about 79 percent of them on unsupported branches. PHP 7.4, since 2022 without support, is the most common version with about 878,000 services. Even on the then-newest level, the September 24, 2026 releases, VirusTotal counted about 85,000 IP addresses.

Why the reach is this large follows from PHP's role in the web: Wikipedia runs on MediaWiki, WordPress, Drupal and Joomla are PHP applications, and a hole in the PHP core affects every installation of these systems even when the application itself is clean. The Wiz and Recorded Future pieces make clear that attack scenarios run below the application layer: your application is not where the flaw sits, but also not where you find the attack.

A look at the chain shows that frontier AI models here for the first time became the determinant that turned decades-old flaws from theory into practice. That is not a PHP problem but a shift of the threshold at which exploiting a complex flaw pays off. Wiz puts it plainly: complexity was the last line of defense, and it is gone.

The consequence for the AI scene is hard: anyone using frontier models for defensive work must expect the same models being run for offensive work by someone else. The line between security and attack lies not in the AI but in the hand that holds it. That applies to the tooling layer Wiz builds with Wiz Atlas for defenders, and equally to the tooling layer attackers use with the public repo listings and the leaked details.

One more word on WAF mitigations: Cloudflare, AWS, Fastly, Google Cloud, Imperva, Vercel and Microsoft built filters for the known exploit paths, and Wiz describes the chain as running below the application layer, which makes WAF filters hard-pressed to catch the attacks. The guidance from the sources: WAF mitigations reduce risk but do not replace the patch.

For a one-person operation like mine the practical lesson is direct and without alarmism: take release notes of runtime components seriously, document the update paths for PHP runtimes. Runtime hygiene is no longer a backlog task. I read the sources on October 23, 2026 and checked the runtimes I run: the updates are relevant for every server that serves PHP, and for anyone running PHP services outside a direct patch cycle.

The question I leave standing at the end is not whether PHP can be patched. The question is what happens when the next decades-old weak point falls from theory into practice and the effort for it collapses overnight. PHP2Shell is the proof that this point has been reached for the current generation of frontier models. And PHP 5.4 to 8.5 is a reminder that the flaws frontier models pick as targets are not the recent ones, but the ones nobody checks anymore.

About the Author: I am Marcel, a graphic designer running the HUNTER cyberdeck on a Google Pixel 6a. For this post I read the Wiz Research disclosure on PHP2Shell and the Recorded Future situation report on October 23, 2026; the Digitale Profis video of October 23, 2026 served as the newsroom trigger. The newsroom sweeps 58 feeds, I pick the topic, drafts ship under my go.

Sources with retrieval date October 23, 2026: Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet (Oct 21, 2026). Recorded Future / Insikt Group, PHP2Shell Exploitation: Two Critical PHP Flaws Explained (Oct 21, 2026). Digitale Profis, KI-Angriff auf das gesamte Internet (YouTube, Oct 23, 2026, newsroom trigger, marked as secondary source).