CVE-2026-111497 Brotli Bug: Node2Shell Risk for VS Code, .NET and Embedded Runtimes

The underlying bug is CVE-2026-111497. It sits in Google's Brotli decompression library, which a lot of software ships its own copy of. Patching one copy does not patch the others. Here is what is known, what is still unclear, and what Windows admins and developers should do this week.

The Bug: A Decoder That Kept Writing​

CVE-2026-111497 is an out-of-bounds write in Google's Brotli C decoder. According to the Node.js project's advisory, malformed compressed input could hit an invalid block switch. The decoder treated it as "send me more input" when it should have been a permanent format error. The streaming decoder then kept adding bytes to an internal eight-byte buffer, well past its end. Node.js says the result can be memory corruption, a crash, leaked process memory, or remote code execution.

Cycode describes the trigger simply: a stream that declares a single block type and then switches blocks was not rejected, so decoding continued in an invalid state and wrote past a buffer (CWE-787, CWE-252).

The severity rating depends on who you ask:

The GitHub advisory scores network attack vector, low attack complexity, and no privileges or user interaction required. Its "attack requirements" metric is marked as present, though. In plain terms, attacker-controlled Brotli data has to actually reach a vulnerable decoder. A 9.2 score doesn't mean every machine with Brotli on it is exploitable.

Affected upstream versions, according to GitHub's advisory and Google's release listing:

• Affected: Google Brotli 1.0.3 through 1.2.0, on all platforms
• Fixed: Brotli 1.0.10, 1.1.1 and 1.2.1, all released October 21, 2026

Rescana, citing Google's CVE record, puts the affected ranges as 1.0.3 before 1.0.10, 1.1.0 before 1.1.1, and 1.2.0 before 1.2.1. Google is the CVE numbering authority for Brotli.

Section summary: This is a memory-safety bug in shared decoder code. It is dangerous when untrusted Brotli data reaches an unpatched copy, and it's mostly harmless where that can't happen.

Exploitation: Proofs of Concept Exist​

This is no longer a theoretical risk. Imperva researcher Ron Masas published an analysis that gave the bug the Node2Shell name. According to Cyber Kendra, Imperva said its proof of concept ran attacker-supplied code in applications using the official Node.js 24.22.0 Linux arm64 image, and that Node.js 24.22.1 rejected the same inputs.

Indusface reports public PoCs since October 22. Not in CISA's Known Exploited Vulnerabilities (KEV) catalog as of October 23, 2026. So the flaw is weaponizable, but nobody has confirmed exploitation in the wild. Still, public exploit code tends to cut the time defenders have to patch.

Beyond Node.js: McCarty's Inventory​

McCarty looked at developer tools and libraries in several ecosystems that implement or include Brotli decompression. He found potentially vulnerable software across Python, Go, .NET, Perl and others. His findings, as reported by iTnews:

• Already fixed, per McCarty: Chrome and Firefox (bundled Brotli copies updated), the Envoy proxy, and Unity's fork of the Mono runtime used in its game engine.
• Carrying their own Brotli decoder: Microsoft's .NET runtime, the DuckDB database, and the Pillow and pyarrow Python libraries.
• Electron desktop apps: Signal, Slack, Discord and Microsoft's Visual Studio Code each ship their own copy of the browser engine and depend on their own update mechanisms for fixes.

McCarty calls it the "Brotlipocalypse" and compares it to Log4j. He says Brotli, like Log4j, "is used everywhere," and adds that he hopes it won't be as disruptive. He also says that in OpenSourceMalware's testing, it was relatively easy to get at least denial of service, if not RCE.

Keep that comparison in proportion. It's one researcher's view of how widely Brotli is used, not a measurement of impact. Log4Shell was trivially triggerable through logged strings. Here, an attacker has to get crafted compressed data into a decoder. That is a real hurdle, but HTTP compression is the main reason Brotli exists, so the hurdle may be lower than it sounds.

These product findings come from McCarty, not from each vendor. The reporting doesn't list affected or fixed versions for most of them, including VS Code and .NET. Don't assume each named app is still unpatched today, and don't assume it's safe either.

Section summary: The flaw spreads through every product that bundles its own Brotli. That includes two Microsoft products, but their patch status isn't confirmed in the available reporting.

The February Fix Nobody Shipped​

The timeline is the most uncomfortable part of this story.

• February 27, 2026: A Brotli repository record shows a pull request titled "Detect and report invalid stream earlier." iTnews says Google engineer Evgenii Kliuchnikov wrote the fix, and its description said nothing about security.
• October 21, 2026: Node.js ships security releases, and Google publishes Brotli 1.0.10, 1.1.1 and 1.2.1, now labeled as the security fix for CVE-2026-111497.
• October 22, 2026: The CVE and the GitHub Advisory Database entry are published.
• October 23, 2026: Bun publishes its own advisory.

Aikido sums up the problem: The root cause was fixed in the Brotli source code in February, but it wasn't recognized as a security issue at the time and no release shipped with the fix until now. That means every project that bundles Brotli has to ship its own update. Node.js fixed its copy the same way. Aikido says Node.js cherry-picked (Brotli commit 0ed4268a from February).

For about eight months, the fix was public in the repository, but anyone shipping tagged releases kept shipping the vulnerable decoder. It's a common supply-chain blind spot: a fix that isn't labeled as security doesn't go out as one.

A note on credits: the Node.js advisory credits Khai Tran and Sylvie Mayer of OpenAI Codex Security with reporting the flaw, and Matteo Collina and Antoine du Hamel with fixing it. Some secondary coverage gives a different split. The Node.js advisory is the primary source.

Patch Targets You Can Verify Today​

Three details are easy to miss:

• End-of-life Node.js gets no fix. HeroDevs says every earlier release on those lines is affected, as is every end-of-life line from 25.x back to 12.x. If you're still on Node 20 or 18, the only open-source fix is moving to a supported line.
• The npm brotli package is unrelated. HeroDevs notes that the vulnerable code is compiled into the Node.js runtime under deps/brotli; the npm package named brotli is unrelated. Only a fixed runtime build removes the flaw.
• Python HTTP clients can pick up Brotli without you asking. Aikido warns you're exposed with Brotli 1.2.0 or earlier, or brotlicffi 1.2.0.x, installed, since HTTP clients such as requests, httpx, and aiohttp load these packages automatically when they're present.

Your Action Plan​

1. Find every copy, not just the obvious ones. Check SBOMs, lockfiles, container images and vendor release notes. The product name often won't tell you which Brotli it bundles. On a Windows dev box, a few quick checks:

• node --version should show 22.23.4, 24.22.1, 26.12.1 or later on your line
• pip show brotli brotlicffi in each virtual environment
• bun --version should show 1.4.4 or later

2. Patch through whoever maintains the embedded copy. Updating a system-wide Brotli library does nothing for an Electron app or runtime that ships its own. That applies to VS Code, Slack, Discord, Signal and .NET: update each through its own channel and check its release notes for a CVE-2026-111497 fix. Version numbers can also mislead. Linux distributions often backport fixes without changing the upstream version, so check your supplier's advisory.

3. Rebuild anything that embeds a runtime. Bun says plainly that executables built with bun build --compile stay vulnerable until rebuilt with 1.4.4. HeroDevs gives similar advice for Node: upgrade, rebuild every image and executable that embeds the runtime, and restart the processes. Your Docker base image won't fix itself.

4. Patch exposed decode paths first. HeroDevs suggests starting with services that inflate request bodies or fetch user-supplied URLs. Indusface notes that Express 5 and body-parser 2.x decompress these by default when requests carry a Brotli Content-Encoding header. That makes common Node web stacks exposed by default.

5. Use workarounds only to buy time. Bun says there's no process-wide workaround, only per-request options like turning off fetch decompression. WAF rules from vendors such as Imperva add a layer of defense, but they don't replace a patched decoder.

The Microsoft Angle​

For Windows shops, the main problem is visibility. VS Code installs are spread across developer laptops and update on their own schedule. The .NET runtime ships its own Brotli decoder, according to McCarty, which matters to any service decompressing client-supplied content. Neither iTnews nor the other evidence available includes Microsoft version numbers. Watch Microsoft's .NET servicing notes and VS Code release notes. Until vendor confirmation arrives, treat both as items to verify, not as confirmed vulnerable or confirmed safe.

The bigger lesson goes beyond Microsoft. A security fix that ships without a security label doesn't reach the people who need it. If your SBOM can't tell you where Brotli lives, it's out of date.

Update: Microsoft reportedly patches Node2Shell in .NET (October 27, 2026)​

According to NewzTodays, Microsoft has issued a security patch for CVE-2026-111497 covering .NET 8, 9, 10 and the .NET 11 Release Candidate 3. That changes the earlier picture: the available reporting had not confirmed Microsoft’s patch status or identified .NET versions.

NewzTodays also reports that Visual Studio and PowerShell components linked to those .NET versions have been updated. It says the older .NET Framework is not affected because it does not enable Brotli decompression by default.

For Windows administrators and developers, the reported update makes .NET installations and dependent components a priority for patch verification. Check Microsoft’s servicing information for the applicable fixed builds before treating a deployment as protected; the NewzTodays report does not provide build numbers.

Teams using containers should also rebuild their images with the updated components and redeploy them. The reported Visual Studio update does not establish a patch status for Visual Studio Code, which remains a separate item to verify.