PHP2Shell: the critical PHP flaws, and how to patch them

If you run PHP, update it now. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October, fix two critical flaws in PHP itself that can let an attacker run code on your server.

The flaws, now known as PHP2Shell, sit in the core of PHP, not in an extension or a framework. That means a plain site can be exposed. Wiz, one of the teams that found them, says “even a simple ‘Hello World’ application running on an affected PHP version can be vulnerable.”

What the PHP2Shell flaws are

There are two bugs, both rated 9.2 Critical by the PHP project (CVSS 4.0):

php.net says the risk covers “all PHP installations serving web requests”. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers mod_php the most exposed, “with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.”

The official advisories cover branches 8.2 to 8.5. AWS, Wiz and Calif say older versions are affected too, going back to PHP 5.4.

Which versions fix it

One trap: your distribution’s version number may not match these. Ubuntu, for example, patched PHP 8.3 on 24.04 LTS as 8.3.6-0ubuntu0.24.04.13 (USN-8948-1). So php -v won’t show 8.3.36 even when you’re patched.

Check your package version against your vendor’s advisory, not against php.net. Red Hat rates the flaws Important. When we checked on 22 October, its bulletin said some fixes were out and others were still in progress.

If you can’t update today

php.net says “There are no complete mitigations, updating is the only safe choice.” Its advisory lists stopgaps:

• For CVE-2026-109618: set memory_limit=-1 and enforce it with php_admin_value so apps can’t change it. Keep post_max_size small (8M without uploads, 32M with), with upload_max_filesize below it. Limit request sizes at your proxy, and use a container or cgroup memory limit.
• For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini, the FPM pool or server config, then restart every worker. php.net warns: “Do not rely on ini_set() or FPM .user.ini.” On PHP 8.5, also set fatal_error_backtraces=0.

Each setting only covers one of the two bugs, and php.net says neither is complete. The UK’s National Cyber Security Centre goes further.

If you can’t apply those stopgaps either, it says to “consider taking the system offline until it can be fully mitigated.” If you can’t update or take it offline straight away, it says to check for signs of compromise first and look for “backdoors installed by an attacker”.

How AI models found them

Three teams found the bugs separately, with help from AI models. The PHP Foundation says the security firm Calif reported the first bug on 11 August. OpenAI “independently reported the same root cause on the same day”. Wiz reported both bugs on 24 August.

OpenAI says Calif found the flaw “using GPT‑5.6 Sol as part of our Patch the Planet initiative”. That’s OpenAI’s programme, built with Trail of Bits, for coordinating fixes when AI agents find serious bugs.

Calif’s own write-up says “No special harness, or access to models that weren’t generally available to everyone were used”. Wiz says it used “Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol”. We’ve covered how far AI tools now go in reading other people’s code, in our piece on the Reverse Engineer Anything tool.

The root problem wasn’t new. The PHP Foundation says a developer it contracts spotted it in 2024, but a fix stalled for months. It calls that delay “a structural failure”, caused by its security team’s “decision process and its lack of resources.” The team worked by consensus and is changing so it can decide by majority.

What’s disputed

Whether it’s being exploited. AWS says its honeypots saw an exploitation attempt on 17 October, four days before disclosure. It says “PHP2Shell is now being broadly exploited in the wild”.

Of the attempts it logged before the release, AWS also says “it’s unclear if any of these attempts would have succeeded in real-world systems.” The PHP Foundation says the PHP security team “did not identify any functional exploits at the time of release/public disclosure”.

How hard it is to exploit. In a blog post, Elias Taylor wrote that exploiting it “is significantly harder than people are making it out to be”. He says the public proof-of-concept code on GitHub doesn’t work against plain PHP, but still: “You should patch your servers anyway.”

Red Hat also says PHP-FPM, which standard Red Hat Enterprise Linux set-ups use, makes remote code execution “difficult in practice”. On the other side, Calif and PHP’s own advisory say it was proved against default mod_php set-ups. Wiz says its exploit worked on the latest WordPress, Drupal and Joomla container images. None of them has published a working exploit.

The leak. Details were meant to stay secret until 22 October. The PHP Foundation says CVE numbers leaked on 20 October, and that Calif “mistakenly published a video” of its exploit that evening.

It also says Chainguard “unilaterally broke the embargo” by publishing fixed container images early on 21 October. Chainguard’s chief executive, Dan Lorenc, told The Register his company “didn’t leak” and that “People were getting hit in advance”. PHP had already brought the release forward to 21 October after the CVE leak.

What happens next

Watch your vendor’s advisory if you’re on Red Hat, an older Ubuntu release or a managed host. AWS says to investigate your logs “from at least starting on October 17th.”

AI agents that find bugs can also cause them. Our report on OpenAI agents that weakened their own monitoring covers what to lock down when an agent has write access to your code.