If you've talked to anyone who runs a website this week, there's a good chance "PHP2Shell" came up. Several of our clients asked us about it before the fix was even public.
The short version: two critical security flaws were found in PHP, the programming language WordPress is built on. Because every WordPress site runs on PHP, every WordPress site was in scope. The PHP project released a fix on October 21, 2026, and our servers had a temporary protection in place about ten hours before that. Later the same day, we installed the fixed version of PHP on our servers and confirmed on each one that it's what is actually running your site.
Here's what happened, why updating WordPress or your plugins doesn't help with this one, and what to check if you manage your own server.
Do WP Haven clients need to do anything?
No. This one is fixed on the server, not inside WordPress, and that's our side of the line. The rest of this post explains what we did and why, so you know what to look for if you also have sites hosted elsewhere.
What is PHP2Shell?
PHP is the software that runs WordPress behind the scenes. Every time someone visits your site, PHP builds the page they see. PHP2Shell is the nickname for two flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619.
In plain terms, both flaws can leave PHP in a confused state after an unusual request, for example one that makes it run out of memory or hit an error at just the wrong moment. A carefully crafted request can use that confusion to run the attacker's own code on the server, without logging in to anything. That's what "shell" in the name refers to: getting a foothold on the server itself.
Both are rated 9.2 out of 10, which counts as critical. CISA, the US government's cybersecurity agency, says they affect every PHP installation that serves websites. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
When CISA published its alert, it hadn't seen these flaws used in real attacks yet. Qualys reports that attempts are already showing up, though. Attackers now use automated tools to study a security fix and work out how to exploit it within hours. We saw exactly that with the wp2shell WordPress vulnerability in July, and it means the gap between "patch released" and "attacks start" keeps getting shorter.
Why updating WordPress won't fix it
A few things make this one different from the usual WordPress security news:
- It isn't a WordPress bug. Updating WordPress, your theme or your plugins doesn't fix it. The fix is a new version of PHP, which lives on the server.
- It can be triggered before WordPress even loads. On servers that run PHP inside Apache (a setup called mod_php), the PHP team showed an attack that works before the site's own code runs. PHP-FPM, the setup most modern WordPress hosting uses, ours included, is harder to attack this way, but it's still affected.
- Older PHP versions won't get the official fix. PHP 8.1 and earlier no longer receive updates from the PHP project. CISA's advice for anything still on those versions is to take it offline until it can be upgraded.
How we protected our sites
Step one: a temporary protection before the release
Hosting platforms get advance notice of security releases like this one, so they can prepare. Our server management provider used that time well. Overnight, about ten hours before PHP published the fix, it switched off a PHP feature called session upload progress on every server we run with them, whether the server uses Nginx or LiteSpeed. That blocks the known ways of exploiting the second flaw.
The trade-off is small. File uploads still work as normal. The only side effect is that an upload progress bar that depends on this feature may not move while a file uploads.
We checked rather than assumed: the setting was in place for every version of PHP serving a site, and spot checks confirmed PHP had actually picked it up.
A temporary protection isn't a fix, though. It blocks the attacks that were known on the day. Only the updated PHP closes the flaws themselves.
Step two: installing the fixed PHP
Our provider builds its own PHP packages, so the fixed versions came from them rather than directly from the PHP project. They tested the new builds before publishing them, which is the right call: a security update that breaks sites on the way in just trades one emergency for another.
Once the builds were out, we didn't wait for them to roll out on their own. We checked, found that none of our servers had picked them up yet, and installed them ourselves later that same day, about eight hours after PHP's release. That covered 33 servers, both Nginx and LiteSpeed, including the production, staging and maintenance copies of our sites. Staging and maintenance copies matter here: they run on the same PHP as the live site, and an attacker doesn't care which copy they get in through.
We updated only PHP. A full server update would also have restarted things like the database, and that wasn't worth a blip on every site. We tried it on our own staging server first, checked the sites on it, and then rolled it out to the rest.
One client server we look after sits outside our main hosting platform, so the provider's update doesn't reach it. There, we installed the fixed PHP from Ondřej Surý's packages, the community-maintained source most Ubuntu servers use for current PHP versions. Along the way we found an outdated duplicate package source that was stalling every update on that server, which is exactly the kind of thing that makes a server look updated when it isn't. We also switched off older versions of PHP that were still running there but no longer used by any site, since anything left running is something that can be attacked.
Step three: making sure the fix is actually running
This is the step that's easy to miss.
Installing a new version of PHP replaces the files on the server, but PHP that's already running keeps using the old copy until it's restarted. On most WordPress hosting, PHP-FPM keeps a handful of PHP processes running between visits so pages load quickly, and those keep running the old, vulnerable code until they restart. A server can report the new version while every visitor is still being served by the old one.
So after updating, we checked every server to confirm that:
- the new PHP version was installed for every version a site uses
- the running PHP had restarted after the update
- nothing was still running the old, replaced copy of PHP
Nothing was. We then loaded sites on every PHP version to make sure they still worked.
Step four: extra protection for sites on older setups
Security releases like this one only cover current PHP versions on current systems. For sites on our hosting servers that run an older version of PHP, or sit on a server with an older operating system, we went further than the protection from step one.
Normally PHP reuses the same process for many visits in a row. On those sites, we set it to start a fresh one for every visit instead. That fully closes the second flaw, because no visit can be affected by anything an earlier one left behind. We did the same on PHP-FPM and LiteSpeed servers, which each have their own version of this setting. The cost is a little extra work per page load, and we checked the sites afterwards to make sure they're loading normally.
It's a stopgap. The lasting fix is moving those sites to a current PHP version and server, and we've already reached out to the owners of those sites to plan that.
Why we encourage clients to use Cloudflare
We encourage our clients to put their sites behind Cloudflare, and PHP2Shell is a good example of why. Cloudflare's firewall sits in front of your site and filters traffic before it ever reaches the server. For this vulnerability, Cloudflare had protection rules in place about nine hours before the fix was made public, and they were switched on automatically, even on the free plan. On paid plans, it's worth checking that Cloudflare's managed rules are set to block.
A firewall in front of your site doesn't replace updating PHP, and it only protects traffic that actually goes through Cloudflare. But it's an extra layer that often catches new attacks before anyone has had time to patch, and that's exactly the window attackers aim for. If your site isn't behind Cloudflare yet, ask us about setting it up.
If you manage your own server
If your site isn't hosted with us, here's what we'd check. The PHP changelog and CISA's alert have the full technical details.
- Find out which PHP version your site uses. In WordPress, go to Tools → Site Health → Info → Server. If you're on managed hosting, check your host's status page or ask them whether they've installed the October 21 release.
- Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or newer. If your server gets PHP from your Linux distribution's own packages, the version number may not change, because distributions often add the fix to the version they already ship. Check your distribution's security notice instead.
- Make sure the update actually reached your server. Updates aren't always picked up right away, and a broken or unreachable package source can make an update quietly skip packages. On Ubuntu and Debian,
apt updateshould finish without errors before you trust the result. - Restart PHP-FPM (or Apache, if you use mod_php, or LiteSpeed), then confirm the new version through the website itself, not just with
php -von the command line. - If you're on PHP 8.1 or older, plan the upgrade now, and test your site on a newer version in staging first, since older themes and plugins can break. Until then, there are two places a fix may still come from. Ondřej Surý's PHP packages for Debian and Ubuntu include a backported fix for PHP 7.4, 8.0 and 8.1, written by PHP's own developers. Ubuntu has also published fixes for the PHP versions that came with Ubuntu 16.04, 18.04 and 20.04, through its paid Ubuntu Pro service.
If you can't update straight away, the PHP team recommends turning off session.upload_progress.enabled in your PHP settings, the same temporary protection from step one. Putting the site behind Cloudflare adds another layer while you work on it. Both are stopgaps, not fixes: updating PHP is the only complete solution.
Why this was on our side of the line
When a WordPress plugin has a security flaw, there's usually a button in your dashboard that fixes it. When PHP itself has one, there isn't. The fix happens on the server, and if you're on shared or unmanaged hosting, it's either your hosting company's job or yours. You often don't find out which until something like this happens.
Most hosting plans include the server, but not the work of keeping it current, checking that an update actually took effect, or noticing that a site is still running on a version of PHP that stopped getting fixes years ago.
WP Haven covers the whole stack, from the server and PHP up to WordPress, its plugins and your content. When a vulnerability like PHP2Shell is announced, there's no question about whose job it is or which sites have been checked. Our goal is that by the time you read about something like this in the news, your site was already taken care of.
Explore our plans and see how we keep your WordPress sites secure at wphaven.app.