Node2Shell: closing the Brotli flaw CVE-2026-111497 in Node.js, Python and .NET

On 21 October 2026 Node.js fixed a flaw in the Brotli decoder it ships with. It is now clear that the bug lives in Google's Brotli library itself and reaches far beyond Node.js, into Python packages, .NET, Bun, Envoy and the packages of Linux distributions. Whether you are affected depends less on a version number than on whether your software decompresses Brotli data from an untrusted source. This article shows where that happens, which versions are safe and how to check your systems with tested one-liners.

What happened?

The bug is old; the disclosure was quick. According to Aikido, OpenAI found it as early as February 2026, and the fix landed in the public Brotli repository back then without being labelled a security fix. Projects that bundle their own copy of the Brotli code therefore never picked it up. Node.js credits the OpenAI Codex Security team (Khai Tran and Sylvie Mayer) with the report; Matteo Collina and Antoine du Hamel built the fix.

• February 2026: the fix lands in the Brotli source code without a security label.
• 21 October: Node.js releases 22.23.4, 24.22.1 and 26.12.1 with ten security fixes, this one among them. Google releases Brotli 1.0.10, 1.1.1 and 1.2.1. Vercel deploys WAF rules, and the official Node.js Docker images are updated.
• 22 October: NVD publishes CVE-2026-111497 and GitHub publishes advisory GHSA-9v8h-qqgm-4m35; Brotli 1.2.1 reaches PyPI. Imperva demonstrates code execution on the official Node.js 24.22.0 image (Linux, arm64) and withholds the exploit. A first public proof of concept achieves code execution only against a deliberately weakened build. Bun 1.4.4 ships.
• 23 October: brotlicffi 1.2.1.0 ships, and the Python packages get their own advisories (PYSEC-2026-4322 and PYSEC-2026-4323). Envoy and Istio release fixes.
• 24 October: the Ruby gem 0.9.1, the PHP extension 0.21.1 and brotli4j 1.24.0 for Java follow; Amazon Linux 2023 publishes ALAS2023-2026-3334.
• 25 October: Microsoft ships out-of-band .NET 8.0.33, 9.0.22 and 10.0.14 plus .NET 11 RC3 and, according to SecurityWeek, updates for Visual Studio 2019, 2022 and 2026 and for PowerShell 7.4 to 7.6.
• 26 October: Ubuntu publishes USN-8956-1 for 22.04 to 26.10; Debian has fixed packages with DSA-6582-1 (trixie) and DLA-4855-1 (bookworm).

The flaw in plain terms

Brotli compresses data in blocks, and a stream may switch between block types. The function DecodeBlockTypeAndLength() in c/dec/decode.c used to report nothing more than "worked" or "didn't work". The second answer could mean two things: the input hasn't fully arrived yet, or the stream asks for a switch that cannot exist, for example in a category with only one block type.

The streaming decoder treated both as "needs more input" and kept appending bytes to an eight-byte internal buffer, past its end. The fast path ignored the result altogether and carried on decoding from an impossible state. A crafted stream thus overwrites the decoder's adjacent state. The fix introduces a dedicated error code, BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH (-17), which every caller now returns. In formal terms these are two weaknesses: an unchecked return value (CWE-252) and an out-of-bounds write (CWE-787).

Three paths to the decoder

An affected Brotli version on disk is not yet an attack. It becomes dangerous once data from an untrusted source reaches the decoder, and there are three ways for that to happen:

Inbound: the server decompresses requests

A client sends a body with Content-Encoding: br, and the application decompresses it before processing. Express 5.0.0 to 5.3.0 and body-parser 2.0.0 to 2.3.0 do this with json(), raw(), text() and urlencoded(), as does ASP.NET Core with request decompression enabled for br and Python frameworks with matching middleware. A bare node:http server decompresses nothing by itself, and Express 4 and body-parser 1.x don't support Brotli request bodies. In .NET, request decompression is off by default.

Outbound: the application fetches foreign content

The application fetches a URL and decompresses the response automatically. Node.js's fetch() does so without any extra setting; urllib3, and therefore requests, as well as aiohttp and httpx do so as soon as the Python package Brotli or brotlicffi is installed; in .NET it is HttpClient when AutomaticDecompression includes Brotli or All. Typical triggers are webhooks, link previews, crawlers, "import from URL" features and AI agents that read web pages. A web application firewall in front of your server never sees these responses. Dropping br from Accept-Encoding helps little, because a malicious server sends Brotli anyway.

Direct: your own code decompresses data

Code that runs zlib.brotliDecompress(), brotli.decompress() or BrotliStream on files, caches or messages from a queue is affected as soon as that data does not come from a trusted source.

Who is affected?

Any software that loads or bundles the C decoder of Brotli 1.0.3 to 1.2.0 is affected. The most important cases as of 26 October 2026:

Safe versions

Fixed versions of the system library and the runtimes as of 26 October 2026. Compare them with the package version from your source:

1.Take stock

Start with the systems that fetch foreign URLs or accept compressed requests. Each of the following commands prints a finished result, OK, VULNERABLE or a hint per finding. We tested all of them against real images; an older node:22-alpine, for instance, reported v22.23.3 VULNERABLE.

node -e 'const v=process.versions.node.split(".").map(Number),f={22:[23,4],24:[22,1],26:[12,1]}[v[0]];console.log(process.version,!f?"NO FIX (end of life)":(v[1]>f[0]||(v[1]==f[0]&&v[2]>=f[1]))?"OK":"VULNERABLE")'

# same check inside an image: docker run --rm --entrypoint node <image> -e '...'

python3 - <<'EOF'
from importlib.metadata import version, PackageNotFoundError
fixed = {"Brotli": (1, 2, 1), "brotlicffi": (1, 2, 1, 0)}
for name, good in fixed.items():
    try:
        v = version(name)
    except PackageNotFoundError:
        print(name, "not installed")
        continue
    parts = tuple(int(p) for p in v.split(".")[:len(good)] if p.isdigit())
    print(name, v, "OK" if parts >= good else "VULNERABLE")
EOF

# inside a container: docker exec -i <container> python3 - <<'EOF' ... EOF

On Debian and Ubuntu, check the system library against the fixed version for your release from the table, here for Debian 12. The second command counts the processes that still hold a replaced libbrotlidec in memory; 0 means everything has been reloaded:

dpkg-query -W -f='${db:Status-Abbrev} ${Package} ${Version}\n' 'libbrotli1*' 2>/dev/null \
  | awk '$1=="ii"{r=system("dpkg --compare-versions "$3" ge 1.0.9-2+deb12u1"); print $2, $3, (r==0?"OK":"VULNERABLE")}'

sudo grep -ls 'libbrotlidec.*(deleted)' /proc/[0-9]*/maps 2>/dev/null | wc -l

For .NET, what counts is the shared runtime Microsoft.NETCore.App, which an ASP.NET Core application under IIS loads too. On Windows and Linux:

$fix = @{8=33; 9=22; 10=14}; dotnet --list-runtimes | ForEach-Object { if ($_ -match '^Microsoft\.NETCore\.App (\d+)\.(\d+)\.(\d+)') { $maj = [int]$Matches[1]; $p = [int]$Matches[3]; $s = if ($maj -lt 8) { 'NO FIX (end of life)' } elseif (-not $fix.ContainsKey($maj)) { 'CHECK' } elseif ($p -ge $fix[$maj]) { 'OK' } else { 'VULNERABLE' }; "Microsoft.NETCore.App $($Matches[1]).$($Matches[2]).$p $s" } }

dotnet --list-runtimes | awk '$1=="Microsoft.NETCore.App"{split($2,v,".");f=(v[1]==8?33:v[1]==9?22:v[1]==10?14:-1);print $1,$2,(v[1]<8?"NO FIX (end of life)":f<0?"CHECK":(v[3]+0>=f?"OK":"VULNERABLE"))}'

A search of the source code shows whether your own code decompresses untrusted Brotli data. A hit is not a vulnerability, just the place to look first:

# .NET: request decompression, HttpClient decompression, direct decoder use
grep -rnE --include='*.cs' 'AddRequestDecompression|DecompressionMethods\.(All|Brotli)|BrotliStream|BrotliDecoder' .

# Node.js: direct decoder calls, and Express 5 / body-parser 2 in the dependency tree
grep -rnE --include='*.js' --include='*.ts' --exclude-dir=node_modules 'brotliDecompress|createBrotliDecompress' .
npm ls express body-parser --all 2>/dev/null | grep -cE 'express@5|body-parser@2'

2.Patch, restart, rebuild

The order is always the same: update, restart running processes, rebuild images. Skip the second or third step and the old decoder stays in production.

sudo apt update
sudo apt install --only-upgrade libbrotli1 brotli python3-brotli   # skips what is not installed

# restart the services that still map the old library, until this prints 0
sudo grep -ls 'libbrotlidec.*(deleted)' /proc/[0-9]*/maps 2>/dev/null | wc -l

python3 -m pip install -U "Brotli>=1.2.1"
python3 -m pip install -U "brotlicffi>=1.2.1.0"

# then regenerate lockfiles (requirements.txt, poetry.lock, uv.lock) and rebuild images

• Node.js: move to 22.23.4, 24.22.1 or 26.12.1 and restart every Node.js process. Switch images that point at a fixed tag such as node:24.22.0 to the fixed tag and rebuild them; the same goes for single executable applications and startup snapshots. Node.js 20, 21, 23 and 25 get no fix: move to 22 or 24.
• .NET under IIS: install the Hosting Bundle or runtime 8.0.33, 9.0.22 or 10.0.14 and restart the application pools, for example with Restart-WebAppPool -Name <pool> or iisreset. Republish self-contained applications with the updated SDK; with NativeAOT, updating the runtime on the server does not replace the decoder linked into the executable.
• .NET in containers: pull the images from mcr.microsoft.com/dotnet again and rebuild the application.
• Containers in general: an update on the host never reaches the image. Rebuild and redeploy every image with its own runtime or its own libbrotli on a patched base; where images are pinned by digest, move the pin deliberately.

3.Stopgaps until you can patch

Until the update is live, blocks in two places help. They do not replace the update, as Microsoft and Imperva both stress. Test every block, because it changes how requests and responses are handled.

Inbound: reject Brotli bodies at the proxy

# nginx (server or location block): reject Brotli request bodies before the app decodes them
if ($http_content_encoding ~* "br") { return 415; }

# HAProxy (frontend)
http-request deny deny_status 415 if { req.hdr(content-encoding) -m sub -i br }

<system.webServer>
  <security>
    <requestFiltering>
      <filteringRules>
        <!-- CVE-2026-111497: reject Brotli request bodies, logged as 404.19 -->
        <filteringRule name="Block Brotli request bodies" scanUrl="false" scanQueryString="false" scanAllRaw="false">
          <scanHeaders>
            <add requestHeader="Content-Encoding" />
          </scanHeaders>
          <denyStrings>
            <add string="br" />
          </denyStrings>
        </filteringRule>
      </filteringRules>
    </requestFiltering>
  </security>
</system.webServer>

In the application: remove Brotli from existing configuration

Microsoft advises removing Brotli only where decompression is already switched on, and not adding new decompression features:

// only where AddRequestDecompression is already configured
builder.Services.AddRequestDecompression(options =>
{
    // CVE-2026-111497: stop decoding Brotli request bodies until the runtime is patched
    options.DecompressionProviders.Remove("br");
});

// HttpClient: was DecompressionMethods.All, drop Brotli until patched
var handler = new SocketsHttpHandler
{
    AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate
};

• Python: run python3 -m pip uninstall -y Brotli brotlicffi, remove extras such as httpx[brotli] and regenerate the lockfiles. requests, aiohttp and httpx then fall back to gzip and deflate. Other bundled Brotli copies are not affected by this.
• Node.js: there is no workaround for responses to fetch(), only the update. For inbound traffic the proxy block helps.
• curl: remove --compressed from scripts and .curlrc; curl -V shows whether curl was built with Brotli.
• Envoy and Istio: remove the Brotli decompressor filter until the proxies are updated.
• Limit outbound fetches: let services that load foreign URLs reach the internet only through an egress allow list. That cuts the risk for webhooks, previews and AI agents considerably.

4.Recognising attacks

An attack along the outbound path leaves no trace in your access logs, because the malicious response comes from the foreign server. Only logs of outbound connections and the service's crash reports help there. The traces at a glance:

Frequently asked questions

Sources

External sources, as of 26 October 2026 (open in a new tab):

• Node.js, October 2026 Security Releases
• NVD, CVE-2026-111497
• CVE.org, CVE-2026-111497
• GitHub Advisory Database, GHSA-9v8h-qqgm-4m35
• Google Brotli, release 1.2.1
• Google Brotli, commit 0ed4268
• Microsoft, security advisory CVE-2026-111497 for .NET
• .NET Blog, out-of-band updates of 25 October 2026
• Imperva, Node2Shell: From Brotli Data to Remote Code Execution
• Aikido, Python packages and further ecosystems
• OpenSourceMalware, Node2Shell affects Python
• Hadrian, What we know about the Node.js Brotli RCE
• broccoli2shell.com, overview of affected projects
• OSV, PYSEC-2026-4322 (Brotli)
• Ubuntu, USN-8956-1
• Debian Security Tracker, CVE-2026-111497
• Red Hat, CVE-2026-111497
• Amazon Linux, ALAS2023-2026-3334
• Vercel, Node.js security advisory
• SecurityWeek, patches across Microsoft, Node.js and Python
• Microsoft Learn, IIS request filtering rules

This article is for general information and does not replace a case-by-case assessment. Versions and commands refer to the stated date and need adapting to your environment. As of October 2026.