PHP2Shell: AI Found It First, and Someone Else Was Already Knocking

Mats Sjödin·October 22, 2026·9 min read

If you run anything on PHP, this week was patch week. Two bugs in the PHP core, nicknamed PHP2Shell, let an attacker run code on a web server with a single request and without logging in. They were found with AI, the embargo leaked a day early, and Amazon saw someone trying the exploit four days before the patch existed.

I've spent 25+ years running servers and the last couple building with AI, so this one hits both halves of my job. This post covers what the bugs are, how the disclosure fell apart, whether it was an inside job, and what we can do about it as web developers.

What PHP2Shell is

PHP2Shell is two critical remote code execution bugs in PHP itself, both scored 9.2 on CVSS v4. They are tracked as CVE-2026-109618 and CVE-2026-109619, and PHP's security announcement says updating is the only safe choice.

The first one, CVE-2026-109618, is a memory bug. PHP handles out-of-memory errors by abandoning the request wherever it is. If that happens while request memory is only half set up, the cleanup step later treats the broken memory as valid. An attacker forces it with crafted multipart requests.

The second, CVE-2026-109619, is about state. A PHP worker keeps global state pointing into one request's memory. If a fatal error interrupts the request before that state is reset, the memory is freed but the pointer survives, and the next request on the same worker can use it. That makes it a use-after-free spread across two HTTP requests.

The bugs live in the core rather than in any app, so every PHP that serves web requests is in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. mod_php is worst off. Its cleanup runs even when request startup failed, so the attack lands before any of your code runs. PHP-FPM kills the child instead, which blocks the easiest path but leaves the underlying bug in place.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The bugs reach back to PHP 5.4, more than a decade of releases. PHP published minimal backports for 7.4, 8.0 and 8.1; anything older is on its own.

How it was found

AI found it, with people pointing it in the right direction. Security firm Calif found the first bug in August using OpenAI's GPT-5.6 Sol, in a PHP audit funded by OpenAI's Patch the Planet initiative. Wiz found the flaws independently weeks later with Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol, and showed working attacks against WordPress, Drupal and Joomla.

Calif is surprisingly modest about it. They started from older public research that had theorised about this attack vector, used only generally available models, and say that knowing PHP's history mattered more than the model. A limited version of the bug had even been seen in 2024 and written off as minor.

The reaction was big. OpenAI called it one of the most impactful security issues in recent memory. CERT-EU and the UK's NCSC told organisations to take systems offline if they couldn't patch, and sites like Pinboard and the GrapheneOS forum went partly dark. A PHP Foundation engineer compared it to Heartbleed.

The embargo that broke

The plan was a coordinated release on Thursday, October 22. It broke in several places at once, and PHP shipped a day early because of it.

When (2026)	What happened
Oct 21, 14:00 UTC	PHP ships the fix, a day ahead of the original embargo (announcement)
Oct 21, 07:41 UTC	Chainguard publishes patched images more than six hours before release; PHP calls it an embargo break, Chainguard denies leaking
Oct 21, 03:02 UTC	Cloudflare turns on WAF rules for every customer, free plans included
Oct 20, evening	watchTowr confirms publicly that the bugs are real and posts both CVE numbers
Oct 20	Calif accidentally publishes a short proof-of-concept video, then pulls it
Oct 20, ~15:00 UTC	A Hacker News post leaks the CVE numbers and the planned date; it's deleted, but screenshots spread

PHP's maintainers wrote up their side on the PHP Foundation blog. Chainguard's CEO says his team rediscovered the same bugs in one evening with an AI harness after hearing from a researcher that something was coming.

Exploited before release: an inside job?

The rumour is true: someone tried PHP2Shell before it was public. Amazon Threat Intelligence caught an exploit attempt in its MadPot honeypots on October 17, four days before disclosure, from a commercial anonymization network. Amazon says it doesn't know how the attacker got the information. More attempts from different actors followed in the hours before release, and broad exploitation started right after.

So was it an insider? Here's my read of what's public.

The timing rules out the public leaks. October 17 is three days before the Hacker News post and four days before Chainguard's images, so whoever did it had the information first.

An insider leak is possible. The embargo circle was large: three research teams, distributors, LTS vendors and critical-infrastructure contacts who got mitigation advice. Nobody has shown evidence pointing at any of them.

Independent rediscovery is at least as likely, though. The bug class was partly described in public research, Wiz found it independently, and Chainguard says it found it in one evening with a simple prompt. If three defenders could do that, a well-funded attacker with the same models probably could too.

Who leaked matters less than what Amazon points out: an embargo only protects you until someone else finds the same bug, so the disclosure date is not the earliest date you could have been hit.

The phishing that follows

PHP2Shell needs no clicks, but the week after it will be full of scams. A public emergency with a deadline is perfect material for social engineering, as PhishingBox points out. Expect:

Emails to site owners quoting the real CVE numbers, linking to a fake control-panel login and threatening account suspension.
Calls to helpdesks from "your hosting provider" or "your MSP" asking for SSH or cPanel credentials to apply the fix.

Your host patches the server, and it never needs your password to do it. Anyone asking for credentials to "apply the PHP fix" is the incident.

Why we'll see a lot more of these

This is the second time in a few months that AI-found bugs forced a mass update, after the mass-exploited WordPress flaws in July. OpenAI says PHP2Shell is one of several serious bugs it has found and expects such findings to rise sharply.

AI helps defenders, but it speeds up attackers too. Code that has been reviewed for decades, like PHP's core, is getting a fresh look from models that don't get bored, so finding bugs is cheaper. Amazon notes that attackers used to wait for a few skilled people to publish a proof of concept. Now AI makes it cheap to turn a patch diff into a working exploit, so many more actors can move within hours. And defences get tested live: Cloudflare watched attackers change their payloads against its WAF rules as the rules went in.

For internet-facing systems, that means a 7-day or 30-day patch window is time attackers no longer give you.

What we can do as web coders

We can't fix bugs in PHP's C core ourselves. What we control is how fast we patch, how much damage a hijacked worker can do, and how quickly we notice.

Patch within hours.
- Know every place PHP runs: CMS sites on shared hosting, cPanel and Plesk, vendor appliances, Windows tools that bundle php.exe.
- Automate updates: unattended distro security updates, or a container pipeline that rebuilds on a new base image the same day.
- Retire end-of-life PHP. Anything before 8.2 gets no regular fixes.
Shrink the attack surface.
- Prefer PHP-FPM over mod_php; FPM blocked the easiest path here.
- Turn off what you don't use, like session.upload_progress.enabled.
- Cap request size, multipart parts and headers at the proxy as well as in PHP.
- Put admin panels behind a VPN or SSO, and ship static output where you can.
Put a filter in front. A WAF or CDN won't fix the bug, but it buys hours between disclosure and patch.
Limit the damage when code does run.
- Run the worker as a low-privilege user that can't write to the web root.
- Use read-only containers or filesystems where possible.
- Block outbound traffic from web servers by default. It kills most reverse shells and second-stage downloads.
- Give the app scoped database credentials and keep secrets out of files the worker can read.
Watch what your processes do. Alert when php-fpm, httpd, apache2 or php-cgi starts a shell, python, perl, curl, wget or nc. Florian Roth's free process-watcher does this on Linux, and because it looks at behaviour instead of specific CVEs, it catches the next zero-day too. Add file-integrity monitoring on the web root.
Assume you were hit first. Investigate from the earliest known exploitation, which for PHP2Shell is October 17 at the latest, rather than from the advisory date. Rotate exposed secrets and keep tested backups.
Point AI at your own code. The same models that found PHP2Shell can review your app. Run AI security reviews and dependency scanning in CI, so your model reads your code before an attacker's does.

Closing thoughts

I think PHP2Shell is a preview of the next few years. AI will keep finding old bugs in code we thought was settled, and the gap between "patch released" and "exploited" will keep shrinking. The good news is that most of what protects us is boring basics: fast patching, least privilege, egress filtering and watching what our servers do. If you haven't updated PHP yet, close this tab and do it now.