PHP Security Vulnerability PHP2Shell: Why Hundreds of Websites Went Offline

On October 21, 2026, website administrators across Germany, the Netherlands, Finland, and Canada made the same call: pull the site offline. Not because they had been attacked, but to prevent it. Two critical security vulnerabilities in the PHP programming language (now known collectively as PHP2Shell) had leaked to the public roughly 20 hours ahead of schedule. What followed was one of the most disruptive emergency patching events since Log4Shell.

This article explains what happened, which sites went dark, and why, if you run a WordPress site on shared or VPS hosting, a WordPress update would not have protected you.

What Is PHP2Shell? Two Critical PHP Security Vulnerabilities Explained

PHP2Shell is the collective name for two critical remote code execution (RCE) vulnerabilities in the PHP core engine: CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS 4.0 score of 9.2, placing them firmly in the critical tier.

Here is what each one does:

• CVE-2026-109618 (Upload-progress unserializer use-after-free): A fatal memory allocation failure can interrupt PHP while internal request data is only partially initialized, leaving corrupted global state exposed to the next request on the same worker. An attacker who triggers this condition can manipulate that stale memory to execute arbitrary code.
• CVE-2026-109619 (Fatal-error backtrace use-after-free): PHP retains the backtrace from the most recent fatal error across request boundaries. That retained backtrace can be exploited to inject and execute malicious code before it is reset.

In practical terms: a single crafted HTTP request to any vulnerable PHP server is enough to give an attacker full code execution on that server. No login required. No prior access needed.

The vulnerabilities affect every PHP installation that processes web requests: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. Every CMS or application running on top of PHP is also at risk, including WordPress, Drupal, Joomla, Magento, and MediaWiki. Affected versions reach back to PHP 5. Wiz Research, which discovered both flaws with the help of AI models from OpenAI and Google DeepMind, estimates that PHP powers approximately 70% of all websites on the internet.

Emergency patches were released on October 21, 2026 at 16:00 MESZ: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and all older branches will not receive a fix.

Which Websites Went Offline, and Why

The coordinated disclosure process broke down on October 20, 2026, when technical details leaked on Hacker News approximately 20 hours before the scheduled patch release. That window handed attackers a significant head start and left administrators with a narrow, stressful choice: patch immediately or take the site offline.

Many chose to go dark.

In Germany, the city of Düsseldorf took its official website offline, followed by Heinrich Heine University Düsseldorf and Uniklinik Düsseldorf. The cities of Mainz and Bochum (Ruhr-Universität) took similar action, as did Charité Berlin. Across Europe, Finnish and Dutch government portals went offline. Canadian federal agencies took precautionary measures.

Perhaps the most striking single event: the Dutch National Cyber Security Centre (the organization coordinating the national response) took its own website offline as a precaution. CERT-EU's official guidance was unambiguous: organizations that cannot apply the patch immediately should take their public-facing sites offline. Some hosting providers went further, disabling file uploads across entire shared hosting environments.

By October 22, Cloudflare had already reported active exploitation attempts in the wild. CERT-EU confirmed that working proof-of-concept exploits were circulating publicly. Germany's BSI classified the risk as critical, warning that widespread exploitation within hours was "likely" (BSI advisory 2026-297981-1032).

Why a WordPress Update Won't Protect You

This is the part that matters most for business website owners, and it is worth stating plainly: a WordPress update would not have prevented PHP2Shell exposure.

PHP2Shell is a flaw in the PHP runtime: the server-side engine that executes PHP code. WordPress, Drupal, Joomla, and every other PHP-based CMS run on top of that engine. When the engine itself has a critical flaw, every application running on it is at risk regardless of how up-to-date the application is. You could have had the latest WordPress version, all plugins current, every security plugin active, and still been exposed to a remote attacker executing code on your server.

The following reflects the opinion of Aleksey Rogalev, managing director of marketer UX GmbH.

The model of running self-hosted WordPress on your own PHP server asks too much of the website operator. When you run WordPress on shared or VPS hosting, you are simultaneously responsible for the PHP version on the server, WordPress core, every plugin, every theme, and your hosting provider's response time to critical vulnerability disclosures. PHP2Shell exposed the fourth layer in that chain: the one most operators assume their host is handling automatically. The BSI advisory published at 08:30 on October 21. The patch was available at 16:00. Between those hours, every unpatched PHP server was a target. For any organization without dedicated IT security staff, that window is too short to close reliably. At the scale of an enterprise website, maintaining a self-managed PHP stack is an unnecessary operational risk.

Managed Platforms Had a Different Day

Websites built on managed SaaS platforms like Webflow for businesses, or on static and headless architectures (Next.js deployed via Vercel or Netlify, for example), did not have a PHP runtime to patch. There was no PHP server to take offline, no patching window to race against, and no BSI advisory demanding immediate action from the site operator.

That is not the same as saying these platforms are unhackable. Every technology has attack surfaces, and no vendor will eliminate all risk. But the attack surface is measurably smaller when the infrastructure layer is managed by the platform vendor, not the website owner. On a managed platform, PHP2Shell was the vendor's problem to solve, not yours.

This distinction becomes concrete when you look at what one mid-sized company experienced after migrating away from WordPress. ACO, a manufacturing firm, described leaving what their own team called the "update hell" of self-managed WordPress before an incident of this scale could affect them. The full story of that migration is documented in the ACO case study: from WordPress to Webflow.

For a detailed side-by-side comparison of how WordPress and Webflow differ on security model, hosting responsibility, and long-term maintenance costs, see Webflow vs. WordPress 2026: The Ultimate Comparison.

What to Do Right Now: A Checklist

If you are running a website on PHP, here is what to prioritize today (as of October 22, 2026):

1. Check which PHP version is actually running. Ask your hosting provider for the installed and active PHP version, not the version shown in your CMS admin panel. PHP 8.2, 8.3, 8.4, and 8.5 all have available patches. PHP 8.1 and below do not.
2. Update to a patched version immediately. The safe versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. If your hosting provider manages PHP versions centrally, request written confirmation that the update has been applied to your specific environment, not just to the provider's general server fleet.
3. Migrate off PHP 8.1 or older without delay. If your site requires a version that no longer receives security updates, you are permanently exposed to this vulnerability. Treat migration as urgent, not scheduled.
4. Audit your server logs for signs of compromise. Focus on activity around and after October 20-21, 2026. Indicators include unexpected new files in web-accessible directories, unusual outbound connections, unfamiliar running processes, or requests with abnormally large or malformed payloads.
5. Re-evaluate your platform strategy. PHP2Shell is not the first critical PHP vulnerability, and it will not be the last. If your organization cannot reliably close a critical patching window within a few hours, a managed platform or non-PHP architecture may be a better fit for your security posture.

If you are weighing your platform options, finding the right website partner covers what to look for in a platform and agency relationship, including questions to ask about infrastructure responsibility. For a direct conversation about a Webflow migration, visit our Webflow agency page.

Last updated: October 22, 2026. Sources: BSI advisory 2026-297981-1032; Malwarebytes blog; Wiz Research; CERT-EU advisory.