PHP2Shell, and why this patch can't wait

Two flaws in PHP itself let a stranger run commands on a web server with one request. What PHP2Shell is, in plain terms, why no setting fixes it, and why updating is the only real answer.

7 min read

On 21 October the PHP project released updates for every supported version of PHP and asked everyone to install them immediately. The two flaws they fix, CVE-2026-109618 and CVE-2026-109619, have been given a shared name, PHP2Shell, and the name is the summary: a way to go from an ordinary web request to a shell, the command line of the server behind a website. Neither needs a password. In the configuration PHP rates riskiest, the attack works before the website’s own code has even started.

PHP is the language behind WordPress, Drupal, Joomla, Magento, Nextcloud and a long tail of company websites, online shops and admin panels. Most people who run one of those have never thought about PHP at all, which is exactly why this one matters. The flaw isn’t in anyone’s website. It’s in the layer underneath, so careful code doesn’t protect you, and the fix has to come from whoever looks after the server.

What PHP does on a server

When someone visits a PHP website, the web server hands the request to a PHP worker: a small program that reads what the visitor sent, runs the site’s code, and returns a page. Workers are reused. One worker might serve thousands of visitors in a row, tidying up after each one before taking the next.

A hotel room is a fair picture. Between guests, housekeeping resets the room so the next guest finds it clean and finds nothing of the last guest’s. Both PHP2Shell flaws are failures of that reset.

What the two flaws are

Interrupted while setting up (CVE-2026-109618). Every running program has a memory budget. When PHP runs out of memory, it stops what it’s doing at once and abandons the request. According to PHP’s advisory, if that happens while PHP is still setting up a new request, the clean-up afterwards treats half-prepared data as if it were complete. In the hotel picture, housekeeping is called away mid-change, and the next shift assumes the room is ready. An attacker can cause this on purpose, because the oversized, oddly built upload forms that exhaust the budget are something anyone can send.

Something left behind (CVE-2026-109619). PHP’s second advisory describes information about one request surviving after the memory that held it has been given back. The next request handled by the same worker can pick up that leftover before the normal reset runs. That is a key to a room that has since been given to someone else, still in the drawer, still working.

Neither sounds dramatic. In both cases, though, PHP ends up trusting memory it no longer controls, and an attacker who can shape what goes into that memory can steer what PHP does next. Both advisories rate the result at 9.2 out of 10 on the standard severity scale (CVSS v4.0) and describe the outcome as unauthenticated remote code execution: a stranger, without logging in, running their own commands on the server with the permissions of the web worker. Wiz Research, which reported the flaws alongside researchers at OpenAI and Calif, also showed the leftover-memory route can leak what’s in a worker’s memory, including passwords, tokens and API keys.

9.2 / 10
severity of each flaw (PHP advisories, CVSS v4.0)
69.3%
of sites with a known server language use PHP (W3Techs, Oct 2026)
34.7%
of PHP sites on version 7 or older (W3Techs)

Who it affects

PHP’s own advisory is blunt: “all PHP installations serving web requests” are at risk, whichever way PHP is connected to the web server (PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed are all named). The team considers the risk highest for mod_php, the long-standing Apache setup common on shared hosting, where it has seen a working attack trigger “before any application code runs.”

That last detail explains why application security doesn’t help here. A WordPress site with every plugin up to date and every password strong is still exposed, because the attack lands in PHP before WordPress is consulted. Wiz says it achieved remote code execution against the latest official container images of WordPress, Drupal and Joomla. The vulnerable code goes back to PHP 5.4, over a decade.

The scale comes from how much of the web PHP runs. W3Techs measures PHP on 69.3% of the websites whose server-side language it can identify. Its version breakdown shows 26.9% of those sites on PHP 7 and 7.8% on PHP 5 or older. The PHP project fixed versions 8.2 to 8.5; 8.1 and earlier no longer get official releases, though for this case it published minimal source fixes for 7.4, 8.0 and 8.1. A third of PHP sites are on versions where getting the fix means a vendor’s backport, building from source, or an upgrade that was overdue anyway.

Why it was fixed now

The bugs are old. Wiz’s write-up is direct about what changed: frontier AI models, Google’s Gemini 4 Argon and OpenAI’s GPT-5.6 Sol among them, made exploiting this class of bug practical in weeks rather than months of specialist work. In Wiz’s words, “LLMs can help adapt an exploit to different PHP versions, configurations and memory layouts.” That is the part that used to protect most servers: a memory bug like this needed a different exploit for each version and setup, and few people could write one.

The timeline after that was a normal, careful disclosure. Wiz confirmed the flaws between 19 and 21 August, reported them to PHP’s security team on 24 August, and the team spent the following weeks building a fix and sharing it in advance with Linux distributions and support vendors. On 20 October PHP announced that a release would follow at 14:00 UTC the next day, reserving the right to ship early if details leaked or attacks appeared. Attackers didn’t wait for either. Sansec reports that Cloudflare saw early attacks at 07:43 UTC on 21 October, hours before the release, and BleepingComputer quotes Cloudflare’s CTO saying the company was “already observing early attacks” despite the firewall rules it had put in place.

Why patching is the only real answer

There are three reasons, and each closes off a shortcut people usually reach for.

No setting makes it safe. PHP’s advisory lists temporary measures for anyone who can’t update straight away, such as removing the memory limit, shrinking the maximum upload size and switching off upload progress tracking. It says plainly that they “reduce exposure to specific attack paths but do not make an installation safe.” Each blocks one known route. Updating removes the flaw.

A firewall only blocks what it recognises. Services such as Cloudflare added rules to filter attack traffic, and those rules buy time. They match known attack patterns, though, and the attack is built from requests that look much like ordinary form submissions. Cloudflare’s own report of attacks continuing behind its rules is the clearest evidence of the limit.

The clock now runs faster. A published patch shows exactly which lines of code changed, and with the same AI tools that helped find these bugs, working backwards from a patch to an attack is quicker than it has ever been. The window between “fix released” and “attacks everywhere” used to be measured in weeks. For PHP2Shell, attacks started before the fix was out.

What to ask whoever runs your site

If you don’t manage your own server, three questions to your host or developer cover it.

  1. Which PHP version are we on, and is it 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer? Managed hosts and Linux distributions received the fix early and many have already rolled it out, but “should be” isn’t “is”. If the answer is 8.1 or older, the follow-up is when you’re moving to a supported version.
  2. Does anything else we run bundle its own PHP? The UK’s National Cyber Security Centre asks organisations to find every PHP installation, including inside third-party software and appliances. Hosting control panels and admin tools often carry their own copy.
  3. Has anyone checked for signs of a break-in? Updating closes the door; it doesn’t evict anyone who came through it. The NCSC advises checking for “backdoors installed by an attacker” on any system that couldn’t be updated immediately, and considering taking a system offline if it can’t be protected quickly.

How we think about it

Most of a website’s security is in code nobody on the project wrote: the language, the server, the libraries. PHP2Shell is a reminder that the job of keeping software safe doesn’t end at launch, and that it belongs to a named person, not to whoever notices first. When we build or look after software, we treat the runtime underneath it as part of what we’re responsible for, and we decide in advance who applies an update like 21 October’s, and how quickly.

Sources

Read next

Research 16 October 2026 11 min read

What happens when every chunk knows its document

We tested Voyage's context-aware embeddings on our journal, research papers and contracts. Context helps when a question is about the document. Finding the paragraph is still your job.

Read article
Code 6 October 2026 9 min read

Build your own dot

OpenAI's dots are always-on agents with memory, their own computer, a schedule and your apps. Each part is buildable today. Here's one on Cloudflare, with the approval step that keeps it safe.

Read article

Got an idea?Tell us about it.

Send a short brief. We'll come back with questions, a call slot and a straight answer on whether we're the right team.

Start a project