PHP2Shell: AI helped expose two critical PHP flaws that put most of the web at risk

On 21 October 2026 the PHP project shipped emergency releases for two critical vulnerabilities in the PHP engine itself. The flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, can let an unauthenticated attacker execute code on a web server. They are not bugs in WordPress, Drupal or a plugin. They sit in the memory management and error handling that nearly every PHP request touches, which is why even a simple "Hello World" page on an affected version can be at risk.

What makes this story different from a normal patch day is how the flaws were proven. According to the PHP Foundation, the first signs of the underlying problem were noticed back in 2024, but nobody could show a realistic attack path, so the fix stalled. In August 2026, researchers using frontier AI models turned that old weakness into working exploits within days. Wiz calls it a possible turning point for the AI era, comparable to Heartbleed in 2014 and Log4Shell in 2021. OpenAI describes it as one of the most impactful security issues in recent memory.

This article explains what the two flaws are, who found them with which AI tools, how the disclosure went wrong at the last minute, what is known about attacks, and what you should do if you run anything on PHP.

The short version

• What: two related remote code execution flaws in core PHP, both rated CVSS 9.2 by the PHP security team.
• Who is affected: every PHP installation that serves web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest on Apache with mod_php.
• How old: the earliest affected code path dates back to PHP 5.4, released in 2012. Every PHP version from the last decade is affected by at least one of the issues.
• The fix: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older branches get no official release.
• The AI angle: Calif used OpenAI's GPT-5.6 Sol, and Wiz used its Wiz Atlas agent together with Google's Gemini 4 Argon and GPT-5.6 Sol.
• Attacks: Amazon Threat Intelligence saw a first exploitation attempt on 17 October, four days before disclosure, and says the flaws are now being broadly exploited.

What the two vulnerabilities actually do

Both issues come from the same design pattern. When a PHP request hits a fatal error at exactly the wrong moment, especially an out of memory error, PHP can tear down the memory of that request while some internal pointers still refer to it. The worker process survives and handles the next request. If that next request reaches the stale pointer before PHP resets it, the engine treats memory that an attacker may now control as if it were valid internal data.

CVE-2026-109618 (OOM corruption). The PHP Foundation explains that if a request reaches the memory_limit at the wrong moment, PHP can leave partially initialized internal data behind and later treat it as valid. On Apache with mod_php, an unauthenticated request can trigger this before any application code runs, and full remote code execution was demonstrated with default settings. Code execution was also confirmed on PHP-FPM through application level code paths.

CVE-2026-109619 (stale global state). Here a fatal error can leave internal state pointing at memory that belonged to a previous request. A later request handled by the same worker can then use that freed memory, a classic use after free. The reporter demonstrated remote code execution against a real application on Apache with mod_php, and PHP also lists memory disclosure as a confirmed impact.

Wiz described four concrete bugs grouped under these two CVEs. One abuses the session upload progress feature, which parses multipart uploads during request startup. Another lets an attacker read a chunk of live worker memory that comes back URL encoded inside a PHPSESSID cookie, even if the application never starts a session. That memory can contain passwords, tokens, API keys and certificates from other users' requests. A third bug involves the stored backtrace of the last fatal error, and a fourth creates a type confusion in OPcache's shared memory across workers.

Wiz combined these primitives into a single exploit script and says it achieved pre authentication remote code execution on the latest container images of WordPress, Drupal and Joomla. Calif, according to Tenable's FAQ, also confirmed pre authentication code execution on Magento. These applications are only demonstrations. The vulnerable code is in PHP, not in the CMS.

How AI changed the picture

The PHP Foundation is unusually open about the history. In 2024 PHP went through its first external security audit in years, funded by the German Sovereign Tech Agency through OSTIF and carried out by Quarkslab. While fixing one of those findings, a PHP core developer found the first signs of the out of memory problem. A potential exploit was theorized, but no concrete attack vector was found. The security team developed several competing fixes, each with trade offs in compatibility, performance or third party extensions, and the work stalled and restarted over months. The Foundation calls that delay "a structural failure".

Then the economics changed. Calif began auditing PHP on 30 July 2026 as part of OpenAI's Patch the Planet program. On 11 August, researcher Ryan A at Calif reported an unconditional remote code execution with the same root cause as the 2024 problem. OpenAI's Codex Security team reported the same root cause on the same day and added more attack vectors on 18 September. Wiz found its own set of bugs on 19 August, confirmed code execution on Drupal the next day and on WordPress the day after, and reported to PHP on 24 August.

Wiz is explicit about why AI mattered. The flaws had been in the code for more than a decade, but exploiting them meant chaining several bugs and adapting each attempt to the memory layout of a specific PHP version and configuration. That is slow, expert work. "With AI this is no longer a barrier," Wiz writes. Language models can adapt an exploit to different versions and layouts, and with testing and debugging tools they can analyze failures and iterate. According to Wiz, a single researcher with frontier models and the right tools completed in a week what previously would have taken a world class team months. Google DeepMind's head of Gemini security, Raluca Ada Popa, said Gemini 4 Argon helped defenders bridge that gap.

The PHP security team itself also uses AI now. Earlier in 2026 it worked with Alpha-Omega to scan PHP with Anthropic's Claude Mythos, and it uses OpenAI's Daybreak Red to validate incoming reports and exploits. The flip side is volume: the team has published 15 CVEs since 1 July and worked through more than 100 reports that turned out to be invalid, duplicates or not reproducible. A person still makes every call and writes every patch.

A disclosure that broke down at the end

The coordinated disclosure worked for about two months and then came apart in the last 48 hours. The PHP Foundation lays out the sequence:

• On Tuesday 20 October, around 15:00 UTC (17:00 Berlin time), the two CVE IDs began circulating on forums and social media, with a wrong release time and a wrong CVSS score of 10.0. No technical details leaked.
• PHP published its pre announcement at 19:30 UTC and moved the release from 22 October to 21 October, 14:00 UTC. Distributors were still packaging the fix, so an immediate release would have left many users without an easy update.
• After the pre announcement, Calif mistakenly published a video showing its proof of concept working against several targets. It was deleted, but copies spread and, according to PHP, sped up the development of public exploit attempts.
• On 21 October at 07:41 UTC, more than six hours before the coordinated release, Chainguard published built images containing the fix. PHP says this broke the embargo, because attackers could study the patch in binary form while everyone else was still waiting.

PHP says it inspected the public proofs of concept that appeared after the leak and did not find a functional exploit at the time of release. That reassurance did not last long.

Attacks are already happening

Tenable's FAQ collects the early signals. Cloudflare CTO Dane Knecht said on 21 October that the company was "seeing early attacks emerging" and had deployed WAF rules for the known exploit vectors to all customers, including the free tier, while calling them a stopgap only. watchTowr said it had reproduced both vulnerabilities and was seeing exploitation attempts against both.

The most uncomfortable detail comes from Amazon Threat Intelligence. It observed a PHP2Shell exploitation attempt against its MadPot honeypot network on 17 October, four days before public disclosure, and says it is unclear how the attacker got the information. More attempts followed on 21 October from what looks like multiple actors. Amazon now describes the flaws as broadly exploited in the wild and recommends that investigations start from at least 17 October, not from the disclosure date. That contradicts the earlier hope that AI had found the bugs before any attacker did, at least for the last few days of the embargo.

TechCrunch reports that the US National Security Agency advised that websites which cannot be patched immediately should be taken offline until they can be. CERT-EU similarly suggests isolating internet facing applications from public networks until a fix is applied and verified.

How big is the exposure?

PHP is everywhere. W3Techs data cited by Tenable puts PHP at 69.3 percent of websites whose server side language is known. A Shodan search by Henk Poley counts more than 1.9 million internet exposed hosts running PHP, and researcher Silas Cutler roughly estimates that more than 1.3 million exposed hosts are potentially vulnerable. Those are estimates, not scan results, but they show why this is treated as an internet scale event.

WordPress published a statement that the flaw is not WordPress specific. Site owners need their servers patched, which for most of them means waiting for, or pushing, their hosting company. Many large hosts and CDNs, including Automattic, Akamai, AWS, Cloudflare, Fastly, Google, Imperva, Microsoft and Vercel, helped prepare mitigations before disclosure.

What you should do now

The PHP security team is clear that updating is the only complete fix.

• Supported branches: update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart every PHP worker.
• PHP 7.4 to 8.1: these branches are end of life and get no official release. The security team published minimal source backports for people who build from source. Everyone else should upgrade to a supported branch or check with their distribution or long term support vendor.
• PHP 5.4 to 7.3: no fix from the PHP project. Upgrade.
• If you cannot update today: PHP lists configuration changes that reduce exposure to specific attack paths but do not make a server safe. For CVE-2026-109618 that is setting memory_limit to -1 in a way applications cannot override. For CVE-2026-109619 it is setting session.upload_progress.enabled to 0 and, on PHP 8.5, fatal_error_backtraces to 0. A container or cgroup memory limit can act as an availability boundary.
• Look for signs of attack: Wiz suggests watching for unusual multipart requests followed by memory limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID cookies, and unexplained worker churn.

OpenAI also released a PHP version checker as a Codex skill to help operators find potentially vulnerable installations, and Tenable, Wiz and other vendors have shipped detections.

Our take

PHP2Shell is the clearest example so far of AI changing what "vulnerable" means. The bug class was known in 2024. What was missing was proof that it could be exploited in practice, and that proof was expensive enough that a small, underfunded security team could keep postponing a hard fix. Frontier models removed that cost for the researchers at Calif, OpenAI and Wiz. The same capability is now available to attackers, which is exactly why Wiz warns that complexity may no longer be a meaningful barrier.

There are two lessons. The first is for defenders: old, hard to exploit bugs can no longer be parked. If AI makes exploitation cheap, the backlog of "theoretical" issues in widely used software becomes a list of real risks. The second is about funding. The PHP Foundation openly says that tools now find bugs faster than ever, but deciding the right fix for a decades old design decision still takes experienced engineers, and there are too few of them. OpenAI's pledge of $1 billion in subsidized Daybreak access for organizations with limited security resources is a step, but the bottleneck in this case was people who understand the PHP engine.

The disclosure also shows how fragile coordination becomes when the stakes are this high. A leak of two CVE numbers, a deleted video and one early container image were enough to shorten the defenders' window, and Amazon's honeypots suggest someone was probing even before that. Expect more of this. OpenAI says these bugs are among several significant vulnerabilities it has already found and that similar findings will increase sharply in the coming months.

If you run PHP anywhere, the practical advice is simple: patch today, restart your workers, and check your logs back to 17 October.

Sources: PHP Foundation, Wiz Research, OpenAI, Tenable, TechCrunch.