PHP2Shell: the PHP vulnerability that took government websites offline, and how to fix it.

On Tuesday afternoon, European time, two CVE numbers started doing the rounds on security forums. They came with almost nothing. No technical details, a release time that was wrong and a severity score that was wrong too. A day later, Belgium’s Centre for Cybersecurity was telling website owners who couldn’t update to take their sites offline, and the Flemish government had already switched off its own.

Our office is in Bangkok, so for us the leak arrived at around ten on Tuesday evening and the patch at half past eight the next night. That’s a long day if you look after PHP servers, and a lot of people do.

The pair now goes by the name PHP2Shell. The bugs aren’t in WordPress, a plugin or a framework. They’re in PHP, the software on the server that runs PHP websites, and W3Techs counts PHP on 69.3% of websites where it can see the server-side language. Send the right request to an unpatched server and either bug can let an attacker run their own code on it, without logging in. PHP’s security team scored both 9.2 out of 10.

The PHP security fix came out on Wednesday, in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP Foundation kept its advice short: “If you run PHP, it is imperative that you update now.”

If you own a PHP website and you’re not technical

You don’t need to follow every detail below. You need to know whether your website runs on PHP, and who is updating it.

If your site is built on WordPress, Drupal, Joomla, Magento or Laravel, it runs on PHP. Updating the site itself, its theme or its plugins doesn’t fix this one, because the problem is in the software underneath. That has to be updated on the server.

So send your host or your developer three questions about the PHP update today:

1. Is PHP on our servers now on 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a patched package from your Linux vendor?
2. Were the web server and PHP restarted after the update? Until they are, the old version keeps running.
3. Have you checked our logs for signs of an attack, going back to 17 October?

If the answer to the first question is that you’re on PHP 8.1 or older, ask what the plan is, because there’s no official fix for those versions. On managed hosting the host normally handles the update, but ask them to confirm it in writing. The rest of this post is the detail behind those three questions.

How the PHP2Shell disclosure leaked a day early

This was supposed to be a calm release. PHP’s security team had worked on the patches from August, and the Linux distributions got them in advance, under embargo. On Monday 19 October the release managers tagged the four fixed versions and kept them private, ready to publish on Thursday 22 October at 14:00 UTC.

Then the CVE numbers got out, at around 15:00 UTC on Tuesday. At 19:33 the team moved the release forward a day. Roughly half an hour later Calif, one of the security firms that had reported the bugs, published a proof-of-concept video by mistake, a working demonstration of the attack. It was taken down quickly, but people had already copied it.

Wednesday brought one more leak. Chainguard, a company that builds hardened container images, published patched PHP builds at 07:41 UTC, more than six hours early. Anyone who compared the old code with the new could start working out what had been fixed. The official files, the php.net announcement and the GitHub advisories went out between 13:31 and 13:35.

Someone, it turns out, was ahead of all of it. Amazon says its MadPot honeypots, decoy servers it runs to attract attackers, recorded an attempt to exploit PHP2Shell on Saturday 17 October. That’s four days before the patch and three days before the leak, and it isn’t known where the attacker got the details. On release day Amazon was seeing proof-of-concept exploits from about 02:00 UTC, some twelve hours before the fix was public.

What the two PHP vulnerabilities do

The full technical write-ups are in the advisories, linked at the bottom. This is the short version.

Both bugs are in the PHP interpreter, the program on the server that reads PHP code and runs it. WordPress, Drupal, Laravel, Symfony and every homegrown PHP application sit on top of it, which is why updating any of those doesn’t help. PHP itself has to change.

CVE-2026-109618 is about PHP running out of memory at a bad moment. The attacker sends a specially shaped file upload, for example one with no content length or with thousands of part headers, so PHP hits its memory limit while it’s still preparing the request. PHP stops halfway and leaves some of its own data half-built, then later reads that data as if it were fine.

CVE-2026-109619 is about what a PHP worker, the background process that handles page requests, carries over from one request to the next. A fatal error at exactly the wrong point can leave the worker holding on to memory from the request it just finished, memory that has already been freed. The next request on that worker then uses it. Security people call this a use-after-free, and with careful setup it becomes remote code execution. One way in is session upload progress, a PHP feature that’s switched on by default and works even if the website never starts a session.

The worst case is Apache with mod_php, because there the attack runs before the website’s own code is even involved. Other setups aren’t safe either. PHP’s own advisory names PHP-FPM, php-cgi, FrankenPHP and LiteSpeed alongside mod_php, and CISA’s alert says the bugs “affect all PHP installations serving web requests”. watchTowr, a firm that tracks real attacks, found that even PHP 5 is affected, for anyone still running something that old.

Found in 2024, fixed in 2026

This is the part I keep thinking about. The first bug wasn’t new at all.

In 2024 Quarkslab carried out an outside security audit of PHP, paid for by Germany’s Sovereign Tech Agency and arranged through OSTIF. While fixing one of its findings, a core developer working for the PHP Foundation saw signs of this memory problem. It looked exploitable in theory, but nobody found a concrete way to attack it. The security team couldn’t agree on a fix, and it stayed open.

This summer, three teams found it within about six weeks of each other. Calif started auditing PHP on 30 July under a programme called Patch the Planet, and reported remote code execution on 11 August. The Foundation made the fix its top security priority that same day. Wiz reported on 24 August, after its researchers had already made code execution work against Drupal and WordPress in their own tests, without logging in. OpenAI came on 18 September with more ways in.

Much of that digging was done with AI. Wiz says its researchers worked with Google’s Gemini 4 Argon and OpenAI’s GPT-5.6 Sol, together with its own tool, Wiz Atlas, to find the bugs, build working exploits and test the patch.

The people defending PHP use the same kind of tools. Alpha-Omega scanned PHP with Anthropic’s Claude Mythos earlier this year, and PHP’s security team has since added OpenAI’s Daybreak Red. Since 1 July the team has put out 15 CVEs. It has also had to work through more than 100 reports that turned out to be invalid, duplicates or impossible to reproduce. For a small group of people, that’s a lot of reading.

I respect how the Foundation has handled the delay. Its own post calls it “a structural failure”: decisions got stuck, and there weren’t enough people to push a fix through. The security team is moving to majority decisions, Alexandre Daubois and Daniel Scherzer have joined it since July, and the Foundation is asking the companies that depend on PHP to help pay for the work.

They should. A lot of businesses make their money on PHP and have never given anything back to it.

How big the risk was, and what we still don’t know

Until it was patched, every PHP site that serves web pages was open to this PHP vulnerability. How many were actually attacked is another question, and right now there’s no clear answer.

Amazon logged its 17 October attempt and more on release day, from other anonymised infrastructure, and says it can’t tell whether any of them “would have succeeded in real-world systems”. watchTowr reported exploitation in the wild on 21 October, picked up by its own honeypots. CISA, the US cybersecurity agency, said the same day that it hadn’t seen any yet. And when the patch came out, PHP’s security team hadn’t found a working exploit in the code that appeared after the leak.

Officials didn’t wait for a clearer picture. CISA told organisations that couldn’t update right away to take their PHP systems offline, and to do the same with anything on PHP 8.1 or older. The UK’s National Cyber Security Centre asked teams to look for signs of a break-in, backdoors included, and to consider taking systems offline if the temporary fixes couldn’t go in quickly.

Belgium went furthest. The Flemish government took its websites offline as a precaution, and the Ministry of Foreign Affairs and the Centre for Cybersecurity’s own website were down too. Inti De Ceukelaire, a Belgian ethical hacker, took his own sites down as well, something he told the Belga news agency he had never done before, The Brussels Times reported.

How to apply the PHP security update, step by step

This section is for whoever runs your servers. The PHP security update itself is simple. Making sure it has reached every server is the slow part.

Installing the new package doesn’t touch what’s already running. A PHP-FPM pool or an Apache process holds the old code in memory until it restarts, so restart all of them. Then check the version the web server really uses, because the command line can tell you something different. php -v reports the command-line PHP, and your pages may be served by another binary. The FPM binary’s -v option (it’s often named after the version, such as php-fpm8.3) only shows what’s installed, and a master process that hasn’t restarted still runs the old version. A temporary phpinfo() page served through the website is the reliable check, and the only one for mod_php. Delete it straight after.

Containers need their own PHP update. An app shipped as a Docker image carries whatever PHP was inside when the image was built, and patching the host changes none of that. Rebuild from a fixed base image and redeploy.

It’s easy to forget the PHP you never installed yourself. CISA points out that PHP is often part of other software, and the NCSC mentions appliances and services, so it won’t always be on a list of your own apps. Hosting control panels, for example, come with their own PHP. Ask your vendors which version they ship.

PHP 7.4, 8.0 and 8.1 are the awkward ones, with no official release. You can use a vendor package, build the PHP team’s source backport, or finally do the upgrade that keeps getting pushed back. For anything unsupported that stays unpatched, CISA’s advice is to take it offline.

Finally, check whether anyone used the PHP vulnerability before you patched, and start that search on 17 October. Amazon suggests searching web logs for POST requests that contain PHP_SESSION_UPLOAD_PROGRESS. Wiz suggests looking for unusual multipart requests followed by memory-limit errors, or sudden bursts of HTTP 500 errors. Oversized session cookies are a warning sign, and so are workers that crash and restart for no clear reason. A PHP worker that starts a shell or downloads tools, CISA says, is a very bad sign.

If you can’t patch the PHP vulnerability today

Sometimes an update has to wait for a change window, a vendor or a round of testing. The PHP team has published settings that make the attacks harder in the meantime, with a clear warning: “There are no complete mitigations, updating is the only safe choice.”

For the memory bug, the advice sounds backwards at first. Set memory_limit to -1, in a way the application can’t override, and cap memory outside PHP instead, ideally so that only the worker that runs out gets killed. A limit on the whole pool can take every worker down at once, and with no cap at all, one bad request can use up the server’s memory. Even then, php.net warns, a failed allocation underneath can still reach the vulnerable code. Keep post_max_size low, 8M if the site takes no uploads and 32M if it does, with upload_max_filesize below it. Don’t set RLIMIT_AS or RLIMIT_DATA limits at all.

The PHP team also recommends limits at the web server or proxy in front of PHP, on decoded request size, the number of input fields, multipart parts and headers, and they have to cover requests without a usable content length too. If the application doesn’t use multipart form data, the advisory says to block those requests at the front end.

For the stale memory bug, set session.upload_progress.enabled to 0 in php.ini, the FPM pool or the Apache config for mod_php, so it applies before the request is read. Don’t rely on ini_set() or an FPM .user.ini file. Then restart every worker. This blocks the known session routes, not every variant. If you don’t use the feature, the advisory suggests leaving it off after patching too. On PHP 8.5, set fatal_error_backtraces to 0 as well. On PHP-FPM, setting pm.max_requests to 1 makes every worker start fresh after each request, if the server can take the hit to speed. That makes an attack less likely to work, but the bug is still there.

Wiz says Cloudflare, Fastly, Vercel and others were preparing guidance and protection at their edge, and CISA says a web application firewall may help while you patch. Amazon also suggests blocking multipart file uploads where the application can manage without them, after testing what breaks. If none of that is possible, CISA’s advice is to take the system offline until it’s fixed, and the NCSC says to consider doing so.

What PHP2Shell changes for anyone running PHP

I don’t think one PHP vulnerability, even a bad one, is a reason to leave PHP. Serious bugs turn up in every language, and once the fix was ready, the PHP team moved quickly and was open about what went wrong.

What it changes is the speed you need. We’ve written about what AI coding tools do for developers, and PHP2Shell shows the other side. AI helped find these bugs, it will find the next ones sooner, and attackers can use it too. Amazon’s advice is to measure patching for critical, internet-facing flaws in hours, not days. That’s hard when the one person who knows where your servers are is asleep, on holiday or has left.

So the question I’d ask this week is a simple one. Who owns PHP patching in your company, and could they do all of the above again on a Tuesday night?

For many companies the true answer is “sort of”. Finding every server, rebuilding images, restarting workers and reading logs is everyday work for a good offshore DevOps team. Setting up the pipeline so the next patch ships within the hour is what DevSecOps engineers do. And if your product is built by PHP developers or on Laravel and its security has no clear owner, a dedicated cybersecurity team, fully managed by us, can take that on full time next to the people who build it.

Sources

Every figure, date and quote in this post was checked against the original publication on 23 October 2026.

1. PHP, Security advisory: critical remote code execution vulnerabilities, update now, 21 October 2026, and the advance notice of 20 October.
2. PHP security team, GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618).
3. PHP security team, GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619).
4. The PHP Foundation, Today’s PHP security release, and how we’re strengthening PHP security, 21 October 2026.
5. Daniel Scherzer, PHP 8.5 release manager, PHP2Shell: a timeline, 22 October 2026.
6. CISA, Critical vulnerabilities in PHP require immediate patching, 21 October 2026.
7. UK National Cyber Security Centre, Critical security issue affecting PHP, 21 October 2026.
8. CJ Moses, Amazon Threat Intelligence, PHP2Shell exploitation prior to public disclosure in MadPot, 21 October 2026.
9. Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities, 21 October 2026.
10. watchTowr, PHP2Shell FAQ, updated 22 October 2026.
11. W3Techs, Usage statistics of PHP for websites, 23 October 2026.
12. The Brussels Times, Major websites go offline as critical PHP vulnerability triggers security fears, 21 October 2026.