PHP2Shell: What WordPress Owners Must Do Now

On 21 October 2026, the PHP project shipped an emergency fix for two critical flaws in PHP itself. Security researchers call them PHP2Shell. Together they let an attacker run their own code on a web server without logging in, and attacks started hours before the fix was out. PHP runs most of the web, and it runs every WordPress site.

If you own or manage a WordPress site, the most important fact is the one most people get wrong: updating WordPress does nothing here. The flaw is in the PHP layer underneath WordPress, its plugins and its theme. Your site is safe only once the server it runs on uses a patched version of PHP. Below is what happened, how to check your site in five minutes, and an honest view on whether this is a reason to leave WordPress.

Everything here reflects what is known as of 23 October 2026. The situation is still moving, so follow the official PHP advisory for changes.

What PHP2Shell is

PHP2Shell is the nickname for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The PHP security team rates both critical, at 9.2 out of 10.

• CVE-2026-109618 is triggered when PHP runs out of memory partway through setting up a request. The cleanup step can then treat half-built data as valid.
• CVE-2026-109619 lets internal data from one request survive after its memory is freed, so the next request handled by the same server process can use that stale data.

In plain terms, a carefully crafted request can corrupt PHP’s memory and take control of the server. No password, no plugin and no admin access is needed. Patchstack reports that researchers at Wiz showed even a one-line “Hello World” PHP page can be exploited, and that every PHP version back to 5.4 is affected by at least one of the two flaws. Every common way of running PHP is in scope: PHP-FPM, Apache mod_php, CGI, LiteSpeed and FrankenPHP.

Why this one is worse than usual

Three things make PHP2Shell different from the plugin vulnerabilities WordPress owners are used to.

It sits below WordPress. Security plugins, firewalls inside WordPress and maintenance mode cannot stop it, because the attack lands before WordPress loads. WordPress.org has confirmed that “no WordPress update is required or planned”. The fix has to come from whoever runs your server.

Attackers had a head start. PHP announced the release on 20 October for 14:00 UTC the next day. Details leaked first. Cloudflare reported early attacks at 07:43 UTC on 21 October, around six hours before the patch shipped, and its CEO later reported hundreds of thousands of exploit attempts within two hours of the announcement and millions by the next day.

Old PHP gets no official fix. The PHP project only ships new releases for supported versions: 8.2, 8.3, 8.4 and 8.5. Anything older depends on your host, your Linux distribution or a paid support vendor backporting the fix.

That last point is where WordPress is exposed. According to WordPress.org’s own usage statistics, 34.7% of WordPress sites run PHP 8.1 or older, versions that receive no official release. Another 23.5% run PHP 8.2, which is patched today but reaches end of life on 31 December 2026. Put together, almost six in ten WordPress sites are on PHP that is unsupported now or will be within ten weeks.

Check your site in five minutes

You do not need to be technical to do this. You need to know your PHP version and who is responsible for updating it.

1. Find your PHP version. In your WordPress dashboard, go to Tools, then Site Health, then Info, and open the Server section. The PHP version is listed there.
2. Compare it with the fixed releases. You are patched if you run PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or anything newer.
3. Ask your host before you panic. Some hosts backport the fix without changing the version number, so a patched server can still show an older number. Email or chat with your host and ask one question: “Is the PHP on my server patched for CVE-2026-109618 and CVE-2026-109619?” Get the answer in writing.
4. If you are on PHP 8.1 or older, plan an upgrade now. Even if your host has backported this fix, your PHP version no longer gets fixes as a matter of course. Moving to PHP 8.3 or 8.4 can break old plugins and themes, so test on a staging copy first.
5. If you manage your own server and cannot patch today, PHP and Patchstack list temporary mitigations, such as setting session.upload_progress.enabled=0 and restarting PHP. WordPress does not use that feature, so turning it off should not affect a typical site. On 23 October, PHP recommended the same setting against a third, less likely attack path it will fix in its next regular release. These settings reduce the risk. They do not replace the update.

Two warnings. Do not install “PHP2Shell fix” plugins or paste code snippets from forums: a plugin cannot change the PHP your server runs, and fake fixes are a classic way to plant malware during a scare. And if you use UpdraftCentral to manage several sites, Patchstack separately reports stolen UpdraftCentral keys being used to backdoor WordPress sites, so delete and reissue those keys.

Signs your site was targeted

Patchstack lists a few signals worth checking in your server logs. None of them is proof either way.

• Unusual multipart requests followed by memory-limit errors or repeated 500 errors
• Unexpectedly large or malformed PHPSESSID cookies
• PHP worker processes restarting without explanation

If you see these, update PHP first, then treat the server as possibly compromised: change every password and API key stored on it, including database credentials, payment and email keys, and admin logins. If you are not sure what that involves, this is the moment to bring in someone who does.

The real lesson: who patches your stack?

PHP2Shell is not a WordPress bug. But it shows how a WordPress site is put together: WordPress on top of PHP, on top of a web server, on top of an operating system, plus every plugin and theme you install. Each layer needs patching, and each one has an owner. For a lot of businesses, nobody is clearly that owner. The site was built once, the agency moved on, and the hosting plan renews every year without anyone checking which PHP it runs.

That is why some sites were patched within hours this week and others are still exposed. The difference was rarely the software. It was whether anyone was responsible.

Platforms built differently carry less of this burden. On a hosted platform such as Webflow or Framer, there is no PHP on a server you rent, and the platform patches its own infrastructure for every customer at once. A static or edge-rendered site, the way we build with Astro, serves pre-built pages and runs no PHP at all, so a flaw like this has nothing to attack. No platform is free of risk. The point is how much of that risk you carry yourself, and whether you have time to manage it.

Should you leave WordPress over this?

Not automatically. If your host patched within a day, your PHP version is current and someone owns updates, PHP2Shell is a bad week, not a reason to rebuild.

It is worth considering a move if one of these sounds familiar:

• You are on PHP 8.1 or older and the upgrade would break plugins nobody maintains any more.
• Nobody owns the stack. You found out about PHP2Shell from the news, not from your host or developer.
• Your site is mostly marketing pages and a blog. You are paying the maintenance cost of a full application server for content that does not need one.
• You were already planning a redesign. A rebuild on a lower-maintenance platform costs about the same, and you stop inheriting the old stack’s risk.

Two ways to leave PHP behind, and we can move you to either

If you decide to move, there are two routes we recommend. Both remove PHP from your site completely, so a flaw like PHP2Shell has nothing to attack, and neither leaves you with a server to patch.

Option 1: Move to Webflow

Webflow is a hosted platform. There is no server you rent and no PHP you manage: Webflow runs the infrastructure, patches it for every customer at once, and serves your site from a global CDN with SSL and backups included. Your team edits pages and publishes blog posts in a visual editor, without a developer and without plugins to update.

• Best for: marketing sites, blogs and lead generation, and teams that want to change pages themselves.
• Keep in mind: you pay a monthly plan, and complex app features need integrations rather than plugins.

We are Webflow specialists. See Webflow development at Carril for how we build.

Option 2: Fully coded on Cloudflare

The second route is a custom-coded site, built with a modern framework such as Astro or Next.js and deployed on Cloudflare’s global network. Pages are built ahead of time and served from data centres close to every visitor, and the few dynamic parts, such as forms or search, run as small functions on Cloudflare’s own platform. There is no PHP, no web server and no operating system for you to patch. Cloudflare maintains the platform underneath.

• Best for: speed, custom features, several languages, high traffic, and owning your code outright with no platform lock-in.
• Keep in mind: content changes go through code or a connected CMS, so it suits teams with a developer or an agency on hand.

This is how our own website is built. When PHP2Shell broke, there was nothing on our site to patch. See web development at Carril for the custom route.

How we handle the move for you

Moving is where most migrations lose traffic, so we run the whole process as your Co-Driver:

1. Free consultation. We review your site, your PHP version, your plugins and your goals, and recommend Webflow or Cloudflare. If staying on WordPress with a patched PHP is the right call, we will say so.
2. A plan for every URL. Every page that changes address gets a 301 redirect, so you keep the rankings and traffic the old site earned. You can preview this yourself with our free migration planner: enter your site, choose Webflow, Astro or Next.js, and it lists every URL and builds the redirect file.
3. Design, build and content. We rebuild the site, move your pages, posts, images and SEO settings, and reconnect your forms, analytics and tracking.
4. A safe launch. We test every redirect, submit the new sitemap to Google and Bing, and watch 404 errors and rankings in the weeks after launch.

Founders get one team for the whole move, with no in-house developer needed. Marketing managers get a senior partner who works alongside their team and owns the timeline. Book a Free Consultation and we will tell you which route fits your site.

For more detail, read our WordPress to Webflow migration guide and our Webflow vs WordPress comparison.

PHP2Shell timeline

• 20 October 2026. PHP announces a critical security release for the next day at 14:00 UTC. Details of the flaws leak.
• 21 October, morning. Hosting partners report active exploitation to Patchstack, and Cloudflare sees early attacks at 07:43 UTC.
• 21 October, afternoon. PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with fixes for both CVEs. Hosts begin rolling out patches.
• 23 October. PHP publishes an informational advisory recommending session.upload_progress.enabled=0 until its next regular release.
• 31 December 2026. PHP 8.2 reaches end of life and stops receiving security fixes.

The short version

PHP2Shell is a flaw in PHP, not WordPress, so the fix is a patched PHP version on your server, not a WordPress update. Check your version today, get your host to confirm the patch in writing, and plan an upgrade if you are on PHP 8.1 or older. Then ask the bigger question: who owns your stack, and is that owner you?

If you would rather stop patching servers altogether, move to Webflow or to a fully coded site on Cloudflare, and we can handle the move for you, from the URL plan to launch. Book a Free Consultation. We will check where your site stands and tell you honestly whether it needs a fix or a fresh start. Your Co-Driver for the web.

Frequently asked questions

Does updating WordPress fix PHP2Shell? No. The flaw is in PHP, the language WordPress runs on. WordPress.org has said no WordPress update is planned for it. Only a patched PHP version on your server fixes it.

Which PHP versions are safe? PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 and newer. Older versions are safe only if your host or Linux distribution has backported the fix, so ask them to confirm.

Can a security plugin protect my site? No. The attack happens before WordPress and its plugins load. A firewall in front of the server, such as Cloudflare, can block some known attack patterns, but it is not a substitute for patching PHP.

Are Webflow and Framer sites affected? Your site does not run on PHP you manage on those platforms, so there is nothing for you to patch. Each platform is responsible for patching its own infrastructure.

Can Carril move my WordPress site to Webflow or Cloudflare? Yes. We plan every redirect, rebuild the site on Webflow or as a fully coded site on Cloudflare, move your content and SEO settings, and manage the launch. It starts with a free consultation.

My host says I am patched, but Site Health shows an old version. Who is right? Possibly both. Backported fixes often keep the old version number. Ask your host to confirm in writing that your server is patched for CVE-2026-109618 and CVE-2026-109619.