PHP2Shell: Critical PHP RCEs and How to Respond

Disclaimer

PHP2Shell is a PHP-specific vulnerability: a pair of flaws in the PHP runtime that put web servers running PHP at risk. Bloo is not affected. Bloo does not use PHP anywhere in its infrastructure, and while the Bloo SaaS platform is hosted on Amazon Web Services (AWS), none of the services we use are affected by PHP2Shell.
In the sections below we look at how this issue is playing out across the internet, and how you can use Bloo to further strengthen your own security posture against it.

What Happened?

On October 20, the PHP security team announced an out-of-band security release for October 21 to fix two critical vulnerabilities, both rated 9.2 under CVSS v4.0. Full details were due to be disclosed on October 22, but information about the flaws, including the CVE IDs, leaked early, and a proof-of-concept (PoC) video was posted online.
Exploitation attempts began before any fix was available. The earliest recorded attempt was on October 17, four days before PHP shipped patches, and activity increased sharply once the patches and details became public.

What is PHP2Shell?

The two vulnerabilities are CVE-2026-109618 and CVE-2026-109619. Both allow unauthenticated remote code execution (RCE) on PHP installations serving web requests, meaning an attacker with no credentials can compromise the web server and the applications running on it. Both stem from memory corruption that occurs when PHP runs out of memory partway through handling a request.

CVE-2026-109618 is a memory-corruption flaw in the PHP engine. An out-of-memory error can interrupt PHP while internal request data is only partially set up, and the cleanup code then treats that invalid data as valid and releases memory an attacker can influence. An attacker can trigger the out-of-memory condition deliberately, for example through crafted multipart requests.
CVE-2026-109619 is also a memory-corruption flaw in the PHP engine. After a fatal error, such as an out-of-memory crash during a file upload, request memory is freed but PHP’s global state still points at it. A later request handled by the same worker can then use that stale state, which an attacker can exploit.

It is important to note that both flaws sit in the PHP engine itself, not in an application built on PHP such as WordPress or Nextcloud. This makes them harder to deal with, because every application running on a vulnerable PHP build is exposed regardless of how well it is written. Updating the application alone is not enough; the PHP runtime itself must be patched.

Impact

The exposure is very large. Palo Alto Networks Unit 42 counts more than 22 million internet-exposed instances that are potentially vulnerable, and Cloudflare, Amazon and other providers have reported exploitation attempts against their customers and infrastructure.

Because the flaw is in PHP, only patching the runtime fixes it. PHP 8.1 and earlier branches are end-of-life and receive no official fixes from the PHP project, so many systems depend on patches backported by their Linux distribution or vendor, and some may never receive them.
PHP is also embedded in far more than websites. CMS platforms, control panels such as cPanel and Plesk, firewall web interfaces, and companion tools such as phpMyAdmin and webmail clients all run on PHP.

In our assessment, organisations should expect automated mass scanning, with bots hitting every public IP address and hostname with PHP-looking requests. Attackers who achieve RCE will most likely follow up by establishing persistence. Applying a patch after a compromise only stops new attackers from getting in; it does not evict the ones already inside.

Attackers may use this access for many purposes: stealing data, cryptomining, sending spam, hosting phishing pages, enrolling the server in a botnet, scanning other networks, and pivoting into internal networks.
Also concerning, old and neglected assets such as outdated Docker images, vendor appliances, forgotten subdomains and unmaintained marketing sites are likely to be among the first to fall. They are easy to overlook, and they can become a standard pathway into the wider environment.

Where Bloo Stands

Bloo’s platform and API tiers do not run on PHP, so no component in the request path, including proxies, gateways and bundled tools, executes PHP. The flaws live in PHP’s own memory handling, and our code runs on a different language runtime that does not contain the vulnerable code. Any request to our services that attempts to use these payloads will simply return an error response.

Detection & Prevention

As a cybersecurity company, we have a few recommendations for our customers and for anyone affected by this exploit. The most important point is that attacks began four days before the first patch was released. A system may therefore have been compromised before patching, without any obvious signs. The way to find out is through retained telemetry.
Things to look for include:

• Shells or system utilities spawned by web server or PHP processes. A PHP worker has little legitimate reason to start a shell
• New or modified files in web roots, especially executable scripts that were not previously deployed
• Unusual outbound connections from web servers to hosts never seen before
• Bursts of PHP crashes or out-of-memory errors starting from October 17, or a few days earlier, since at least one of the flaws is triggered by pushing PHP into an out-of-memory state
• New accounts, scheduled tasks or other persistence mechanisms on hosts running PHP

We hope you have kept logging active on these systems. The Bloo platform can use those logs to give you the insight you need.

If you run PHP, take the following steps:

1. Upgrade PHP immediately. The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and earlier are end-of-life and will not receive official fixes from the PHP project.
2. Check your distribution. Linux distributions and LTS vendors received the patches in advance, so updated packages may already exist for older branches.
3. Rebuild your containers independently of the host, so that images carry the patched PHP rather than inheriting it from an unpatched base.
4. Apply interim hardening while you patch, but do not treat it as a fix: keep post_max_size low, enforce request-size limits at the web server or proxy, and disable session.upload_progress where you do not need it.
5. Isolate what cannot be patched. This is a serious consideration, because attackers have a high chance of pivoting from a compromised host given the nature of this flaw.

Conclusion

A critical flaw in a language runtime affects everything built on that runtime, no matter how secure the application itself is. What matters most now is how well you know your environment, and whether your telemetry can show you what may already be hiding in it. For everything else, follow industry best practice and apply the necessary patches within your required timelines.