Node2Shell and HTTP2Shell (CVE-2026-111497): What to Patch Now

Last updated 24 October 2026, 08:15 IST.

One bug in Google's Brotli decoder is now going around under two names. Node.js disclosed it on 21 October, and it got called Node2Shell. Then it turned out Python packages and other HTTP software were affected too, and Aikido started calling the wider impact HTTP2Shell. It's the same flaw either way: CVE-2026-111497.

If you run Node.js, Bun or Python services, or anything that unpacks Brotli-compressed HTTP data, this is the patch to do this weekend. Below you'll find the fixed versions, commands to check every stack at once, a patch order, and what to do if you can't patch today. It's defensive only. There are no exploit details here.

What happened

According to the CVE record, the flaw is an out-of-bounds write in the Brotli decoder (c/dec/decode.c). It affects Google Brotli 1.0.3 through 1.2.0. The record lists CWE-787 (out-of-bounds write) and CWE-252 (unchecked return value). Its description says an unauthenticated remote attacker could corrupt decoder memory, read sensitive memory, crash the process, or potentially run code by sending a crafted Brotli stream.

Google, the CNA, scores it 9.2 Critical under CVSS 4.0, with the vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. You can paste that vector into the CVSS vector parser to see what each part means. NVD still shows "Awaiting Analysis". Note that the Node.js security release rates the same bug HIGH, not Critical. Both are real: 9.2 is Google's CVSS 4.0 score as the CNA, HIGH is Node's own severity label for its release, and NVD hasn't added a score of its own yet.

Node.js credits OpenAI Codex Security with reporting it. Google tagged Brotli 1.2.1, 1.1.1 and 1.0.10 on 21 October, and each release note lists the CVE.

Why it matters

The risk exists wherever a process decompresses Brotli data that someone else controls. Node.js says an attacker who can supply Brotli data that an application decompresses with node:zlib can corrupt process memory. In practice that means two cases:

• Servers that accept request bodies sent with Content-Encoding: br
• Clients (HTTP libraries, fetch(), crawlers, agents) that ask for br and decompress what comes back

According to Aikido, OpenAI described it as working in both directions. A malicious client can attack an unpatched server, and a malicious server can attack an unpatched client. That second case is the one people forget. Anything you run that fetches URLs it doesn't control is exposed, not just your public API.

Fixed versions

Node.js release lines that have reached end of life don't get the fix. Node says end-of-life versions are "always affected" when a security release happens, so the only fix is moving to a supported line. Linux distributions are shipping their own patched packages; Debian LTS has already put out an advisory. For a distro package, trust your vendor's advisory rather than the upstream version number.

Check your stack

These are all read-only. Run whichever ones apply.

Node.js and Bun

• node --version
• bun --version
• Judge Node by node --version, not by process.versions.brotli. Node patched its bundled copy without bumping that number, so a fixed 24.22.1 still reports Brotli 1.2.0 and a fixed 22.23.4 reports 1.1.0

Python

• pip show brotli brotlicffi
• pip list 2>/dev/null | grep -i brotli
• grep -riE "^(brotli|brotlicffi)" requirements*.txt and search poetry.lock or uv.lock for name = "brotli" and name = "brotlicffi"

Aikido notes that common Python HTTP libraries load these packages automatically if they're installed, so you may have one you never asked for. As of 23 October, Aikido also said pip-audit, Dependabot and Safety weren't flagging vulnerable versions yet. GitHub's advisory added both packages late on 23 October, so Dependabot should start flagging them, but pip-audit and Safety use other databases and may still lag. Don't wait for a scanner to catch up. Check the versions directly.

System libraries

• Debian or Ubuntu: dpkg -l | grep -i brotli
• RHEL, Fedora or Rocky: rpm -qa | grep -i brotli
• Alpine: apk info -v | grep -i brotli

Containers

Your hosts can be fully patched while your images still carry an old Node.js or Brotli. For each image you run:

• docker run --rm IMAGE node --version
• docker run --rm IMAGE pip show brotli brotlicffi

Replace IMAGE with your image name. Do the same for your base images in CI.

Patch order

1. Internet-facing services that accept compressed request bodies. That means APIs, webhooks and upload endpoints.
2. Anything that fetches outside URLs. That covers crawlers, link previewers, webhook senders, AI agents and MCP servers with fetch tools.
3. Internal services and developer machines. Do these after the first two.

For each one, update the runtime or package, rebuild the container image (patching the host doesn't fix an image), redeploy, and restart the process. A patched binary on disk doesn't protect a process that's still running the old code. Afterwards, run the version checks again against what's actually running.

Can't patch today?

These cut exposure. They don't fix the bug:

• Inbound: at your reverse proxy or load balancer, reject requests that carry Content-Encoding: br if your app doesn't need them.
• Outbound: for clients that fetch untrusted URLs, stop sending br in Accept-Encoding and also disable Brotli response decoding (or reject br responses before decoding). Aikido warns that changing Accept-Encoding alone isn't enough, because a malicious server can send Brotli anyway.
• Size limits: cap request body size and decompressed size where your framework allows it.
• Turn off Brotli decoding where you control it. Aikido recommends this where no patch exists yet.

According to Aikido, Apache's standard mod_brotli and Nginx don't decode Brotli by default. Your proxy itself probably isn't the problem. The app behind it is, if the proxy passes compressed bodies through.

AI agents and MCP servers

Most MCP servers and agent tools run on Node.js or Python, and they routinely fetch URLs chosen by a model or a user. That combination is exactly the client-side case above. If you run MCP servers, patch the runtime they run on, rebuild their images, and check which ones fetch remote content. My guide on how to vet an MCP server covers what else to look at before you trust one.

Patching fixes this bug. It doesn't control what your agents are allowed to call next time. If you want an enforced check between your agents and the MCP tools they use, Guard puts a runtime policy gate in front of agent tool calls, enforcing 22 controls. A grade finds risk; a gate enforces policy.

FAQ

Is Node2Shell the same as HTTP2Shell? Yes. Both names refer to CVE-2026-111497. "Node2Shell" came first, from the Node.js disclosure. "HTTP2Shell" is Aikido's name for the wider impact on HTTP software beyond Node.

Is it being exploited? As of writing, I haven't found a vendor or CISA statement confirming exploitation, and the CVE isn't in CISA's Known Exploited Vulnerabilities catalog. I'll update this page if that changes.

Does npm audit catch it? On Node.js the vulnerable code is bundled inside the runtime, not in an npm package, so npm audit won't see it. Check node --version instead.

I already patched PHP this week. Is this related? No. It's a separate bug in a separate project. My PHP update guide and PHP2Shell detection checklist cover that one. For checking Python dependencies more broadly, the steps in my LiteLLM supply chain write-up still apply.

More guides are on the incident response tag page.

Sources