PHP2Shell: Why a Fully Patched WordPress Site Can Still Be Taken Over

If you run a WordPress site, you’ve probably made peace with the routine: update WordPress when it asks, keep the plugins current, maybe add a security plugin, and you’re in reasonable shape. For most of the problems that come along, that routine works.

This week’s problem is different. On October 21, the PHP project released fixes for two critical flaws in PHP itself, which researchers have nicknamed PHP2Shell. PHP is the engine that WordPress, and a huge share of the rest of the web, runs on. A site can have every plugin patched and still be wide open, because the attack never touches WordPress at all.

Below we’ll explain what PHP2Shell is, why the usual WordPress defenses can’t stop it, and what actually fixes it.

What PHP2Shell Is

PHP2Shell is the name for two vulnerabilities in PHP, tracked as CVE-2026-109618 and CVE-2026-109619. (CVE stands for Common Vulnerabilities and Exposures, the public catalog security flaws are filed under.) The PHP project rates both critical, at 9.2 out of 10 on the Common Vulnerability Scoring System (CVSS).

Without getting lost in the internals, both flaws come down to PHP mishandling its own memory while it’s dealing with an incoming request. One is triggered when PHP runs out of memory partway through reading a request, and the other when leftover data from one request is mistakenly reused by the next. In both cases, an attacker who sends the right request can end up running their own commands on the server, with no username or password required.

That’s about as serious as a web vulnerability gets. The PHP project confirmed full takeovers against servers that run PHP inside the Apache web server, and researchers have demonstrated one against a recent version of WordPress. Servers that run PHP through PHP-FPM, the way many hosts run it behind nginx, aren’t safe either. The PHP project has confirmed a takeover there too, under more specific conditions that depend on what the site itself does.

Why Plugins and Security Tools Can’t Stop It

Here’s the part that catches people off guard. When a request reaches your website, it passes through several layers before WordPress ever sees it. The web server hands it to PHP, PHP reads and unpacks it, and only then does WordPress, with its theme and plugins, get to run.

On the most direct attack path, PHP2Shell lands in that middle step. On servers that run PHP inside Apache, the vulnerable code runs while PHP is still reading the request, before a single line of WordPress executes. So a security plugin never gets the chance to inspect the request, and a WordPress maintenance mode doesn’t help either, because PHP has already done the dangerous part by the time WordPress checks whether the site is in maintenance.

Other paths, including the one confirmed on PHP-FPM, do pass through the website’s own code along the way. But the flaw being exploited is still in PHP, so updating WordPress or its plugins doesn’t close those paths either.

Why the Timing Matters

Normally there’s a bit of a head start between a fix being published and attackers putting it to use. Not this time. Details of PHP2Shell leaked ahead of the planned release, and Cloudflare reported seeing attack traffic aimed at its customers before the official patch was even out. Researchers widely expect mass, automated scanning now that both the fix and the technical write-ups are public.

Automated scanning doesn’t care how small or obscure your site is. It tries every address it can find. If your site runs on an unpatched version of PHP, the question is when, not if.

What Actually Fixes It

The only complete fix is updating PHP itself to a patched release. A site is protected once it’s running one of these versions, or anything newer:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Those numbers aren’t the only way to be fixed, though. Many hosts don’t run PHP straight from the PHP project. They use packages from their operating system vendor, such as Ubuntu or Red Hat, and those vendors often apply the fix without changing the main version number. Ubuntu 24.04, for example, fixed both flaws in a package that still reports itself as PHP 8.3.6. So there are two good answers: one of the versions above, or a vendor package that’s documented as fixing both CVE-2026-109618 and CVE-2026-109619.

If a site runs PHP 8.1 or older straight from the PHP project, there’s no fixed release at all, since those versions are past the end of PHP’s support. It needs to move to a supported version, or onto a vendor package that has been patched.

Not sure which version you’re on? If you can log in to WordPress as an administrator, go to Tools, then Site Health, then the Info tab, and open the Server section. It lists the PHP version the site is actually using. Treat that as a starting point rather than the final word: a vendor-patched package can show an older number and still be fixed, so your hosting company is the one who can confirm it.

Habits That Make This Easier

1. Know who’s responsible for your website. For a lot of businesses it’s a web developer, a marketing agency, or a hosting company, and nobody inside has the login. Write down who it is and how to reach them before you need them.
2. Keep a list of every site you run. The main website is rarely the one that gets missed. It’s the client portal, the booking tool, the old event microsite, or the intranet that was set up years ago and quietly runs on an ancient version of PHP.
3. Ask for a clear yes, not a reassurance. “We keep everything up to date” isn’t the same as “we updated PHP to 8.3.36 this morning.” For something this serious, ask for the version number, and if they patch through their operating system vendor, the security notice that covers both flaws.
4. Be willing to go offline for a day, properly. If a site can’t be patched right away, ask your host to stop PHP from handling any public request at all, either by blocking traffic before it reaches PHP or by switching PHP off, and to serve a plain static notice instead. Swapping the homepage for a “back soon” page or turning on a WordPress maintenance plugin isn’t enough, because pages like the login screen can still reach PHP behind it. A day offline is far cheaper than cleaning up after a compromise.

What to Ask Your IT Team or Web Host

If you’re not sure where you stand, these are good questions to bring to whoever looks after your sites.

• What version of PHP is running on every server that hosts our sites, and when was it updated? The answer should be either one of the fixed versions above or a package from their operating system vendor that’s documented as fixing both CVE-2026-109618 and CVE-2026-109619. Ask them to confirm the web server is actually running the fixed version, not just that it’s installed. If any server is on PHP 8.1 or older without a vendor patch, ask what the upgrade plan is.
• Are our sites behind a web application firewall (WAF)? Cloudflare switched on protections for PHP2Shell by default for sites using its WAF, including on its free plan. That’s useful breathing room, but Cloudflare itself says it doesn’t replace updating PHP.
• If you can’t update today, what’s the interim plan? The PHP project lists configuration changes that reduce the risk, such as removing PHP’s per-request memory limit and blocking file-upload style requests at the web server when a site doesn’t need them, but it’s clear that none of them are a complete fix. Taking the site offline until it’s patched is the safest option, as long as offline means no public request reaches PHP at all.
• How would we know if someone already got in? Ask them to check for administrator accounts nobody recognizes, files that changed unexpectedly, and unusual outgoing email from the server. Given that attacks started before the patch, it’s worth looking even on sites that are now updated.

The Bottom Line

PHP2Shell is a reminder that keeping WordPress and its plugins current is necessary, but it isn’t the whole job. The engine underneath matters too, and this time it’s where the problem is. Find out which version of PHP your sites run, get them onto a fixed release today, and if you’d like a hand figuring out where you stand, get in touch.