PHP2Shell: Old WordPress & Drupal Sites at Risk

PHP2Shell is the name for two critical flaws in PHP itself (CVE-2026-109618 and CVE-2026-109619), patched on October 21, 2026. They let an attacker run code on an unpatched server without logging in, and read passwords and API keys out of memory. Every WordPress, Drupal and Joomla site runs on PHP, so any of them on an unpatched PHP version was exposed until its host updated. If you can't say for sure your site's PHP was updated this week, find out today.

This one is different from the usual “update your plugins” warning. The hole wasn’t in a plugin, a theme, or WordPress. It was in PHP, the language underneath all of them. That means a site with every plugin updated and a strong password was still wide open, and no button in your WordPress dashboard could fix it.

We build websites for a living, so we want business owners to understand what actually happened, how to check whether they’re still exposed, and why this keeps pushing us toward a different way of building sites.

What happened, in plain English

Researchers at Wiz reported the bugs to the PHP security team in August. Details leaked publicly on October 20, a day before the fix was ready. On October 21 the PHP project released emergency updates: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Both flaws are rated 9.2 out of 10 for severity.

No login needed. An attacker could send specially built requests to a site and take control of the server.
It worked on stock installs. Wiz showed working attacks against the latest WordPress, Drupal and Joomla, and warned that even a bare “Hello World” PHP page on an unpatched version can be vulnerable.
It could leak secrets. Separately, attackers could read chunks of server memory, which can hold passwords, login tokens and API keys (the secret codes that connect your site to other services).
It goes back a long way. Wiz says every PHP version back to 5.4 is affected by at least one of the two flaws.

Was anyone actually attacked?

Yes. Hosting partners reported active exploitation to the security firm Patchstack on the morning of October 21, before the patch was even out. Codeable reported that Cloudflare’s CEO counted thousands of exploit attempts before the announcement and millions by the next day. Reports so far describe attack attempts and probing; confirmed break-ins had not been publicly verified as of this writing. Government services in the Netherlands and several major Japanese platforms went offline on purpose until they could patch.

That’s the part business owners should sit with. Large, well-staffed organizations chose to shut their sites off rather than run them unpatched for a few hours.

Is my WordPress or Drupal site affected?

If it runs on PHP and its PHP wasn’t updated after October 21, yes. Here’s how to check:

Find your PHP version. In WordPress, go to Tools, then Site Health, then the Info tab, and open the Server section. Most hosting control panels show it too.
Ask your host one direct question: “Has the October 21, 2026 PHP security release (CVE-2026-109618 and CVE-2026-109619) been applied to my server?” Some hosts patch without changing the version number you see, so the answer from support matters more than the number.
If you’re on PHP 8.1 or older, the PHP project no longer ships official releases for it. Some hosts and Linux vendors backported this fix (copied it onto older versions), but many older setups got nothing. Plan the move to a supported version now.
If you run your own server (a rented private server, a cloud box, a server someone set up years ago), nobody is patching it for you. If it’s on PHP older than 8.2 and can’t be updated right away, WordPress.org and the UK’s National Cyber Security Centre both say to consider taking it offline until it can be.
If you see possible signs of trouble, like repeated server errors or unexplained PHP restarts around October 20 to 22 (signs security researchers flagged), treat the server as possibly compromised and change the passwords and API keys it holds.

A firewall like Cloudflare’s helps as a layer. It isn’t the fix. The only complete fix is the PHP update.

This wasn’t a one-off

PHP2Shell landed at the end of a rough stretch. In July, a pair of flaws in WordPress core, nicknamed wp2shell, allowed takeover of stock WordPress installs and were exploited across the internet. In early October, a critical flaw in the Bricksforge plugin was exploited in the wild. And security firms log new WordPress plugin and theme vulnerabilities every single week.

None of that means WordPress is bad software. It means a WordPress or Drupal site is a running application that needs a server, PHP, a database, a theme and a stack of plugins, and every one of those layers has to be kept current by someone, forever. When nobody owns that job, the site quietly gets more dangerous every month.

The real risk: the site nobody is maintaining

A WordPress site on a good managed host was usually protected quickly. Many big hosts, including Pantheon, Pressable and OVHcloud, confirmed they patched within a day or so. The sites we worry about are the other kind:

Built five or more years ago by someone who isn’t around anymore
On cheap shared hosting or a server nobody has logged into in years
Still on PHP 7 or 8.0 because upgrading “broke something” once
Full of plugins that haven’t been updated by their developers in years
Collecting form submissions, logins or customer data

If that sounds like your site, PHP2Shell is your warning shot. The next flaw may not come with a leak a day early and a patch the next morning.

How we build sites now, and why

Many of the sites Dye Media builds today, including this one, are static sites hosted on Netlify. A static site is a set of finished pages that get handed to visitors as files. There’s no PHP interpreter running on each page request and no WordPress database sitting behind the page, so a flaw like PHP2Shell has nothing on the site to attack.

Static isn’t magic. Forms, third-party scripts, your domain and your hosting login still need real security. But removing an entire server-side application from the picture removes most of the weekly patching that old CMS sites demand. Static sites also tend to load fast, which helps both visitors and search rankings.

We still build on WordPress when a business genuinely needs it. What we won’t do is pretend that an unmaintained PHP site is a set-it-and-forget-it asset. It isn’t.

What to do this week

Confirm with your host, in writing, that the October 21 PHP fix is on your server.
Find out which PHP version you’re on and whether it still gets security updates. PHP 8.2 stops getting security fixes on December 31, 2026, so 8.4 or 8.5 is the safer target.
List who is responsible for updates on your site. If the answer is “nobody,” that’s the real problem to solve.
If your site is old, slow and unmaintained anyway, price out a rebuild before you pay to patch it again.

Frequently asked questions

Is PHP2Shell a WordPress vulnerability?

No. It’s a pair of flaws in PHP, the language WordPress runs on. WordPress.org confirmed no WordPress update is needed or planned. The fix is a PHP update on the server.

Does updating my plugins protect me?

Not from this. Plugin updates are still important, but this flaw sits below WordPress, so only the PHP update closes it.

Does it affect Drupal and Joomla too?

Yes. Any site running an unpatched PHP version is exposed, and researchers demonstrated working attacks on the latest Drupal and Joomla as well as WordPress.

Are static websites affected?

A purely static site doesn’t run PHP when someone visits a page, so this flaw has nothing on the site to exploit. Any separate PHP app you run on another server would still need patching.

PHP2Shell: Why Old WordPress and Drupal Sites Are at Risk