PHP2Shell: the day websites started switching themselves off

On Wednesday 21 October, the PHP project fixed two flaws that let a stranger run their own code on a web server without logging in. PHP is the language underneath WordPress, WooCommerce, Drupal, Joomla, Magento and Laravel apps. It runs about 69 per cent of the websites whose server-side language W3Techs can identify. Finland, the Netherlands, France, Germany and Belgium took government websites offline while they patched.

If you have a WordPress site, today's job is short: find out which PHP version it runs, and ask your host whether the 21 October fix is installed. Most of you will need one email. A few will need a longer conversation.

Two quiet years, then twenty-three hours

The bug is older than the panic. In 2024, during a security audit the PHP Foundation arranged funding for, one of PHP's core developers spotted the first signs of trouble in how PHP handles running out of memory. Nobody found a concrete way to attack it, the competing fixes each had drawbacks, and the work stalled. The Foundation's own account calls that "a structural failure".

Then the AI-assisted audits arrived. On 30 July 2026 the security firm Calif started auditing PHP under OpenAI's Patch the Planet programme, and on 11 August it reported a working attack with the same root cause. OpenAI reported the same root cause independently that day, and Wiz reported a further attack path on 24 August. Wiz's researchers wrote that frontier AI models "were critical to making this process practical."

The plan was a quiet release on Thursday 22 October, with Linux distributions given the patches in advance. It went like this instead (times in UTC, from the PHP Foundation's account unless marked):

• Tuesday, about 15:00. The CVE numbers start circulating online, with the wrong severity score and the wrong release time.
• Tuesday, 19:30. PHP confirms the release and moves it forward a day.
• Tuesday, about 20:00. Calif publishes a video of its exploit by mistake. It comes down, but copies spread.
• Wednesday, 07:34. Hosting partners report active exploitation to Patchstack.
• Wednesday, 07:41. Chainguard, a software vendor, publishes builds containing the fix more than six hours before the agreed time.
• Wednesday, 13:52 (just before 17:00 in Finland). PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released, by Patchstack's timestamp. The agreed time was 14:00.

Security releases are supposed to be dull. This one had a leak, a deleted video and a vendor six hours early.

Why a PHP bug closed the weather service

Most website problems live in a plugin, a theme or an old copy of WordPress, and the fix is an update in the dashboard. This one lives a layer lower, in PHP itself, the engine that runs WordPress and everything built on it.

There are two separate bugs, both in how PHP manages its own memory. In the first, PHP runs out of memory at an unlucky moment and leaves internal data half set up, and the clean-up afterwards treats that broken data as valid. In the second, a fatal error leaves internal state pointing at memory that has already been freed, and the next request handled by the same PHP worker can use it. With a carefully built request, either one becomes a way to run code on the server, and the attacker doesn't need a password. The PHP advisory says every installation serving web requests is affected, whether it runs as PHP-FPM, Apache's mod_php, php-cgi, FrankenPHP or LiteSpeed, and it rates the risk highest for mod_php. That's where the attack was shown working with default settings, before any application code runs. On PHP-FPM it was confirmed through paths that depend on the application. Wiz demonstrated the attack against the latest WordPress container image.

So updating WordPress and every plugin you own does nothing for this one. The hole isn't in WordPress.

Until a server is patched, the only vulnerable server that is definitely safe is one nobody can reach. That's why the NSA told organisations to take systems offline if they couldn't update right away. It's also why Valtori, the Finnish state's IT centre, took public government sites offline on Wednesday afternoon, Yle reported. The National Land Survey, Oikeus.fi and the Finnish Meteorological Institute's online services were among them. Valtori said nothing had been breached. The closures were there to keep it that way.

One footnote on the "70 per cent of the web" headlines. W3Techs counts sites whose server-side language it can detect, so it's a share of a large sample, not a census of the internet. It is still most of the web.

Where your site probably stands

Most site owners never touch PHP directly. Who patches it depends on where the site lives. This is the picture from Codeable's host roundup on Wednesday evening.

One catch: hosts often apply the fix without changing the version number you see, so an old-looking number may already be patched. Ask rather than guess.

The ten-minute check

1. Find your PHP version. In WordPress, go to Tools, Site Health, the Info tab, then Server.
2. Email your host and ask: "Have you applied the 21 October PHP security release to the server my site runs on, and which PHP version am I on?" Get the answer in writing.
3. Don't install a "PHP2Shell fix" plugin or paste in a snippet from a forum. Patchstack advises against both, and a plugin runs inside the thing that needs fixing.
4. If you use UpdraftCentral, delete its keys. Patchstack reports that an attacker with valid keys was installing backdoors on connected WordPress sites. It's a separate problem, which Patchstack reported on 19 October, two days before the PHP release.
5. If you can't get confirmation and the site takes payments or stores customer data, ask your host to block traffic to it or take it offline until the fix is in. WordPress's own maintenance mode isn't enough here, because the attack can run before any WordPress code does.

The sites with no patch coming

The fixes cover PHP 8.2 to 8.5. PHP 8.1 and anything older gets no regular release from the PHP project. PHP did publish minimal source patches for 7.4, 8.0 and 8.1, and some Linux distributions and paid support vendors backport fixes into their own packages. So whether an older version gets fixed depends on who supplies your PHP, and your host is the one who can tell you. If there's no fixed package for your version, "update PHP" means moving to a newer major version, and that's a project, not a button.

That group isn't small. On W3Techs' figures for Wednesday, 27 per cent of PHP sites run version 7 and almost 8 per cent still run version 5.

Sites usually stay on old PHP because something breaks on the new one. Usually it's a theme that stopped getting updates, a page builder from another era or a plugin someone customised years ago that nobody dares touch. Each year the upgrade costs more to start, so it doesn't start.

And one more date. PHP 8.2, one of the versions that got Wednesday's fix, reaches end of life on 31 December 2026. A site moved to 8.2 this week has ten weeks before it's back in the same queue.

A patch, a tidy-up or a new site

I work on WordPress and WooCommerce sites as well as building in Next.js, so this isn't a post about PHP being finished. It isn't. For most sites the sensible order is:

1. Patch today, through your host. It usually costs nothing.
2. Tidy up. If the site is on PHP 8.1 or older, move it to a supported version newer than 8.2. Test the theme and plugins on a staging copy first, and remove what nobody uses.
3. Rebuild only when the tidy-up turns out to be the expensive option.

A rebuild makes sense when the upgrade means replacing the theme anyway. When the site needs a long list of plugins to do what five pages and a contact form could do. When every WordPress update is a small gamble somebody has to take. At that point you're paying to keep an old structure standing, and the same money could go into something with fewer moving parts.

What I'd build instead is usually a Next.js site where most pages are generated ahead of time and served as files. For pages built that way, someone reading your services page isn't running code on your server, so there's less to attack and less to patch. Anything dynamic, such as a contact form or a checkout, still runs on a server and still needs looking after. You still edit the content yourself through a headless CMS.

It isn't immune, and I'd rather say so here than on a call. In December 2025 a flaw called React2Shell hit React Server Components, which Next.js uses, with the maximum severity score of 10.0. Every stack gets its turn. What changes is how much of your site runs on a server for each visitor, and how quickly someone notices when a fix ships.

If you move, the part that matters most is keeping what the old site earned: the URLs, the redirects and the rankings. That's the first thing I plan in a migration, and it's the same work that decides whether search engines and AI answers still find you afterwards.

Where I come in

If you're not sure where your site stands, book a 30-minute call. It's free, nothing is bought on it, and I work in Finnish as well as English. By the end you'll know whether you need an email to your host, an upgrade or a bigger conversation. For a website, the call is usually enough to scope the work and quote it, and the price ranges are on the services page.

Short answers

Does updating WordPress fix PHP2Shell?

No. The flaws are in PHP, the language WordPress runs on. Keeping WordPress, themes and plugins updated is still good practice, but only a PHP update fixes this.

Which PHP versions are fixed?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or a distribution package your host confirms includes the 21 October fix.

Has my site been hacked?

Patchstack received reports of active exploitation from hosting partners on Wednesday morning. By the afternoon, its own monitoring showed only probing attacks, with no hard evidence of break-ins yet. So attacks are happening, but that doesn't mean a given site was breached, and you can't tell from the outside either way. Wiz lists signs a host can look for in the server logs: repeated 500 errors, memory-limit errors after unusual upload requests, oversized PHPSESSID cookies and PHP workers restarting for no clear reason. If your host finds them, ask for a proper clean-up, not only the patch.

Do I need a new website?

Most sites don't. Patch first. A rebuild makes sense when getting off an old PHP version means replacing most of the site anyway.

Why does AI keep coming up in this story?

Calif reported the first working attack from an audit under OpenAI's Patch the Planet programme, and Wiz used AI models to find and test a further attack path. PHP's security team has published 15 CVEs since 1 July. Yle quoted Roni Kokkola of Finland's National Cyber Security Centre saying AI tools have sped up both finding vulnerabilities and exploiting them. More of these are coming, which is the best argument for a site that someone actually looks after.

Last checked on the evening of Wednesday 21 October. The story is still moving, and I'll update this post as hosts finish patching.