Brotli Decoder Flaw: What CVE-2026-111497 Means for Your Apps

By Jaspal Singh October 27, 2026 Updated: October 27, 2026

CVE-2026-111497 is a memory-corruption bug in Google's Brotli decoder, the code that unpacks Brotli-compressed data. Any program that decompresses Brotli from an untrusted source can crash, leak memory or possibly run attacker code. Node.js, .NET and Python have shipped fixes, but bundled copies mean many apps need rebuilding, not just updating.

What Happened

On October 21, 2026, the Node.js project published its October 2026 security release, fixing ten vulnerabilities across the 22.x, 24.x and 26.x lines. The most serious, rated high severity, was CVE-2026-111497: an out-of-bounds write in the Brotli decoder that Node.js bundles to support Brotli in its built-in node:zlib module. The project credited Khai Tran and Sylvie Mayer of OpenAI's Codex Security team with the report. Patched builds are Node.js 22.23.4, 24.22.1 and 26.12.1.

The same day, Google tagged three new Brotli releases, 1.0.10, 1.1.1 and 1.2.1, each listing the CVE as an out-of-bounds write that permits remote code execution, according to the project's GitHub releases page. BleepingComputer reported that affected Brotli versions run from 1.0.3 through 1.0.9, plus 1.1.0 and 1.2.0, and that patched Python packages (Brotli 1.2.1 and brotlicffi 1.2.1.0) reached PyPI on October 23.

On Sunday, October 25, Microsoft followed with an out-of-band .NET security update, asking customers to update "as soon as possible." The fixed releases are .NET 8.0.33, 9.0.22 and 10.0.14, with .NET 11 users told to move from Release Candidate 2 to Release Candidate 3. The Register reported that Microsoft's advisory scores the flaw 8.1 under CVSS 3.1 and rates exploitation as "more likely," while noting no confirmed attacks. Bun, Envoy and Istio have also shipped patches, the outlet said.

The bug has collected several nicknames, including Node2Shell, Broccoli2Shell and HTTP2Shell, because it was first disclosed through Node.js and later found to reach other ecosystems. It arrived in the same week as the PHP2Shell flaws, which helped it slip under the radar for a few days.

Why It Matters

Brotli is everywhere on the modern web. Browsers advertise support for it, CDNs use it to shrink pages, and HTTP libraries in most languages can decode it automatically. That ubiquity is what makes a decoder bug dangerous: the vulnerable code sits deep inside runtimes and libraries that developers rarely think about.

The exposure is wider than web servers. Security researchers at JFrog showed, according to The Register, that FFmpeg reaches Brotli through libjxl when it reads metadata inside JPEG XL images, so a crafted image file can trigger the bug without any HTTP request at all. The same researchers said Apache Arrow can be knocked over with a denial-of-service attack. Cloud security firm Wiz told The Register that 91 percent of the cloud environments it sees run components affected by the flaw.

The bigger lesson is about patch reach. Updating a server's system packages does not fix a runtime that carries its own copy of the library. Node.js ships Brotli inside its binary. Self-contained .NET apps carry their own runtime. Container images freeze whatever library versions existed on the day they were built. Each of those copies needs its own update, which is why every vendor advisory ends with the same instruction: rebuild, redeploy and restart.

How It Works

Brotli compresses data into a stream of blocks, and the decoder can switch between block types and context settings as it reads. A streaming decoder, the kind used when data arrives in chunks over a network, has to decide at each step whether the input so far is broken or merely incomplete.

The Node.js advisory explains where that decision went wrong. When the decoder hit an invalid block switch, it reported a temporary need for more input instead of a permanent format error. So the decoder kept waiting for more data and appending incoming bytes to an eight-byte internal buffer. A malicious stream could keep feeding bytes, and once the buffer was full, the writes ran past its end into neighbouring memory.

What an attacker can do with that overflow depends on the program. The Node.js team lists three outcomes: a crash, disclosure of process memory, or remote code execution. Microsoft describes the .NET impact as information disclosure, denial of service or elevation of privilege. Security firm Imperva has reported that code execution is achievable against Node.js, according to BleepingComputer, though some public proof-of-concept code only crashes a stock Node.js process.

There are two ways attacker-controlled Brotli reaches a vulnerable decoder:

Inbound requests. A client sends a request body marked Content-Encoding: br to a server that decompresses request bodies. In .NET, this is ASP.NET Core's request decompression middleware, which is off by default.
Fetched responses. Your application fetches a URL, and the remote server returns a malicious Brotli-compressed response that your HTTP client decodes automatically. This covers webhooks, link previews, scrapers, AI agents browsing the web and any server-side request to an address a user can influence. In .NET, HttpClient automatic decompression is the relevant setting, also off by default.

The second path is the one firewalls miss. Vercel's security bulletin says its web application firewall rules block the inbound attack on its network, but only the runtime patch protects against Brotli responses an app fetches itself. The same applies to any proxy rule that strips or rejects compressed requests.

For a practical check, start with three questions. Which runtimes are running, including those inside containers and CI images? Do any of them decompress request bodies? Do any of them fetch URLs and decode Brotli responses? For Node.js, the version number answers the first question. For .NET, dotnet --list-runtimes shows installed shared runtimes, but self-contained apps must be checked one by one. For Python, look for the brotli or brotlicffi packages, which libraries such as urllib3, requests, httpx and aiohttp use when Brotli support is enabled.

What's Still Unknown

The full list of affected software is still growing. Brotli is vendored into many C and C++ projects, embedded devices and language bindings, and each maintainer has to notice, update and ship. Linux distributions, game engines and appliance firmware may take weeks.

It is also unclear how reliably the bug turns into code execution across platforms. Researchers have shown memory disclosure and command execution in some setups, while other proofs of concept only cause crashes. Modern memory protections vary by runtime and operating system, and the gap between a crash and a working exploit is often where attackers spend their effort.

Finally, there is the question of how long the fix sat unnoticed. OpenAI said the root cause had been fixed in Brotli's source code in February, but the fix was not recognised as security-relevant and no Brotli release carried it until October 21. How many other quiet fixes in widely embedded libraries are waiting for a release, and a CVE, is a question the open-source world has no good answer to yet.

Frequently Asked Questions

Am I affected if my website only serves Brotli-compressed pages?

Probably not through that path. Serving Brotli means your server compresses data, and the flaw is in the decoder. The risk comes from software that decompresses Brotli it did not create, such as a server that accepts compressed request bodies or a client that fetches and decodes compressed responses. Check both directions before concluding you are safe.

Does updating my operating system's Brotli package fix Node.js?

No. Node.js bundles its own copy of the Brotli decoder, so a patched system library does not change the copy inside the Node.js binary. You need Node.js 22.23.4, 24.22.1 or 26.12.1. The same logic applies to self-contained .NET apps, Python wheels that ship their own decoder, and container images built before October 21.

Which .NET versions fix CVE-2026-111497?

Microsoft's October 25 out-of-band release lists .NET 8.0.33, 9.0.22 and 10.0.14, and .NET 11 users should move to Release Candidate 3. Microsoft says .NET Framework is not affected. Run dotnet --list-runtimes to see what is installed, and remember that self-contained apps and containers carry their own runtime and must be rebuilt.

Is the Brotli flaw being exploited in the wild?

As of October 26, neither Node.js nor Microsoft reported attacks in the wild. Proof-of-concept exploits are public, though, and Microsoft's advisory rates exploitation as more likely, according to The Register. Public exploit code for a widely embedded library usually shortens the time before real attacks start, so treat this as urgent rather than theoretical.

Can a web application firewall protect me instead of patching?

Only partly. A firewall or proxy rule can block inbound requests marked with Content-Encoding: br, which covers attackers sending compressed bodies to your server. It does nothing for responses your own application fetches from other servers and decompresses. Vercel's bulletin makes this point directly: its firewall rules cover inbound traffic, and only the runtime patch covers fetched responses.

What about Node.js 20 and older versions?

Node.js 20 and earlier are end of life and will not get an upstream fix, according to the Node.js project and Vercel. Third-party vendors such as HeroDevs have said they will ship patched builds for some old lines, but the safer route is upgrading to a supported release line. Old Node.js versions often hide inside CI runners and build images, so search those too.

Why did a bug fixed in February only become a CVE in October?

The underlying fix landed in Brotli's source code earlier in the year, but nobody recognised it as a security problem at the time, and no new Brotli release shipped it. Software that embeds Brotli kept using vulnerable tagged versions. Once OpenAI's Codex Security researchers showed the memory corruption, Google tagged versions 1.0.10, 1.1.1 and 1.2.1 on October 21.