← All articles Security alert

PHP2Shell: why websites around the world went offline

On October 21, 2026, two critical PHP flaws pushed governments and major organizations to pull their websites. Here is what it is, how it works, and why the reaction was so drastic.

CyberBay Team6 min read

What PHP2Shell is

PHP2Shell is a pair of critical PHP vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Both let an unauthenticated attacker run their own code on a server running PHP — in other words, take control of it. Both carry a severity score of 9.2 out of 10, the “critical” category.

What makes this a global event is the attack surface. PHP is the most widely used server language on the web: it powers nearly 70 % of all sites. Every installation that serves web requests is affected, and even old, unmaintained branches like PHP 5 are vulnerable.

PHP in two minutes

To understand the flaw, you have to separate two things the word “PHP” means at once. First, a programming language. Then a runtime: the engine that reads and executes that language, called the Zend Engine, and — crucially — written in C.

  • Your .php files hold the source code, as text.
  • The engine reads that file, compiles it into opcodes (an internal instruction set, not an .exe) and executes those opcodes in its virtual machine. Nothing is shipped as a binary: everything is recompiled and executed on the fly, server-side.
  • The browser never sees your PHP code. It only receives the result of the execution: HTML, or JSON for an API.

And WordPress in all this? It is an application written in PHP (a content management system), like Laravel or Symfony. PHP is the engine; WordPress is the car built around it. That is why a flaw in PHP mechanically affects a huge share of the web, WordPress included.

The path of a request, and where the flaw strikes

Here is the full journey, from the code repository to what the browser displays. The point marked in red is exactly where PHP2Shell operates.

GitHub repo (.php code) → deployed to the server Browser client Web server Apache · Nginx PHP runtime Zend engine · in C ! Data DB · files reads .php → opcodes → executes Response: rendered HTML — your PHP code never leaves the server The flaw lives here — inside the engine Memory corruption in the C code, while PHP handles the request, underneath your application. No clean code can stop it.
The path of a PHP web request and where the PHP2Shell flaw strikes

The key point reads straight off the diagram: the flaw is neither in the web page nor in the application code (it is not a WordPress bug or a developer’s bug). It is in the PHP engine, at the stage where the interpreter handles the request, before your code even gets a say.

How the flaw works

These are not classic application flaws (not SQL injection, not XSS): they are memory-corruption bugs in the engine, the kind of problem that exists because PHP’s core is written in C, where memory is managed by hand.

  • CVE-2026-109618 — out-of-memory corruption. It triggers when PHP runs out of memory midway through setting up a request, leaving internal structures half-built that the cleanup code then treats as valid.
  • CVE-2026-109619 — stale global state. Internal state outlives the request memory it pointed to; the next request, handled by the same PHP process, can then act on that stale data. Typical of persistent PHP servers.

The most dangerous scenario is Apache mod_php, where PHP is embedded directly in the web server: the attack can succeed before the application code even runs.

Why so many sites went offline

Three factors combined into a perfect storm:

  • A leak before disclosure. Details circulated publicly before the planned date. PHP had to move its patches up by 24 hours, but exploit code had already appeared online.
  • Immediate exploitation. Real attack attempts were observed as soon as it went public, and by the millions in under two days.
  • No reliable workaround. PHP was clear: no configuration change fully neutralizes these flaws. The only real protection is the patch.

Faced with an unauthenticated RCE, already exploited, with no possible mitigation and potentially affecting every PHP server, many organizations chose the only safe option while waiting to patch: pulling the plug. That is how government services (France, the Netherlands, Finland and Denmark, among others) and large companies like Nintendo took sites offline temporarily.

What to do now

  • Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, matching your branch, then restart every PHP process so the fix takes effect.
  • Prioritize what is exposed to the internet, starting with servers running Apache mod_php.
  • Inventory every server and application that runs PHP — including old, forgotten installations.
  • Branches 7.4, 8.0 and 8.1: use a distribution or LTS package, or PHP’s minimal backports. 7.3 and earlier (including PHP 5): no fix, you have to migrate.
  • If a system cannot be patched right away, restrict its access from the internet.

References

  • PHP security advisory (php.net), October 21, 2026 — fixed versions and official details.
  • NVD: CVE-2026-109618 and CVE-2026-109619.
  • NCSC (UK) alert on the critical issue affecting PHP.
  • Technical analysis and exploitation tracking: watchTowr Labs, Calif.io.

Are your exposed servers up to date?

We inventory your estate, check your exposure to critical flaws and hand you a prioritized action plan.

Contact us