PHP2Shell Explained: Critical PHP Vulnerabilities and How to Protect Your Website

On 21 October 2026 the PHP project shipped an emergency security release and said something it almost never says: "There are no complete mitigations, updating is the only safe choice."

The two flaws behind that release now have a name, PHP2Shell. Within a day government portals in Europe were switched off as a precaution, and owners of ordinary WordPress sites started asking the same question: am I affected, and what do I do?

This guide answers that in plain language. Every fact below comes from the official PHP security advisory or from the security researchers and reporters linked next to it.

In short: PHP2Shell is two critical bugs in PHP itself, not in WordPress or a plugin. If your site runs on PHP, it is exposed until the PHP on your server is updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a vendor's patched build). Updating WordPress does not fix it. Ask your host which PHP version you are on today.

What Is PHP2Shell?

PHP2Shell is the name given to two vulnerabilities in the PHP language runtime:

• CVE-2026-109618: remote code execution through out-of-memory corruption. When PHP runs out of memory at the wrong moment, it can be interrupted while request data is only partly set up, and cleanup may then treat that broken data as valid (Help Net Security).
• CVE-2026-109619: remote code execution through stale global state. Internal data owned by one request can outlive its memory, and a later request on the same PHP worker may use it before it is reset (same source).

"Remote code execution" is the worst class of bug there is: an attacker on the internet can make your server run their code. Here it needs no login and no user interaction. The PHP advisory says that for Apache with mod_php there is "a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."

That last part matters. It means a good security plugin, a strong password or a well-written theme does not stand in the way, because the attack lands before WordPress (or any other PHP application) even starts.

How Serious Is It? The CVSS Score

PHP's developers rated both flaws 9.2 out of 10 (Critical) under CVSS v4.0. The research firm watchTowr scored it 10.0 (Wikipedia summary of the reporting). Under the older CVSS 3.x scale, CVE-2026-109618 scores 9.8.

The timeline made it worse:

• The flaws were found in August 2026 as part of coordinated research.
• Details leaked on 20 October, before patches were out.
• Amazon Threat Intelligence reported an exploitation attempt against its honeypots on 17 October, four days before the public release (Help Net Security).
• The patches were published on 21 October 2026.
• watchTowr reports exploitation "observed in the wild since October 21, 2026" through its honeypot network (watchTowr FAQ). CISA had not added either CVE to its Known Exploited Vulnerabilities list as of 22 October.

How Many Websites Are Affected?

This is the question most people are searching for, so here are the numbers that actually exist, with their sources:

Two things follow from that table.

First, the "70% of websites at risk" headlines are about exposure: roughly seven in ten websites with a known server language run PHP, and every PHP version from 5.4 to 8.5 is affected until it is patched.

Second, 35.8% of WordPress sites run PHP 8.1 or older, branches the PHP project no longer supports. Those sites get no official update at all, only minimal source-code backports or a vendor's own build. For many of them the real fix is moving to a supported PHP version.

Even a site on PHP 8.3 "stays exposed until its host has installed 8.3.36", as Digidop puts it. Being on a modern branch is not enough; it has to be the patched release.

Which technologies are affected?

The bug is in PHP, so it reaches everything built on PHP. The PHP advisory names "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed", with the highest risk on mod_php.

Reporting names WordPress, Drupal and Joomla among the content management systems in scope, and notes that PHP is bundled with control panels such as cPanel and Plesk and with some vendor appliances. Palo Alto Networks said all PAN-OS and Panorama versions are affected; Fortinet and Cisco were still checking their products at the time of writing (Help Net Security).

Sites that do not run PHP on their own server, such as hosted Shopify stores or sites built on Next.js, are not running the vulnerable code. If you are unsure what your site runs on, ask your developer or host.

Which Websites Went Offline?

There is no published percentage of websites that went offline because of PHP2Shell, and we will not guess one. What is documented is a list of high-profile shutdowns, most of them precautionary, after official advice:

• The US NSA recommended taking websites offline if they could not be updated immediately, and the UK NCSC issued a similar warning.
• Following CERT-EU and NCSC advice, European organizations switched sites off, including the Dutch government portal Overheid.nl, the Danish national school platform, all Finnish government public-facing web services and all French Interior Ministry websites.
• Some Canadian government websites were temporarily taken down on the Canadian Centre for Cyber Security's guidance.
• The Wikimedia Foundation shut down a number of supporting systems, and the Internet Archive briefly went offline.
• In Japan, several online services and games went into emergency maintenance.

These are compiled, with citations to Reuters, the BBC and others, in the PHP2Shell Wikipedia article. The pattern is the lesson: organizations that could not confirm they were patched chose a few hours offline over the risk of a server takeover.

Is My WordPress Site Affected?

Probably, until proven otherwise. WordPress itself has said that "no WordPress update is required or planned", because the flaw is in the PHP interpreter, not in WordPress (Digidop). So the WordPress "Update" button will not help here. What matters is the PHP version on your server.

To check it:

1. 1In WordPress, go to Tools → Site Health → Info → Server and read the PHP version.
2. 2Or look in your hosting control panel (cPanel, Plesk, hPanel and similar all show it).
3. 3Compare it with the fixed releases: 8.5.12, 8.4.27, 8.3.36, 8.2.35 or newer in the same branch.

If your version is lower in the same branch, or it is 8.1, 8.0, 7.4 or older, you are exposed until your host acts.

One piece of good news: Automattic said sites on WordPress.com, WordPress VIP, WP Cloud and Pressable were "already protected against PHP2Shell." If you are on another host, ask them directly.

How to Protect Your Website: What to Do Now

1. Ask your host, in writing

Most small business sites are on shared or managed hosting, where only the host can update PHP. Send a short message:

Which exact PHP version is my site running, and has the 21 October 2026 security fix for CVE-2026-109618 and CVE-2026-109619 been applied? If not, when will it be?

Keep the reply. If the answer is vague, treat the site as unpatched.

2. Update PHP and restart every worker

If you manage your own server, update to the fixed release for your branch, or install your Linux distribution's patched package. watchTowr's FAQ adds a step people miss: restart every PHP worker afterwards, or the old code keeps running.

3. Move off PHP 8.1 and older

PHP 8.1 and earlier no longer get official fixes. The PHP project says to contact your distribution or LTS vendor for backported fixes, "or upgrade to a supported version." Plan a move to PHP 8.3 or 8.4 and test it on a copy (staging) of the site first, because an old theme or plugin can break on a newer PHP. Note that PHP 8.2 itself reaches end of life on 31 December 2026.

4. If you cannot update today, reduce exposure

For server owners who need hours, not minutes, the PHP advisory lists temporary settings that "reduce exposure to specific attack paths but do not make an installation safe." They include setting memory_limit = -1 with a lower post_max_size in the FPM pool or Apache config, and turning off session.upload_progress.enabled, then restarting every worker. The advisory warns not to rely on ini_set() or .user.ini for this. Read the full advisory before changing anything.

If a public site cannot be patched or protected, the UK NCSC's advice is to take it offline until it can.

5. Put a web application firewall in front

Cloudflare has deployed WAF rules for the known exploit paths, available to all customers, including the free plan (Help Net Security). That is a useful extra layer, not a replacement for the update.

6. Do not install a "PHP2Shell fix" plugin

Avoid unofficial "PHP2Shell fix" plugins and code snippets from forums. A plugin cannot change the PHP on your server, and such downloads may contain malware. The only fix is a patched PHP build.

7. Check for signs of compromise

Attacks were seen from 17 October onwards. Look for admin users you did not create, files that changed when nobody was working on the site, and unusual traffic since that date. If you find any, treat the server as compromised: restore from a clean backup, and change every password and API key. Our guide on common WordPress errors and how to fix them covers the safe order for working on a broken site.

A Quick Checklist for PHP and WordPress Site Owners

• Found the PHP version in Site Health or the hosting panel
• Asked the host in writing whether the 21 October fix is applied
• On 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a vendor-patched build
• Planned a move off PHP 8.1 or older, tested on staging
• PHP workers restarted after the update (own servers)
• Cloudflare or another WAF in front of the site
• Checked users, files and logs for anything unusual since 17 October
• A recent, clean backup stored off the server

The Bigger Lesson

PHP2Shell is a reminder that a website is more than its theme and plugins. Underneath every WordPress site sits a server, a PHP version and a host's update policy, and most owners never look at them until something like this happens.

The owners who can act fastest in a week like this are the ones who already know their PHP version, keep a staging copy, and have a host or developer who answers the same day. If you want that handled for you, our WordPress maintenance service covers updates, backups and security checks, and you can get in touch if you are not sure whether your site is patched.

Frequently Asked Questions

What is PHP2Shell?

PHP2Shell is the name for two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, patched on 21 October 2026. They allow remote code execution without logging in, on servers that run PHP to serve web pages.

Which PHP versions are affected by PHP2Shell?

Versions from PHP 5.4 to 8.5 are affected unless patched. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1, 8.0 and 7.4 have no official release, only source backports and vendor builds, and older versions have no fix.

Does updating WordPress fix PHP2Shell?

No. WordPress has said no WordPress update is required or planned, because the flaw is in PHP itself. The PHP version on your server must be updated, usually by your host.

How many websites are affected by the PHP vulnerability?

W3Techs data from 22 October 2026 puts PHP on 69.3% of websites whose server language is known, and WordPress on 39.6% of all websites. Every one of them is exposed until its PHP is patched. About 35.8% of WordPress sites run PHP 8.1 or older, which has no official fix.

Why did websites go offline because of PHP2Shell?

Security agencies, including the US NSA and the UK NCSC, advised taking sites offline if they could not be updated immediately. Government portals in the Netherlands, Finland, France and Canada, and services such as Wikimedia and the Internet Archive, shut systems down as a precaution. No overall percentage of offline sites has been published.

How do I check my PHP version in WordPress?

Go to Tools → Site Health → Info → Server in your WordPress dashboard, or open your hosting control panel. Compare the version with the fixed releases listed above.

Is there a workaround if I cannot update PHP right away?

The PHP advisory lists temporary settings that reduce exposure but "do not make an installation safe", and a WAF such as Cloudflare's adds another layer. The only complete fix is updating PHP. If neither is possible, take the site offline until it is patched.