Is the internet over? PHP2Shell and the 10 worst vulnerabilities in internet history

On Tuesday, October 21, 2026, the Dutch government took its main portal offline. So did France's Interior Ministry, Belgium's foreign ministry and state IT providers in Finland, Germany and Denmark. The Netherlands' national cyber security centre pulled its own website. The Wikimedia Foundation took a number of PHP systems down as a precaution. The US NSA told organizations that could not update right away to unplug.

Nobody had been hacked. Everyone was scared of the same thing: PHP2Shell, two bugs in the core of PHP, the programming language behind about 69% of all websites whose server language is known.

So, is the internet over? No. But this is the closest it has come in years.

What is PHP2Shell?

PHP2Shell is the nickname for two vulnerabilities in PHP itself, not in a plugin or a framework.

CVE-2026-109618 is a memory corruption bug in how PHP handles running out of memory while it is still reading a request. CVE-2026-109619 is a use-after-free bug: leftover state from one request can be picked up by the next request served by the same worker.

Both let an attacker run their own code on a web server without logging in and without anyone clicking anything. The code runs with the rights of the web server process.

Here is the part that makes PHP2Shell different from the usual "update your WordPress plugin" story. The bug sits in the layer that parses incoming requests, which runs before the application code. WordPress, Drupal, Laravel, Symfony or a custom app with perfect code are all exposed in the same way. The application never gets a chance to say no.

Every common way of serving PHP is affected: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. Researchers rate mod_php as the riskiest setup.

Is PHP2Shell critical? Yes

The PHP security team scored both bugs 9.2 out of 10 (Critical) under CVSS v4. watchTowr, one of the first teams to reproduce them, scored them a perfect 10. The honest answer to "how bad is it" has two sides.

What makes it worse

• It affects PHP 5.4 (released in 2012) through 8.5.11. That is 14 years of releases.
• No credentials, no user interaction.
• Attack attempts started four days before the patch existed.
• About half of all PHP websites run a version that will never get an official fixed build.

What keeps it from being a 10 everywhere

• Exploiting it is not trivial. The CVSS vector marks attack complexity as high. Rapid7 found that each public proof of concept works only for one specific mix of operating system, PHP version and web server, and none is reliable across the board.
• As of October 21, CISA said it had not observed exploitation, and no source had confirmed a specific server being broken into.

That second list is not a reason to relax. Rapid7 put it plainly: a more portable technique could appear at any time. With Log4Shell and React2Shell, the gap between "hard to exploit" and "mass exploitation" was measured in hours.

How big is PHP2Shell, really?

69.3% of websites with a known server-side language run PHP (W3Techs, October 22, 2026). That includes WordPress, Drupal, Joomla and Magento.

1.3 million+ internet-exposed hosts are potentially vulnerable, by one researcher's estimate. A separate Shodan search counted 1.9 million+ exposed hosts running PHP.

About 48% of PHP websites run a version with no official fixed build. By W3Techs' version data, 34.7% of PHP sites are still on PHP 7, 5 or 4, and another 13.7% are on PHP 8.0 or 8.1. PHP ships fixed builds only for 8.2 to 8.5. PHP 7.4, 8.0 and 8.1 got source-code patches but no official builds, and anything older gets nothing. Some Linux distributions backport fixes while keeping the old version number, so the real exposed share is lower. It is still large.

Then there is hidden PHP. It ships inside control panels like cPanel and Plesk, inside network and storage appliances, and inside internal tools nobody remembers deploying. CISA's first instruction was to inventory every system running any PHP version, because many teams do not know where PHP is running.

The 10 biggest vulnerabilities in internet history

These are the bugs behind some of the biggest cyber attacks in history. Ranking them is subjective. We ranked them on three things: how much of the internet was exposed, how easy they were to exploit at scale, and the real damage that followed.

1. 1

   Log4Shell 2021

   Log4j, the logging library inside a huge share of Java software

   CVSS 10, trivial to exploit, buried deep in dependencies. Two years later, 38% of apps still used vulnerable Log4j versions, and it was still among CISA's most exploited vulnerabilities in 2023.

2. 2

   EternalBlue, WannaCry and NotPetya 2017

   Windows file sharing (SMBv1)

   A leaked NSA exploit turned into worms. WannaCry hit 200,000+ computers in 150 countries. NotPetya caused an estimated $10 billion in damage.

3. 3

   Heartbleed 2014

   OpenSSL, the encryption under most HTTPS

   About 17% of trusted HTTPS servers, roughly half a million, leaked memory, including private keys. A month later, 318,000 were still vulnerable.

4. 4

   Apache Struts and the Equifax breach 2017

   A Java web framework

   A patch was available, but Equifax did not apply it in time. About 147 million people's personal data was stolen.

5. 5

   Shellshock 2014

   Bash, the Unix shell

   A decades-old bug in a tool on almost every Linux and Mac machine, reachable through web servers. Mass scanning started within a day.

6. 6

   MOVEit Transfer 2023

   File transfer software

   One ransomware group used one bug to steal data from about 2,700 organizations and roughly 95 million people.

7. 7

   ProxyLogon 2021

   Microsoft Exchange email servers

   Tens of thousands of organizations were broken into within weeks, by several groups at once.

8. 8

   Citrix Bleed 2023

   Citrix NetScaler gateways

   Session hijacking that walked attackers past MFA and fuelled ransomware at major companies. By one count, over half of affected devices were still unremediated three months later.

9. 9

   React2Shell 2025

   React Server Components and frameworks like Next.js

   CVSS 10. Exploited within hours of disclosure, with 1.4 million exploitation attempts in its first week.

10. 10

    The xz Utils backdoor 2024

    A compression library inside Linux SSH

    A patient, multi-year supply chain plot that nearly put a backdoor into most Linux servers. One engineer caught it by accident, just before it reached mainstream releases.

How long will it take to patch PHP2Shell? Our prediction

History is a good guide here, because big vulnerabilities follow the same curve: a fast first drop, then a long plateau that lasts for years.

• Heartbleed: about half of vulnerable servers were patched in the first month. In month two, progress improved by less than 3%.
• Citrix Bleed: one study saw 85% of exposed servers fixed within a month. Another found 54% of affected devices still unremediated after three months.
• Log4Shell: ten months in, 72% of organizations still had at least one vulnerable asset. Three years in, 13% of active Log4j installations were still vulnerable.
• EternalBlue: two years after WannaCry, about 1 million machines were still exposing SMBv1 to the internet.

PHP2Shell has things that speed it up: managed hosting and big platforms patch for their customers, and firewall vendors shipped virtual patches within hours. It also has things that slow it down: half the install base on versions with no fixed build, PHP hidden inside appliances, and a fix that only works after every worker process is restarted. Here is our forecast for internet-facing PHP.

• First 72 hoursThe big names are patched

  Large platforms, managed hosting and cloud runtimes are patched or shielded. Most high-profile sites that went offline come back. Exploit attempts climb as proof-of-concept code improves.

• 30 daysAbout half of supported servers are fixed

  Roughly half of exposed hosts on PHP 8.2 to 8.5 are patched. Hosts on PHP 7 and 8.0/8.1 barely move, because a major version upgrade can break the application.

• 6 monthsThe plateau

  We expect 25–35% of exposed PHP hosts to still be vulnerable: old versions, small business sites, appliances and forgotten servers.

• 2 years and beyondThe tail that never ends

  PHP2Shell joins Log4Shell and EternalBlue on the "still exploited" lists. Many servers will never be patched, only replaced.

This is our estimate, based on the patching curves above and W3Techs' version data. We will revisit it as scan data comes in. The uncomfortable conclusion: for most of the internet, "patch it" is not a plan that finishes this year.

The best protection is adaptive, not static

Look again at the timeline. The first attack attempt came four days before the CVE was public. During those four days, vulnerability scanners had no CVE to look for, signature-based tools had no signature, and patch management had no patch. For that stretch PHP2Shell was, in practice, a zero-day.

Amazon's own advice after PHP2Shell says it directly: build detections that do not depend on CVE-specific signatures, because first exploitation often comes before them. CISA points the same way. Besides patching, it tells teams to watch for PHP worker processes launching shells or downloading tools.

That is a behavior, not a signature. A web server that has served pages for two years and suddenly starts a shell, writes a new file into a system folder or opens a connection to an unknown address is doing something it has never done before. You do not need the CVE number to see that. You need to know what normal looks like for that specific server.

Static defenses ask "does this match something we already know is bad?" Adaptive protection asks "is this server behaving the way it always does?" When attackers move days ahead of the patch, and AI is helping both sides find bugs faster, only the second question works on day zero.

What to do about PHP2Shell today

• 1. Find every PHP and check its version.

  Not just the websites you know about. Check servers, containers, base images, control panels and appliances. On a server, php -v shows the version. Anything from 5.4 up to the fixed releases is in scope, and your Linux distribution's security notice tells you which package build carries the fix.

• 2. Patch internet-facing systems first.

  Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's fixed package.

• 3. Restart every PHP worker.

  Running processes keep the old code in memory. An updated package without a restart is not a fix.

• 4. On PHP 8.1 or older, plan the upgrade now.

  There is no official fixed build. If a server cannot be upgraded quickly, follow CISA's and the NSA's advice and take it offline until it can.

• 5. Treat temporary mitigations as a bridge.

  PHP published configuration changes and firewall vendors shipped rules, but PHP's maintainers say none of them is complete. Updating is the only safe choice.

• 6. Look back to October 17, not October 21.

  Review web server and host activity from the first known attempt, and watch for PHP processes doing things they never do: starting shells, downloading tools, writing new files.

How to check your PHP version

On the server, run php -v. If you see any version below 8.5.12, 8.4.27, 8.3.36 or 8.2.35, the server needs the update.

The command line and the web server can use different PHP builds, so also check the PHP package your web server loads (Apache mod_php or PHP-FPM). Hosting control panels show the site's PHP version on the PHP settings page.

Some Linux distributions backport the fix without changing the version number. On those, compare your installed package build with your distribution's security notice instead of the version alone.