Short answer: HTTP2Shell is the new, wider name for CVE-2026-111497, a flaw in Google’s Brotli compression decoder that was first widely reported as Node2Shell. It is one vulnerability, not a second bug. The reason it has a new name is that the same decoder code turns up in far more software than Node.js alone, including Bun, Python packages, Envoy and Istio, so each of those projects has had to ship its own fix.
If you run any service that unpacks Brotli data you did not create yourself, this is worth checking today. The fix is usually a version update, followed by a restart and a rebuild of any container image that bundles the old decoder. As of October 24, 2026, no real world exploitation had been reported, but public research had already shown code execution on one unpatched Node.js build, which is why waiting for an attack report would be a poor strategy.
What is HTTP2Shell?
HTTP2Shell is the name researchers began using late on October 23, 2026, for the Brotli decoder flaw tracked as CVE-2026-111497. The name refers to reach, not to a protocol version. Brotli is used across both HTTP/1.1 and HTTP/2 to shrink web traffic, and anything that inflates Brotli data over HTTP is in scope if it uses the affected C decoder.
Technically, the flaw is an out-of-bounds write. A crafted Brotli stream can make the decoder write past the end of a small working buffer and corrupt nearby memory. Depending on the program and the input, that can crash the process, leak sensitive memory, or, in the demonstrated Node.js case, run attacker supplied code with the permissions of that process.
Google, which assigned the CVE, scores it 9.2 on the CVSS 4.0 scale, which is critical. Node.js rates the same flaw as high, and Red Hat rates it 8.1, or important. Those differences come from different scoring methods and different views of how easily the flaw can be reached in each product. They do not change the practical advice: update the affected component.
Node2Shell, HTTP2Shell, and the earlier Node.js update: what changed?
Readers who followed the October 21 disclosures may wonder whether HTTP2Shell is something new. It is not a new CVE. The sequence matters, so here it is in order.
On October 21, 2026, Node.js shipped security releases 22.23.4, 24.22.1 and 26.12.1, and Google shipped fixed Brotli versions 1.0.10, 1.1.1 and 1.2.1. At that point the flaw was mainly discussed as a Node.js problem, and researchers called it Node2Shell. Our earlier coverage focused on that Node.js update and the ten vulnerabilities fixed in the same release, which you can read in our Node.js October 2026 security update guide.
On October 22, Imperva researchers demonstrated code execution on an unmodified Node.js 24.22.0 build for Linux on ARM64, delivered both as a fetched response and as an Express request body. The exploit took several tries, has not been publicly released, and was not tested on every build.
From late October 23 onward, the picture widened. Bun confirmed it bundled the same decoder, Python package advisories appeared for the brotli and brotlicffi packages, and The Hacker News published a product by product table covering Envoy, Istio and other software. That wider blast radius is what the HTTP2Shell name describes. If you only patched Node.js on October 21, you may still have the same decoder sitting in another part of your stack.
Which software is affected?
A program is exposed only if it decodes Brotli data controlled by someone else. A plain Node.js HTTP server, for example, does not decode request bodies on its own. The risk appears when a runtime, framework or HTTP client unpacks Brotli automatically.
The table below summarises the fixed versions reported by The Hacker News, Node.js, Bun and the Python advisories. Check your own vendor notes as well, because system packages and distributions are shipping fixes on different schedules.
Affected software and fixed versions
- Google Brotli C library: versions 1.0.3 to 1.2.0 affected. Fixed in 1.0.10, 1.1.1 and 1.2.1.
- Node.js: 22.x, 24.x and 26.x before the fix affected, plus end of life 20.x and older. Fixed in 22.23.4, 24.22.1 and 26.12.1.
- Bun: 1.4.3 and earlier affected. Fixed in 1.4.4.
- Python brotli package: 1.2.0 and earlier affected. Fixed in 1.2.1.
- Python brotlicffi package: 1.2.0.x and earlier affected. Fixed in 1.2.1.0.
- Envoy: versions 1.39.2, 1.38.5, 1.37.7 and 1.36.11 affected. Fixed in 1.40.0, 1.39.3, 1.38.6, 1.37.8 and 1.36.12, and only where the Brotli decompressor is configured.
- Istio: versions 1.31.0 to 1.31.1, 1.30.0 to 1.30.5 and 1.29.0 to 1.29.8 affected. Fixed in 1.31.2, 1.30.6 and 1.29.9, and only where Brotli decompression is enabled.
Other tools that bundle or scan with the decoder are also being updated, including standalone binaries of cdxgen. The lesson is to inventory the decoder, not just the headline product. If a container image, a bundled runtime or a vendored library contains Brotli 1.2.0 or earlier, it needs its own update.
How does an attack work?
The flaw works in both directions, which is part of why its scope is so wide. OpenAI’s Codex Security team, whose researchers Khai Tran and Sylvie Mayer reported the flaw, describes it as enabling unauthenticated remote code execution in both directions.
First, a malicious client can attack an unpatched server. That happens when the server accepts a Brotli compressed request body, for example through Express 5 body parsing, and unpacks it before application code ever sees it. Second, a malicious server can attack an unpatched client. That happens when a client automatically decompresses a Brotli response, for example through Node.js fetch, Bun fetch, or a Python HTTP client, and the server it contacted sends a crafted compressed payload.
In Python, the risk is easy to miss. Once the brotli or brotlicffi package is installed, HTTP clients such as requests, urllib3, httpx and aiohttp decode Brotli responses on their own. An application can therefore be exposed without ever importing Brotli in its own code. That is why checking installed packages matters as much as checking application code.
For Envoy and Istio, the exposure is narrower. The flaw can only be reached where Brotli decompression is actually enabled, for example through an Envoy filter. Where it is off, the flaw cannot be reached through that path.
What has not been proven yet?
It is important to separate what has been demonstrated from what is still only possible in theory. Code execution has been demonstrated on one Node.js build, as described above. The same has not been demonstrated on Bun, Python, Envoy or the other software in the table, and no real world attacks had been reported as of October 23, 2026. CISA’s assessment on that date recorded exploitation as none, and the flaw was not in the CISA Known Exploited Vulnerabilities catalog at that point.
That does not make the flaw low priority. Memory safety flaws in code that handles untrusted network input tend to move quickly from research to weaponisation once details spread, and the fix here is a routine version bump in most cases. Treat the absence of reported attacks as a window to patch, not as a reason to wait.
Why did a February fix take until October to reach users?
The HTTP2Shell story has an awkward history that explains much of the current patching scramble. The change that closes the flaw was added to Brotli’s source code on February 27, 2026, but at the time it was not recognised as a security fix, and no new Brotli release carried it until October 21.
Because each runtime and package ships its own copy of the decoder, fixing the upstream source was not enough. Node.js had to cherry pick the change, Bun had to ship 1.4.4, Python packages had to release 1.2.1 and 1.2.1.0, and Envoy and Istio had to ship their own patched builds. Every private copy has its own patch lag, and that lag is exactly what attackers can exploit when a flaw becomes public.
This is also why the same week produced a second lesson about foundational code. The PHP2Shell flaws disclosed on October 21 were likewise old, complex issues that frontier AI research helped turn into working exploits. Foundational libraries deserve the same inventory discipline as headline applications, because a flaw in one of them can appear in dozens of products at once.
What to do now: a practical checklist
Work through this list in order, starting with the services most exposed to untrusted input. Services that accept compressed request bodies, or that fetch compressed responses from other servers, should go first.
1. Update Node.js, Bun and Python packages
Move Node.js to 22.23.4, 24.22.1 or 26.12.1, depending on your release line. Move Bun to 1.4.4 or newer. In Python environments, move the brotli package to 1.2.1 and brotlicffi to 1.2.1.0. If you cannot update Python packages yet, uninstalling brotli and brotlicffi will make clients fall back to gzip and deflate, which removes that decoding path.
2. Update Envoy, Istio and system packages
Update Envoy and Istio to the fixed versions in the table above if Brotli decompression is enabled. Check your operating system packages separately: Debian, for example, fixed its brotli package for Debian 13 on October 23, while other distributions were still pending a fix on October 22. Do not assume a runtime update also fixed the system library, or the reverse.
3. Restart services and rebuild container images
A running process keeps the old decoder in memory until it restarts, so restarting after an update is not optional. Rebuild any container image that bundles an affected runtime or library, and redeploy from the rebuilt image rather than patching a running container and leaving the old image in your registry.
4. Reduce exposure where you cannot update yet
Where an update is not immediately possible, stop decoding untrusted Brotli. Reject incoming requests with Content-Encoding: br before any proxy or parser decodes the body, turn off automatic Brotli decoding in HTTP clients, and reject Brotli responses before they are decoded. Note that simply removing br from the Accept-Encoding header does not help on its own, because a server can send Brotli whatever the client asks for.
5. Check your scanners, and do not rely on them alone
Dependency scanners may not flag the Python packages yet. The CVE record names Google’s Brotli repository, not the PyPI packages, and advisory databases were still catching up on October 23. GitHub advisory GHSA-9v8h-qqgm-4m35 covers the Python packages, and PYSEC advisories for the two packages were added on October 23, but manual version checks remain worthwhile until scanner mappings settle. Check installed versions directly, especially in Python environments where the package may be present without being imported by your own code.
A web application firewall can help for some request paths, but it does not close the whole hole. Vercel, which added firewall rules on the day of disclosure, said those rules do not cover responses your functions fetch from other servers. For that path, only updating the runtime or library closes the hole.
What should small teams and solo developers prioritise?
If you run a small site or a side project, start with the simplest check: which Node.js, Bun or Python version is actually running in production, not just on your laptop? Then check whether Brotli decoding is even happening. If your app never accepts compressed bodies and never fetches compressed responses from untrusted servers, your exposure is lower, but a framework or client library may be doing it for you without an obvious line of code.
For WordPress site owners, the direct lesson is different but related. WordPress itself is not the product named in this advisory, yet the same week showed how a language level flaw can force sites offline, as covered in our follow up on PHP2Shell exploit attempts and government shutdowns. Keep PHP, your runtime and your plugins on supported, patched versions, and treat a foundational library update with the same urgency as a plugin security release.
FAQ
Is HTTP2Shell a different vulnerability from Node2Shell?
No. Both names describe CVE-2026-111497, an out-of-bounds write in Google’s Brotli decoder. Node2Shell was the early name, when the focus was Node.js. HTTP2Shell is the later, wider name, reflecting that Bun, Python, Envoy and other software use the same decoder.
Is HTTP2Shell being exploited in the wild?
No real world exploitation had been reported as of October 23, 2026, and CISA recorded exploitation as none on that date. Code execution had been demonstrated in research on one unpatched Node.js build, but the exploit had not been publicly released and had not been tested on the other affected software.
Which Node.js versions fix the flaw?
Node.js 22.23.4, 24.22.1 and 26.12.1 fix the flaw. End of life versions, including 20.x and older, remain affected and should be moved to a supported, patched release line.
Do I need to patch Python if my code never imports Brotli?
Yes, check it anyway. If the brotli or brotlicffi package is installed, HTTP clients such as requests, httpx and aiohttp can decode Brotli responses automatically. Update to brotli 1.2.1 or brotlicffi 1.2.1.0, or uninstall the packages if you do not need Brotli support.
Does disabling Brotli in my browser or client fully protect me?
No. Removing br from the Accept-Encoding header does not stop a server from sending Brotli data, and it does nothing for server side request bodies. The reliable fix is updating the affected runtime, library or proxy, then restarting the service and rebuilding container images.
What if I cannot update right away?
Reject untrusted Brotli data before it is decoded, turn off automatic Brotli decoding in clients, and, in Python, uninstall the Brotli packages so clients fall back to gzip and deflate. Treat those steps as a temporary mitigation, not a substitute for the update, and schedule the update as soon as possible.