PHP2Shell, the flaw PHP first saw in 2024

PHP2Shell is the nickname for 2 critical bugs inside PHP itself, the language that runs most of the web, and together they let a stranger send a few ordinary web requests and end up running their own commands on the server, with no password and no account. PHP shipped the fixed releases on 21 October, 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and its own homepage says there are no complete mitigations, updating is the only safe choice.

The patch is the easy half of this story. Models from OpenAI and Google helped 2 separate security teams find the bugs, PHP's own developers had seen the first signs of one of them during an audit 2 years ago and could not agree on a fix, and Amazon recorded somebody trying the attack 4 days before the world was told anything. Those 3 facts come from 3 different documents published this week, and they read very differently side by side.

What is PHP2Shell, in plain words?

PHP2Shell is the name the researchers gave to a pair of flaws in PHP's core engine that let an attacker run code on a web server without logging in first. PHP is the language behind WordPress, Drupal, Joomla and most ordinary web hosting, so the flaws sit underneath millions of sites whose owners have never written a line of PHP in their lives.

Both flaws come from the same clumsy moment, the cleanup a program does when something goes wrong. The first one, which the advisory titles RCE via OOM corruption, happens when PHP runs out of memory while it is still setting up a request and gives up with its own internal state only half built. The second, titled RCE via stale global state, happens when leftovers from one request survive into the next after the memory holding them has already been handed back. RCE is short for remote code execution, which means running your own program on somebody else's machine, and that is where both of them end.

An attacker who can force that stumble on purpose gets to choose what the server does next, and the site's own code has nothing to do with it. A carefully written WordPress theme on a carefully configured server is exposed exactly like a sloppy one, which is why this went round the industry in a day while ordinary plugin bugs never do.

PHP's developers rated both flaws 9.2 out of 10 on the standard severity scale and labelled them critical. The Wikipedia entry on PHP2Shell credits the security firm watchTowr with a perfect score instead, and watchTowr's own public FAQ, read for this piece, prints the same figure PHP does. The advisories put the highest risk on servers running Apache with mod_php, where configuration directives are applied before a request has properly started, so an attack can land before the application runs at all.

Wiz's own write up reaches for Heartbleed and Log4Shell, the 2 names people use when a flaw sits underneath everything else, and The Next Web reports a security engineer at the PHP Foundation making the same comparison to Heartbleed. Those comparisons are about reach rather than about how easy the attack is, and the severity score published with each advisory marks the attack complexity as high, which is the one reassuring line in the advisories.

The figure everybody reached for this week is PHP's share of the web, and it deserves the qualifier the headlines drop. W3Techs, the survey those claims come from, said 69.3% on the morning this was written, and its own sentence counts only the websites whose server side language it can identify. Plenty of sites give nothing away, so the share of every website is lower than that, and PHP is still the most common answer by a wide margin.

Which PHP version is safe, and how do you check yours?

You are safe on the releases PHP published on the day of the advisories, one for each branch it still supports, and the table below lists them. Anything older on a public server is open, because php.net says no configuration change fully protects you and that updating is the only safe choice.

If you run your own server, the check takes 1 command.

php -v

The first line it prints is the version you are running. If that number is lower than the release for your branch in the table, and your Linux vendor has not patched it for you, the server is exposed. If the site is a WordPress site and somebody else runs the server, open the dashboard and go to Tools, then Site Health, then the Info tab, and expand the Server panel, where the PHP version row says what your host is serving. WordPress documents that exact path, and the look takes a minute.

There is a trap in reading that number, and it catches careful people. Linux distributions do not ship PHP's releases as they are, they take the fix and apply it to the version they already carry, so a server can report a lower version and still be patched. AlmaLinux published rebuilt packages on the evening of the advisories, including fixes for streams that had already reached their end of life, with a warning that future fixes for retired streams are not guaranteed. If your distribution supplies PHP, its own advisory answers the question, not the version string alone.

Updating the files is not the end of it either. A PHP worker that is already running keeps the old code in memory until the service restarts, which is why AlmaLinux's instructions pair the upgrade with a restart.

sudo dnf clean metadata && sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm

Those 2 lines are AlmaLinux's own, for a server you administer yourself, and Apache users restart Apache instead. On shared hosting none of it is yours to run, so the honest move is to find your host's status page, or open a ticket and ask which PHP build they are serving today and when they updated it.

If you genuinely cannot update today, the advisory for the second flaw offers a stopgap rather than a cure. On the newest branch an administrator can switch off fatal error backtraces and session upload progress for some immediate relief, and PHP says in the same breath that those settings do not cover every kind of leftover state the flaw touches. The only reliable fix it names is a release carrying the complete state reset patch, which is the wording behind the blunt line on the homepage.

Did an AI really find PHP2Shell on its own?

No, and the published record is more interesting than the headline. 2 separate teams found the flaws within weeks of each other, each using AI models as a tool, and the advisories credit 4 people as reporters alongside 4 PHP developers who wrote the fix.

A researcher at the security firm Calif, credited as Ryan A in the PHP Foundation's account, reported the first flaw on 11 August using OpenAI's GPT-5.6 Sol, under an OpenAI program called Patch the Planet. OpenAI's own team reported the same underlying cause. Wiz, the cloud security company that sits inside Google Cloud, reported both flaws a couple of weeks later, and it used its own tool, Wiz Atlas, together with Google's Gemini 4 Argon and the same OpenAI model.

OpenAI's disclosure post makes a claim about that timing, and it carries its own hedge.

To our knowledge, frontier AI found these vulnerabilities before attackers did.

That sentence is quoted here from implicator.ai, which read the post, because openai.com refused our request for the page this morning. The firm that filed the first report is noticeably more careful about what its model did.

No model is simply capable of unearthing 'all bugs' with simple prompts. At least for now.

The months between August and this week went on coordination. OpenAI says that work ran for about 2 months before anything was public, with maintainers, researchers and security providers working on a fix while the flaws stayed quiet. Hosting companies and cloud providers were briefed in that window, which is why patched builds and protections appeared within hours of the announcement rather than weeks after it.

Calif told The Next Web that knowing PHP's history mattered more than the model did, and the rest of the record agrees with that. Finding a weakness and shipping a fix are different jobs, and this fix took months of argument inside the project plus 4 named developers on the final patch. For a fair picture of what these models are good at inside a codebase today, our walk through how to review code with Claude Code lands on reading and explaining rather than deciding.

Why did PHP leave the problem sitting since 2024?

A PHP core developer found the first signs of the memory flaw in 2024, during the project's first external security audit in years, and no fix shipped until this week. The PHP Foundation says so itself, in the post it published beside the release.

That audit was funded by Germany's Sovereign Tech Agency, organised through OSTIF and carried out by the security firm Quarkslab. While fixing one of the issues Quarkslab reported, a developer contracted by the foundation noticed the behaviour behind the first of the 2 flaws. Nobody had a working attack for it then, and that absence is what let it wait.

The security team wrote several competing fixes afterwards, and every one of them cost something. One broke compatibility with code that already worked, one opened a way to knock a server over, and one would have forced changes on a long list of add ons written by other people. The team decides by consensus, the group with deep knowledge of the engine is small and busy, and the work stalled and restarted over months.

We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources.

Release notes do not usually read like that. The same post lists what the foundation has changed since. Decisions can now be reached by a majority instead of waiting for everybody to agree, a second security team was created in May to work beside the original one on triage and hardening, and 2 more people joined in July and in September for triage and hardening work. The post also names the tools the project now runs over its own code, including Anthropic's Claude Mythos and OpenAI's Daybreak Red for validating reports and exploits.

How was somebody attacking PHP2Shell before the patch existed?

Amazon's honeypot network recorded a PHP2Shell attack attempt on 17 October, 4 days before PHP disclosed the flaws and shipped the fix, and Amazon says it cannot explain how. The attempt came from an address on a commercial anonymization network, and Amazon reads a honeypot being hit from a hidden address as an attacker rather than a researcher.

More attempts followed in the early hours of release day from other hidden infrastructure, carrying different payloads, which Amazon takes as a sign that more than one group had something by then. Amazon's own wording about the first attempt stays careful.

It remains unclear how the actor acquired exploit information prior to disclosure.

The leak everybody pointed at happened later, and PHP's own timeline shows it. The identifiers started circulating on the afternoon before the release, a pre announcement went out that evening, mitigation advice sent to critical infrastructure providers that night may have leaked as well by the foundation's own account, and one vendor published rebuilt images hours before the official moment. Every one of those came after the attempt Amazon logged.

Set that timeline next to OpenAI's sentence about frontier AI finding the flaws before attackers did. The models did find the flaws in August, which is early by any measure, and the quiet window those months were meant to buy had already closed 4 days before the fix existed. Nobody has explained how, and it is the most interesting open question left in this story.

Amazon's advice to anyone running PHP is simple enough to follow today. Start looking in your logs from the earliest known attack rather than from the announcement, which for this one means the Saturday before the patch rather than the Wednesday it landed.

What does PHP2Shell change for anyone who builds with AI?

PHP2Shell shows the same tool working on both sides of the fence. 2 security teams pointed models at the engine behind most of the web and found something real, and whoever was probing on the Saturday before the patch had something real too, from a source nobody has identified.

For somebody running a small site or a side project, the lesson is less about models than about who patches what. Your runtime is maintained by a small group of people who argue about trade offs in public, your host decides when their build changes, and your own code being clean does not protect you when the flaw sits underneath it. Knowing which of the 3 of you is responsible for an emergency update, before the next emergency, is the useful thing to take from this week.

The other lesson is about what you do with whatever a model hands you. A model that can read an engine for weaknesses can also write code with weaknesses, or recommend a package that does not exist, which is how slopsquatting catches people. The same habit covers both cases, check the thing at its source before you act on it, the way the record had to be checked when OpenAI withdrew 3 of its own math papers over a single sign error.

If you have handed an agent access to your own machine this year, this is a reasonable week to look at what it can actually reach, which is what our check of Full Disk Access on a Mac is for. Patch the Planet also deserves a fair reading here. Its first big result worked, with a human researcher who knew PHP's history at the front of it, and that is a better argument for the program than any headline about a model finding bugs by itself.

What we still don't know about PHP2Shell

3 questions are still open this morning, and they are short enough to list. How the attacker got the information days before anybody announced it is the first, and Amazon says in its own blog that it does not know. Anyone running PHP who wants a real answer about their own server has to go looking in logs that stretch back before the announcement.

Whether a real site was actually taken over is the second. Amazon says it is unclear whether those attempts would have succeeded against real systems, watchTowr reports attacks in the wild through its own honeypot network from release day onwards, and as of its update on Thursday the United States cyber agency had still not added either identifier to its catalog of exploited vulnerabilities. Those 3 statements are all true at once, and together they mean nobody can yet say how much damage was done.

Whether a model would have found this without a human who knew where to look is the third, and the firm that filed the first report says no. There is a sourcing note worth making here too. OpenAI's own post would not load for us this morning, so the OpenAI sentence quoted in this piece is the one implicator.ai printed after reading it, and the model names come from the PHP Foundation's post and from the firms themselves rather than from any summary.

What to watch next is whether anybody ever explains the early attempt, whether the foundation's new majority rule shortens the next argument about a fix, and whether the scanners now reading PHP's code find the next flaw before somebody outside the project does. Until then the job is dull and unavoidable, updating the runtime and asking your host when they did the same.