A Bug Was Fixed in Brotli’s Source Code in February.

A Bug Was Fixed in Brotli's Source Code in February. No Release Shipped, So Every App That Bundled It Stayed Vulnerable

Between a fix in a repository and a fix in your running app, there are two more steps. CVE-2026–111497 shows exactly where they got stuck, and what to check today.

Here is a strange kind of security bug. The fix already existed. It had been sitting in the project's source code for months. And yet, until October, software that used the library stayed vulnerable.

That is the story of CVE-2026–111497, a bug in Brotli, the compression library found inside Node.js, Bun, Python packages, Envoy, Istio and .NET. It is a good lesson in the difference between "fixed" and "fixed for you".

What Brotli Is

Brotli is a compression format from Google. Web servers and browsers use it to make responses smaller. When your server or client receives Brotli-compressed data, a piece of code called the decoder unpacks it.

That decoder is the part with the bug. According to The Hacker News, crafted compressed data can make it write past the end of a buffer. The result can be a crash, a memory leak or, in the worst case, attacker-controlled code running. One analysis describes the mechanism as the decoder treating an invalid block switch as a request for more input and then continuing to add bytes to an eight-byte internal buffer.

The Timeline

• 27 February 2026: The change that closes the flaw was added to Brotli's source code. The Hacker News reports that at the time its security impact wasn't recognised.
• Between February and October: No new Brotli release carried that change.
• 21 October: The flaw was disclosed. Node.js and Google shipped fixes.
• 25 October: Microsoft released emergency .NET updates.

OpenAI's Codex Security team reported the bug. Node.js credits two of its researchers, Khai Tran and Sylvie Mayer. OpenAI said the issue "was actually fixed in the Brotli source code in February", but the fix wasn't known to be a security fix and no newer release followed.

Why a Source Fix Isn't Enough

A commit in a repository helps the people who build from the latest source. It does nothing for the many projects that take Brotli from an official release, or that bundle their own copy inside their product.

An analysis on remio.ai puts it plainly: a source change is a development record, a release packages it for users, and a running deployment is a further stage. Each step needs separate evidence. Embedded copies may not be replaced by a system library update. Container images and background services can keep the old version alive long after a fix exists somewhere else.

In other words, "it's been fixed" was true for months, and it didn't help anyone who got Brotli the usual way.

Why One Library Means Many Patches

Because many products bundle their own copy of the decoder, each one has to be patched separately. The Hacker News lists the fixed versions:

Product Fixed in Google Brotli ©, affected 1.0.3 to 1.2.0 1.0.10, 1.1.1, 1.2.1 Node.js 22.23.4, 24.22.1, 26.12.1 Bun (1.4.3 and earlier affected) 1.4.4 .NET 8.0.33, 9.0.22, 10.0.14, 11.0 RC3 Python brotli / brotlicffi 1.2.1 / 1.2.1.0 Envoy and Istio several 1.x patch releases

Node.js 20 and older are end-of-life, and no fix is listed for them. JFrog also reports that FFmpeg, ClickHouse and Apache Arrow are affected.

How Serious Is It?

Scores vary. Google rates it 9.2 out of 10 on CVSS 4.0, while Red Hat and Microsoft give it 8.1. Node.js calls it "high".

On exploitation, the picture is calm so far. CISA's 23 October assessment listed no exploitation, and Red Hat says no reliable public proof of concept for code execution exists. Imperva's red team did run code on an unmodified Node.js build for Linux on ARM64, but that exploit is unreleased and was tested only on that build.

For scale, Wiz data quoted by The Register says 91% of cloud environments have vulnerable resources, and 82% have publicly exposed Node.js instances. That says how common the library is, not how many are exploitable.

Also, the decoder has to process data an attacker can influence. Having Brotli in your app doesn't by itself mean you're exposed. .NET, for example, doesn't turn on Brotli request or response decompression by default.

What to Check Today

1. List what you actually run. Node.js, Bun, .NET, Python packages, Envoy or Istio, and any service that does HTTP decompression. Compare against the fixed versions above.
2. Check Python by hand. The Hacker News says dependency scanners may not flag the Python packages yet, so run pip show brotli brotlicffi and look at the versions.
3. Restart and rebuild. Running processes keep the old decoder, so updating isn't enough until you restart. Rebuild container images too. Microsoft adds that self-contained .NET apps must be rebuilt and republished, since a newer host runtime doesn't update the one bundled with your app.
4. If you can't patch yet, reject requests with Content-Encoding: br before they are decoded, and turn off automatic Brotli decoding in HTTP clients. Removing br from Accept-Encoding doesn't help, because servers can still send it.
5. Ask about the software you don't control. Vendors that bundle Brotli have to ship their own update. The project's list at patchtheplanet.org/brotli tracks products that include it.

What to Take Away

1. "Fixed" has three stages: in the source, in a release and in your running system.
2. A fix nobody recognises as a security fix doesn't get urgency. Without a clear flag, it can sit for months.
3. Bundled copies multiply the work. One library can mean ten separate patches.
4. Updating isn't finished until you restart. Processes and containers keep what they started with.
5. Know what your software contains. You can't patch what you don't know you ship.

Wrapping Up

The fix for this bug was written in February. Nobody had to invent anything new in October. What was missing was a release and a reason to move.

That's a lesson that applies far beyond Brotli: the gap between a repository and a running server is where most of the risk lives.