node2shell

What it means for your AI agents

Agent backends, MCP servers and webhook receivers are usually built on these runtimes and libraries. A flaw that runs code before authentication hands an attacker the agent's keys and tool access, not just the server.

• Check the services behind your agents and MCP tools, including ones that only call outward.
• Look for the affected component in dependencies too, not just the runtime you installed directly.
• Until patched, treat output from an affected service as untrusted input to your agents.

Updates

• Oct 21, 2026 : Node.js published security-release guidance for the vulnerability.

Details

node2shell is the early name for CVE-2026-111497, an out-of-bounds write in the Brotli decoder. The decoder can mistake a malformed block switch for a temporary lack of input, continue appending bytes to a small internal buffer, and corrupt process memory.

The name can be misleading: the flaw is in a widely reused Brotli library, not in Node.js alone. It can reach applications through runtimes, HTTP clients, framework middleware, and container images that bundle or install the decoder.

In Node.js, applications can reach the decoder through node:zlib or Brotli-aware request middleware. Node.js built-in fetch is powered by Undici and automatically handles Brotli responses, so server-side URL fetches and remote-image features require review too. Next.js remote image optimization is one such path. Gzip, Deflate, and Zstd use different decoders. Remediation guidance was still developing at the October 25 review.

Risk

The decoder is used beyond Node.js, including in server-side fetches. The October 25 review did not confirm active exploitation.

Affected deployments

Services that use a vulnerable Brotli decoder, including bundled copies in runtimes and container images. Node.js request middleware and server-side fetches both need review.

Recommended action

Update or remove vulnerable Brotli decoders using each vendor's guidance, including copies bundled with runtimes or container images.

1. 1Inventory runtimes, HTTP libraries, dependencies, and container images that provide Brotli decoding.
2. 2Apply the security update or vendor guidance for every affected component, then rebuild and redeploy affected workloads. Node.js security advisory
3. 3Prioritize inbound Brotli request handling and outbound fetch, webhook, crawler, URL-preview, proxy, and remote-image features that retrieve untrusted responses.

Check your exposure with an agent

Paste this into an AI agent that can see your infrastructure. It asks for a read-only check of what's affected, including the systems behind your agents, and a table you can act on. Copying it changes nothing.

Assess whether the infrastructure you can access is affected by node2shell (CVE-2026-111497). Work read-only within your authorized access: do not run exploits, change configuration, restart services or install anything.

1. Confirm the affected and fixed versions from the vendor advisories and CVE records:
   - https://nodejs.org/en/blog/vulnerability/october-2026-security-releases#nodejs-brotli-decoder-out-of-bounds-write-permits-remote-code-execution-cve-2026-111497---high
   - https://www.cve.org/CVERecord?id=CVE-2026-111497
   - https://www.aikido.dev/blog/python-packages-vulnerable-node2shell-brotli-cve-2026-111497
   Cite each source and the date you read it. Say plainly what you could not verify.

2. Inventory the systems that could run the affected software, including the hosts, containers, MCP servers, tool runners and sandboxes behind any AI agents. For each, record the asset, environment, owner if known and the version actually running, from read-only evidence (package metadata, version commands, platform inventory).

3. Note which affected systems are reachable from the internet or from agents and tools, and which credentials (model-provider keys, tool tokens, service accounts) are stored on them.

4. Report one row per asset: asset, running version, affected (yes / no / unknown), reachable from, credentials at risk, evidence, and the next step. List anything you could not access as a gap rather than assuming it is safe.