Broccoli2Shell: The One Decoder We All Depend On

TL;DR - CVE-2026-111497 is an out-of-bounds write in the Brotli decompressor in google/brotli, fixed upstream in 1.2.1. It is not a separate Node, PHP, or npm bug. It is one C decoder that has been copied into runtimes, databases, document readers, image libraries, language bindings, and prebuilt native packages. And while originally reported as Node2Shell, this CVE impacts far more than just Node. In this post we go into detail on all the copies that you may have missed if you stopped reading after “Node.”

CVE-2026-111497 is a Heap out-of-bounds write in Google's Brotli C decoder. Brotli is a compression algorithm that’s commonly used in HTTP applications and the vulnerable component is called when an attacker supplies a malformed Brotli stream. The decoder can treat an invalid block switch as incomplete input, continue with stale state, and write past the memory it owns.

That can mean a crash, memory disclosure, or memory corruption that may be useful for code execution, depending on the wrapper and the process around it. The bug is in the shared decoder, not in Node.js, Python, PHP, or npm itself. But how the decoder is handled and implemented changes how the vulnerability is actually patched and remediated.

The upstream 0ed4268a fix is in Brotli 1.2.1. The important change is that invalid block-switch state now returns a real decoder error instead of being treated as “need more input.” It’s a fairly simple fix, but prior to AI, it would need a skilled researcher familiar with C code and the Brotli compression decoder, which is probably why no one picked it up in Brotli 1.0.3 when it was introduced.

Node2Shell covered the Node.js attack paths. But Node is only one example. The underlying issue is the vulnerable decoder in Google’s C Brotli library.

That decoder has been copied into runtimes, browsers, databases, proxies, document tools, image libraries, and language bindings. It may be hidden inside a native library, wheel, DLL, addon, static binary, or transitive dependency. Updating one package does not update every copy in the application.

The patch is small. The difficult part is finding each bundled copy and confirming whether untrusted Brotli data can reach it.

Depending on the project, fixing it may mean:

Publishing new Python wheels or native packages

Rebuilding Chromium, DuckDB, Envoy, .NET, or another larger artifact;

Adapting the fix to a language-specific port

Sometimes it is a dependency update. Sometimes it requires a vendor release or a complete rebuild, so the just patch narrative can be complicated and not simple.

There will not be one neat package list for CVE-2026-111497. Broccoli2Shell is a useful resource, but each vendor will also identify packages that are not covered by the main public lists.

Using Semgrep? A post on how it fits into your CVE-2026-111497 response is on the way.

The full scope will be difficult to track. Some projects are already patching silently, without publishing an advisory, and new affected packages will continue to appear across programming-language ecosystems and bundled native components.

Below, we list packages we have confirmed so far, along with recommendations for cases where an immediate upgrade is not available.

In this list we’ve compiled packages or runtimes that specifically ship Brotli inside of them. Patches are typically available for that component if you just update to the version listed below, and you can easily do these updates as you would any other patch.

libbrotli / distro brotli packages (source)

8.0 before 8.0.33; 9.0 before 9.0.22; 10.0 before 10.0.14; .NET 11 before RC3

1.29.0–1.29.8, 1.30.0–1.30.5, 1.31.0–1.31.1

Some packages ship Brotli inside their own binary instead of using the system library. Many of these remain unfixed because either the package itself must be updated or rebuilt from source with the Brotli fixes included. Updating a top-level Brotli dependency will not patch those copies.

Bundled native Brotli C decoder in the native-* Maven JARs, loaded through JNI.

Vendored Brotli source under vendor/brotli, with an optional system-library path.

Rust implementation of the Brotli decompressor, with optional C-compatible FFI.

Precompiled Python wheels bundle libcurl-impersonate with Brotli 1.1.0 statically linked.

No fix yet "main fixed (PR https://github.com/python-pillow/Pillow/pull/10340) ; release pending

wheels ship libbrotlidec (FreeType WOFF2)

wheels ship libbrotlidec 1.2.0 (Brotli codec, JPEG XL)

wheels ship libbrotlidec 1.0.9 (FreeType WOFF2)

wheels ship libbrotlidec 1.2.0 (FreeType WOFF2)

Magick.NET (NuGet, all Magick.NET-*  variants)

native Brotli; used by Parquet.Net 4.x/5.x

no fix (open issue https://github.com/XieJJ99/brotli.net/issues/28)

prebuilt binaries statically link libcurl + Brotli

@ladybugdb/core and its platform packages (npm)

prebuilt native addon; vendored Brotli 1.1.0

prebuilt native addon; vendored Brotli 1.1.0

LadybugDB.Native.* (NuGet: linux-x64, linux-arm64, osx-x64, osx-arm64, win-x64)

We will continue to add to this list, and for packages which are directly included in your first party code, we will include the relevant Semgrep Supply Chain rules to help pinpoint locations you are using insecure versions of a library.

Semgrep Supply Chain showing four reachable findings for the Brotli advisory: two from direct dependencies and two from transitive ones.