PHP2Shell, Node2Shell, HTTP2Shell: What to Patch and How to Check

PHP2Shell. Node2Shell. HTTP2Shell. Three “run code on your server” bugs landed in the same week of October 2026, and the names are already in a lot of team chats. If you are not sure where you stand, this is the short, practical version: what each bug is, which versions fix it, how to check your own servers in a couple of minutes, and the one gap we keep finding even on servers that look patched.

The short version

• PHP2Shell is a bug in PHP itself, and it is already being exploited. Fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
• Node2Shell and HTTP2Shell are one bug with two names. It lives in Brotli, a compression library used across a huge amount of web traffic, so it hits Node.js, Python, Bun and more. Node.js is fixed in 22.23.4, 24.22.1 and 26.12.1.
• Upgrading your language runtime is not always enough. The Brotli library on the operating system can stay vulnerable after everything else is patched (more on that below).

PHP2Shell (CVE-2026-109618, CVE-2026-109619)

Two related flaws in PHP’s core let an unauthenticated attacker corrupt PHP’s internal state and turn that into remote code execution, running as your web server user. It affects ordinary web deployments: PHP-FPM, Apache’s PHP module, php-cgi and others. You do not need to be running anything unusual. Exploitation attempts were seen in the wild before the fixes shipped on 21 October.

The fixed releases are:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

PHP 8.1 and older are end-of-life and get no new official releases. If you are still on 7.4, 8.0 or 8.1, the realistic fix is an upgrade to a supported version, or an extended-support vendor in the meantime.

One detail matters if you use your Linux distribution’s packages. Ubuntu and Debian often backport the fix without changing the version number, so php -v may still say something like 8.5.4 even though the hole is closed. In that case, check the package changelog for the CVE IDs rather than trusting the version string.

Node2Shell / HTTP2Shell (CVE-2026-111497)

This one is in Brotli, Google’s compression format, which browsers and servers use to shrink web traffic. A malicious Brotli stream can trigger memory corruption in the decoder. Anything that decompresses Brotli data from someone it does not trust is exposed. It got called Node2Shell because Node.js bundles Brotli, and HTTP2Shell once people realised how many HTTP clients and libraries decode it automatically.

• Brotli library: affected from 1.0.3 through 1.2.0. Fixed in 1.0.10, 1.1.1 and 1.2.1.
• Node.js: fixed in 22.23.4, 24.22.1 and 26.12.1. Node 20 and older get no fix, so they need an upgrade.
• Python: brotli 1.2.1 and brotlicffi 1.2.1.0.
• Everything else: Bun, browsers and many proxies and libraries bundle their own copy of Brotli, so each one needs its own update.

Check yourself in 2 minutes

Run these on each server (and inside each container image you deploy):

1. PHP version: php -v. Remember that the web server may run a different PHP than the command line. Check the PHP-FPM or Apache version too.
2. Distro PHP packages: on Debian/Ubuntu, zcat /usr/share/doc/php8.4-common/changelog.Debian.gz | grep CVE-2026-1096 (swap in your PHP version).
3. Node.js: node -v. Do it for every Node install, including ones managed by nvm, Docker images and CI runners.
4. System Brotli used by curl: curl -V prints the Brotli version libcurl is linked against (look for brotli/1.x.x).
5. Brotli inside PHP: php -i | grep -i brotli shows whether PHP’s curl extension can decode Brotli, and which library version it uses.
6. Python: pip show brotli brotlicffi in each virtualenv.
7. Docker: for each image you run, docker run --rm --entrypoint sh IMAGE -c "php -v; node -v; curl -V". Base images go stale quietly, and forgotten side services are where old versions hide.

The gap we keep finding: patched runtime, unpatched system library

When we audited servers after these bugs dropped, PHP and Node.js were the easy part. The surprise was the operating system’s own Brotli library. Node.js ships its own copy, so upgrading Node fixes Node. But PHP, curl, image libraries and many other tools use the system library, and distribution updates can lag. As of 24 October, Ubuntu still listed its Brotli package as “needs evaluation”, with no fixed version.

Why it matters: PHP’s curl extension, and Guzzle / Laravel’s HTTP client on top of it, will happily decode a Brotli response from a remote server, even if your code never asked for Brotli. With default settings, the client turns on automatic decoding and libcurl then decodes any format it supports. In our tests, forcing Accept-Encoding: gzip, deflate did not stop it.

So the real exposure is any feature that fetches a URL someone else controls:

• backlink and link checkers
• URL previews and Open Graph scrapers
• webhooks that call out to customer endpoints
• image proxies and “import from URL” features
• free online tools where anyone can paste a URL

A hostile server only has to answer one of those requests with a booby-trapped Brotli body. Until your distribution ships a fixed package, the options that actually work are to turn off automatic decoding in your HTTP client (in Guzzle/Laravel, decode_content => false), or to install a patched libbrotli (1.2.1 or a backported build) and restart everything that loads it. Putting public URL tools behind a login or a rate limit is a sensible extra layer.

How we can help

• Find every place PHP, Node.js and Brotli actually run, including Docker images, CI runners and forgotten side services.
• Patch and test, so production keeps running while the fixes go in.
• Move stuck legacy apps (PHP 7.4 / 8.0 / 8.1, old Node.js) to supported versions.
• Add edge / WAF rules and interim mitigations while the upgrades roll out.

If these names landed in your team chat and you would rather not spend the week on it, get in touch and we will tell you where you stand.