PHP2Shell: What WordPress Site Owners and Hosts Need to Know

Ryan Haylett

What if your WordPress site could be taken over by a visitor who never touches WordPress at all? No login, no vulnerable plugin, nothing. That's the situation with PHP2Shell, and Dave, I want to make sure people understand the bug lives underneath their site, not in it.

Dave Rowley

Right, and that's the part that trips people up. PHP is the engine. WordPress, Drupal, Joomla, MediaWiki, they're all applications running on top of it. PHP2Shell is actually two vulnerabilities, CVE twenty twenty six, one oh nine six one eight and CVE twenty twenty six, one oh nine six one nine. Both are rated 9.2 on the CVSS version 4 scale. The researchers showed an unauthenticated attacker can run their own code on the server. The researchers at Wiz put it plainly: even a bare Hello World script on an affected PHP version can be vulnerable.

Ryan Haylett

And the timeline matters here. This was supposed to be a coordinated disclosure on October 22nd. Details leaked on social media on October 20th, so the PHP team moved up and announced an emergency release for Wednesday, October 21st at 14:00 UTC. Then watchTowr reported seeing exploitation in the wild through its honeypot network on that same day. And the NSA put out an advisory telling organizations to inventory their internet facing PHP and patch.

Dave Rowley

Which, for the NSA to name a programming language in a press release, tells you something. So let me walk through the mechanism, because it's actually elegant in an ugly way. Picture a PHP worker, the process that handles your web requests. It handles one request, then another, and it reuses memory and internal bookkeeping between them. Now, at the very start of a request, PHP parses multipart uploads, the kind of request a file upload form sends. That happens early, before normal initialization is finished, and before any WordPress code has run.

Ryan Haylett

So there's a window where PHP is half set up.

Dave Rowley

Exactly. If PHP runs out of memory in that window, it hits a fatal error. It destroys the memory heap for that request, but some internal pointers still point at the memory that was just thrown away. The cleanup never finished. Then the next request handled by that same worker comes in, and PHP trusts those stale pointers as if they were live data. If an attacker has arranged for that freed memory to be reclaimed with content they control, PHP is now acting on attacker data.

Ryan Haylett

That's the use after free idea, right? Something gets freed, but the program keeps a reference to it.

Dave Rowley

Yes. And it shows up in a few ways. In one, PHP can end up reading that reclaimed memory and putting its contents into a PHPSESSID cookie in the response. That's a memory disclosure, and the researchers said the memory can contain passwords, tokens, API keys and certificates. It works even if the app never starts a session. In the others, a fatal error backtrace pointer goes stale, or the OPcache, which stores compiled PHP in shared memory, gets confused about object types between workers. Those paths lead to corrupted memory and code execution.

Ryan Haylett

And just to be clear for the listener, the researchers demonstrated working remote code execution against the latest container images of WordPress, Drupal and Joomla. Those were representative targets. The bug doesn't care which CMS you run.

Dave Rowley

Here's what bugs me, though. These flaws were old. The Wiz write up says the vulnerable code goes back more than a decade, and they say every PHP version in the last decade is affected by at least one of them, back to 5.4. So why now?

Ryan Haylett

That's the AI piece, and I think it's the most important takeaway from the whole story. The researchers say the hard part was never spotting that something looked off. The hard part was turning it into a reliable exploit. You have to chain several flaws together, and memory layouts differ across PHP versions, configurations, and applications. An exploit that works on one server can fall apart on the next, and every adjustment means more debugging.

Dave Rowley

Which used to be a human bottleneck. You needed rare people with lots of time.

Ryan Haylett

Right. Wiz says they used frontier models, Gemini 4 Argon and GPT five point six Sol, along with their own tool, Wiz Atlas, to debug failures and adapt working exploits across multiple applications in hours. Their claim is that a single researcher finished in about a week what would have taken a world class team months. That's their framing, and they're a security company with a stake in the story, so weigh it that way. But the direction is hard to argue with. Complexity used to be a kind of protection, and it's getting weaker.

Dave Rowley

And it cuts both ways. The same tools help defenders find these things before attackers do. But when you're a host, the practical lesson is that the gap between a bug being disclosed and a bug being weaponized is shrinking. watchTowr saw exploitation the same day as the patch.

Ryan Haylett

Which is why speed on our side matters more than ever. So let's talk about what a responsible host actually does in a moment like this.

Dave Rowley

First, the shared responsibility model, because it explains who owns what. As a host, we own the runtime: the PHP engine, the web server, the operating system libraries. Our customers typically own the application layer: WordPress core, plugins, themes, user accounts. PHP2Shell sits entirely in our half. So when we talk to customers, the headline is that for this specific issue, there's nothing they need to patch themselves.

Ryan Haylett

And what we did started before the official fix existed. We tightened firewall rules, and added extra protections where they applied. Hosts that were in the loop could look at the shape of these attacks, things like malformed multipart uploads and odd session headers, and filter at the edge. That buys time, but I want to be honest about it. It's a stopgap. PHP itself says no configuration change fully mitigates this. The real fix is the patched engine.

Dave Rowley

Then the patches roll out. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. And here's a detail people miss: updating the binary isn't enough on its own. The workers hold state in memory, and that stale state is the whole problem. So you restart the PHP workers after updating so the fix takes effect. That's why some customers might see a brief service restart. We'd rather do rolling restarts and keep it short than leave a poisoned worker running.

Ryan Haylett

And we watch. The researchers suggest signals worth looking for: unusual multipart requests followed by memory limit errors, repeated HTTP 500 responses, strangely large or malformed PHPSESSID cookies, and unexplained worker churn. Because this happens below the application, normal app logs may show very little. So you're hunting in server level logs.

Dave Rowley

Now the hard part for hosts is older PHP. PHP 8.1, 8.0 and 7.4 get no standard official release. You can use a distribution or long term support vendor package, or PHP's minimal source backports. And PHP 7.3 and older, including PHP 5, have no fix at all. watchTowr confirmed those older branches are affected too.

Ryan Haylett

So let's give people the dos and don'ts. Do confirm with your host that server level updates are applied. Don't just assume. Do log into your hosting panel and check what PHP version your site runs. If you're on 7.x, or 8.0 or 8.1, you're in the danger zone, and you need to schedule a move to 8.2 or newer.

Dave Rowley

Do keep updating WordPress, themes and plugins. That doesn't fix PHP2Shell, but neglected plugins are their own door into your site. Now the don'ts. Don't count on a security plugin to save you. Those plugins run inside WordPress, and this bug fires in the engine during request startup. For PHP's most exposed setup, Apache mod PHP, PHP says an attack can succeed before any of the application's own code has run. Security plugins are still useful for other threats, just not this one.

Ryan Haylett

And don't go hunting for a snippet. There's no functions.php hook, no htaccess line, no php.ini tweak that patches a memory allocation failure inside the C engine. If someone online sells you one, be skeptical.

Dave Rowley

Then there's the gray area, which is honestly the hardest. Plenty of business sites run on an abandoned plugin that breaks on PHP 8.2 or 8.3. The site owner says, don't touch it, it works. The host is then balancing two bad options: keep a backported patch in place for the old version, or push for an upgrade that might break something.

Ryan Haylett

My view is that's a budget conversation, not a technical one. Set aside developer time to modernize those dependencies now. Backports are a bridge, and bridges end. Once your PHP branch is past support with no patches, you're exposed the next time something like this lands. And with attackers moving faster, that next time may come sooner.

Dave Rowley

So the short version: if you're with a host that's handling the server, check in, check your PHP version, and plan the upgrade you've been putting off.

Ryan Haylett

And if you're self managed, treat it as an emergency. Inventory every PHP install, update to the fixed release for your branch, restart the workers, and take anything you can't patch off the open internet.

Dave Rowley

And if any of this feels like too much to handle alone, that's exactly what we do at Modularity Networks. Whether you need your PHP version checked, your hosting secured, or an old site modernized, you can get help with all of it at Modularity.us.