PHP just got two critical RCE bugs. Here's why your website shouldn't care.

How a static, composable website sidesteps vulnerabilities like PHP2Shell, and why WordPress can't.

By Max Ikaheimo

October 21st, 2026

On 20 October, the PHP security team announced a security release fixing two critical vulnerabilities, both rated CVSS v4.0 9.2, scheduled for 21 October at 14:00 UTC. The details leaked before the fix was ready, and the whole thing is now being called PHP2Shell.

• The flaws, CVE-2026-109618 and CVE-2026-109619, are remote code execution issues in PHP core, not in some obscure plugin.

• Hosting partners have reported active exploitation, and the only confirmed mitigation is updating PHP.

• A static website served from a CDN doesn't run PHP, so there's nothing to exploit.

Short answer: If your site runs on WordPress, you're exposed until your host patches PHP. If your site is pre-built HTML on a CDN with a headless CMS behind it, this bug doesn't apply to you, and neither will the next one.

• In this post:

What actually happened

The flaws are in the PHP interpreter, not in any one application. That's what makes this one different from the usual "vulnerable plugin of the month" story. WordPress, Drupal, Magento, Joomla, Laravel and every other PHP application is exposed if it runs a vulnerable PHP version. You can have every plugin updated, a hardened theme and a firewall in front, and still be vulnerable, because the hole is underneath all of it.

Sansec says the bugs affect all web servers running PHP 5.4 or later. There's also a catch for anyone on an old setup: end-of-life PHP branches may not get patches at all. Check php.net for the affected and fixed versions, which PHP publishes together with the release.

Why WordPress sites are stuck waiting

When a bug like this lands, a WordPress site owner can't do much. You wait for your host to roll out the new PHP version, or you do it yourself on your own server and hope nothing in your plugin stack breaks on the upgrade. Meanwhile attackers move fast, and mass attacks were expected within minutes of the patch going public.

I've covered this before in Next.js vs WordPress and static sites vs WordPress: WordPress is a 20+ year old codebase, and all that dynamic, server-side machinery is a big attack surface for a site that mostly shows content. Every request runs PHP, hits a database, and passes through a pile of third-party code. Any of those layers can be the entry point. It's also a big part of why website maintenance turns into a permanent job on WordPress sites.

Why a static site doesn't care

A modern setup with Astro or Next.js and a headless CMS works differently. The pages are built ahead of time and served as plain files from a CDN. When someone opens your site, no PHP runs, no database gets queried and no admin panel is sitting on the public internet.

You can't exploit an interpreter that isn't there. PHP2Shell is a non-event for these sites, and so is the next PHP vulnerability.

Some other things that come with this setup:

• The CMS isn't your problem to patch. With a hosted headless CMS like DatoCMS or Sanity, the vendor's security team handles the infrastructure. Your editors log in there, not on your public site. I wrote about the trade-offs in self-hosting vs cloud-hosting your CMS.

• Fewer moving parts. Plugins don't run on your live site. Dependencies run at build time, on a machine you control, and you can pin and audit them.

• Patching is calm. If a dependency in your build has a vulnerability, you bump it, rebuild and redeploy. Nothing live is exposed in the meantime.

If you're still picking a CMS, here's my take on the best headless CMS options.

It's not magic

I'm not going to pretend modern web development is immune to everything. If you use Next.js with server-side rendering, you're running a Node runtime, and Node frameworks have their own serious vulnerabilities. Forms, search and login need to live somewhere, usually in serverless functions or third-party services.

The difference is scale. You're defending a few small, isolated functions instead of a full PHP application with a plugin ecosystem bolted on. Keep the dynamic parts small and you keep the risk small. If you're weighing your options, best ways to build a website walks through them.

So, should you leave WordPress?

If your WordPress site is a marketing site with a blog, a few landing pages and a contact form, you're running a dynamic application for content that changes a couple of times a week. That's a bad trade, and every PHP advisory makes it a little worse. The Automattic vs WP Engine drama didn't exactly help the case for staying either.

If your site is already compromised or you're on an unpatched PHP version, patch first and think about migrating second. If you want to talk about what moving off WordPress actually looks like, get in touch.