Brotli Vulnerability CVE-2026-111497: Why Patching the OS Isn’t Enough

The Brotli vulnerability CVE-2026-111497, nicknamed HTTP2Shell, is a buffer overflow in Google's compression decoder that can crash processes, leak memory and allow remote code execution in Node.js, Python and .NET applications. Proof-of-concept exploits are public, and updating the system Brotli package, the fix most admins try first, leaves many deployments still vulnerable.

What is HTTP2Shell and how does it become remote code execution?

HTTP2Shell, also called Node2Shell and Broccoli2Shell, is a memory-corruption bug in the streaming decoder of Google’s open-source Brotli library. That C decoder is compiled into Node.js and embedded in Python packages and .NET, so one flaw produced emergency releases across all of them. It was first identified in Node.js; the other names appeared as researchers found it elsewhere. Despite the name, it is not specific to HTTP/2.

Per the Node.js advisory, “an invalid block switch was reported as a temporary need for more input instead of a permanent format error, so the streaming decoder kept appending input bytes to an eight-byte internal buffer.” Each appended chunk lands past the buffer’s end and overwrites whatever follows. Node.js says this “can crash the process, expose memory, and enable remote code execution,” and Imperva has published research confirming the RCE path. The decoder is native code inside the host process, so JavaScript, Python or C# memory safety offers no protection; a successful exploit runs with that process’s privileges.

Affected Brotli releases are 1.0.3 through 1.0.9, 1.1.0 and 1.2.0. Fixes reached the upstream source in February, roughly eight months before Node.js and Google shipped stable releases on 21 October. Public disclosure followed on 22 October, fixed PyPI packages on 23 October, and Microsoft’s emergency .NET update the following Sunday, with a warning that exploitation allows privilege escalation.

Am I affected? The two attack paths that matter

You are affected if any of your software decompresses Brotli data an outsider can influence, in either direction.

Path 1: a compressed request to your server

An attacker sends a body marked Content-Encoding: br to a service that decompresses it automatically, such as a Node.js API, a webhook receiver or a Python backend.

Path 2: a malicious response to your client

Your server fetches a URL and the remote side answers with a crafted Brotli response. TLS does not help: decompression happens after decryption, inside your application. Clients called out as at risk are urllib3[brotli], requests, httpx and aiohttp[speedups] when they load a vulnerable decoder. Link previews, remote media imports, feed readers, update checks and CRM or payment integrations all count, and attackers already map which sites fetch remote URLs on request and point them at servers they control (see how hackers find and target vulnerable websites).

On WordPress and Joomla sites, check the Node.js tooling, headless front ends, Python workers and .NET services beside the CMS, not PHP.

Which versions fix the Brotli vulnerability CVE-2026-111497?

Advisories list only these three Node.js lines. Treat any older LTS line as exposed until the vendor says otherwise.

Find every decoder actually loaded in memory

What matters is the decoder loaded into each running process, not the one your OS package manager reports. Node.js ships its own copy, so upgrading libbrotli with apt or dnf changes nothing for it; the same goes for Python wheels in virtual environments, statically linked binaries and container layers. Search lock files and Dockerfiles for brotli, brotlicffi and Node.js base-image tags, including build machines, cron workers and staging containers.

• Node.js: run node -v on every host and confirm a fixed release.
• Python: run pip show Brotli brotlicffi in every virtual environment and container.
• Restart: restart every worker, sidecar and PM2 or systemd service; a patched file on disk does not replace a library already mapped into memory.
• Containers: rebuild from updated base images, redeploy, and confirm old replicas are gone.

How do I spot attacks and mitigate before patching?

Public reporting includes no indicators of compromise. Watch for repeated segfaults in processes that handle compressed traffic and for Content-Encoding: br requests at endpoints that never expect them. For a suspicious crash, preserve the core dump, image digest, runtime and decoder versions, and the request or URL that triggered decompression. A crash alone does not prove exploitation.

If you can’t patch today, remove Brotli support from Python applications so their HTTP clients stop decoding br, and block inbound Brotli-compressed requests at your reverse proxy or website firewall. The block does nothing for Path 2 and may break legitimate API clients that send br bodies. No in-the-wild exploitation has been reported yet; use that window to finish upgrades and restarts.

FAQ

What is CVE-2026-111497 (HTTP2Shell)?

A buffer overflow in Google's Brotli streaming decoder that can crash processes, leak memory or allow remote code execution.

Does updating my server's Brotli library fix Node.js apps?

No. Node.js bundles its own decoder, so upgrade the runtime, restart processes and rebuild container images.

Is the Brotli vulnerability being exploited in the wild?

None has been reported, but proof-of-concept exploits are public.

If a vulnerable service was exposed before you patched, check it for signs of compromise rather than assuming it is clean. SiteGuarding Antivirus website protection scans and monitors your site and helps you recover if something got in.