Node2Shell: die Brotli-Lücke CVE-2026-111497 in Node.js, Python und .NET schließen

Am 21. Oktober 2026 hat Node.js eine Lücke im mitgelieferten Brotli-Decoder geschlossen. Inzwischen ist klar, dass der Fehler in Googles Brotli-Bibliothek selbst sitzt und weit über Node.js hinausreicht: bis zu Python-Paketen, .NET, Bun, Envoy und den Paketen der Linux-Distributionen. Ob Sie betroffen sind, entscheidet nicht die Versionsnummer allein, sondern ob Ihre Software Brotli-Daten aus fremder Hand entpackt. Dieser Beitrag zeigt, wo das passiert, welche Stände sicher sind und wie Sie Ihre Systeme mit getesteten Einzeilern prüfen.

Was ist passiert?

Der Fehler ist alt, die Veröffentlichung kam schnell. Nach Angaben von Aikido fand OpenAI die Lücke bereits im Februar 2026; die Korrektur landete damals im öffentlichen Brotli-Repository, ohne als Sicherheitsfix gekennzeichnet zu sein. Projekte mit eigener Kopie des Brotli-Codes haben sie deshalb nicht übernommen. Node.js nennt als Melder das Team OpenAI Codex Security (Khai Tran und Sylvie Mayer), den Fix haben Matteo Collina und Antoine du Hamel eingebaut.

• Februar 2026: Die Korrektur landet im Brotli-Quellcode, ohne Sicherheitskennzeichnung.
• 21.10.: Node.js veröffentlicht 22.23.4, 24.22.1 und 26.12.1 mit zehn Sicherheitskorrekturen, darunter diese. Google veröffentlicht Brotli 1.0.10, 1.1.1 und 1.2.1. Vercel schaltet WAF-Regeln, die offiziellen Node.js-Docker-Images werden aktualisiert.
• 22.10.: Die NVD veröffentlicht CVE-2026-111497, GitHub den Hinweis GHSA-9v8h-qqgm-4m35; Brotli 1.2.1 erscheint auf PyPI. Imperva zeigt Codeausführung auf dem offiziellen Image von Node.js 24.22.0 (Linux, arm64) und hält den Exploit zurück. Ein erster öffentlicher Proof of Concept erreicht Codeausführung nur gegen einen absichtlich geschwächten Build. Bun 1.4.4 erscheint.
• 23.10.: brotlicffi 1.2.1.0 erscheint, die Python-Pakete erhalten eigene Hinweise (PYSEC-2026-4322 und PYSEC-2026-4323). Envoy und Istio liefern Korrekturen.
• 24.10.: Es folgen das Ruby-Gem 0.9.1, die PHP-Erweiterung 0.21.1 und brotli4j 1.24.0 für Java; Amazon Linux 2023 veröffentlicht ALAS2023-2026-3334.
• 25.10.: Microsoft liefert außerplanmäßig .NET 8.0.33, 9.0.22 und 10.0.14 sowie .NET 11 RC3, laut SecurityWeek auch Updates für Visual Studio 2019, 2022 und 2026 sowie PowerShell 7.4 bis 7.6.
• 26.10.: Ubuntu veröffentlicht USN-8956-1 für 22.04 bis 26.10; Debian hat mit DSA-6582-1 (trixie) und DLA-4855-1 (bookworm) korrigierte Pakete.

Die Lücke verständlich erklärt

Brotli komprimiert Daten in Blöcken und der Datenstrom darf zwischen Blocktypen wechseln. Die Funktion DecodeBlockTypeAndLength() in c/dec/decode.c meldete bisher nur „hat geklappt“ oder „hat nicht geklappt“. Das zweite konnte zweierlei heißen: Die Eingabe ist noch nicht vollständig da, oder der Strom verlangt einen Wechsel, den es nicht geben kann, etwa in einer Kategorie mit nur einem Blocktyp.

Der streamende Decoder hielt beides für „mehr Eingabe nötig“ und hängte weitere Bytes an einen internen Puffer von acht Byte an, auch über dessen Ende hinaus. Der schnelle Pfad ignorierte die Rückmeldung ganz und decodierte aus einem unmöglichen Zustand weiter. Ein präparierter Datenstrom überschreibt so den benachbarten Zustand des Decoders. Die Korrektur führt einen eigenen Fehlercode ein, BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH (-17), den jeder Aufrufer zurückgibt. Fachlich sind das zwei Schwächen: eine ungeprüfte Rückgabe (CWE-252) und ein Schreiben außerhalb eines Puffers (CWE-787).

Drei Wege zum Decoder

Eine betroffene Brotli-Version auf der Platte ist noch kein Angriff. Gefährlich wird sie, wenn Daten aus fremder Hand den Decoder erreichen. Das geht auf drei Wegen:

Eingehend: der Server entpackt Anfragen

Ein Client schickt einen Body mit Content-Encoding: br und die Anwendung entpackt ihn vor der Verarbeitung. Das tun Express 5.0.0 bis 5.3.0 bzw. body-parser 2.0.0 bis 2.3.0 mit json(), raw(), text() und urlencoded(), ASP.NET Core mit eingeschalteter Request-Decompression für br sowie Python-Frameworks mit entsprechender Middleware. Ein nackter node:http-Server entpackt nichts von selbst; Express 4 und body-parser 1.x kennen Brotli für Anfragen nicht. In .NET ist die Request-Decompression ab Werk aus.

Ausgehend: die Anwendung lädt fremde Inhalte

Die Anwendung ruft eine URL ab und entpackt die Antwort automatisch. Das fetch() von Node.js tut das ohne weiteres Zutun; urllib3 und damit requests sowie aiohttp und httpx tun es, sobald das Python-Paket Brotli oder brotlicffi installiert ist; in .NET der HttpClient, wenn AutomaticDecompression Brotli oder All enthält. Typische Auslöser sind Webhooks, Link-Vorschauen, Crawler, „Import von URL“ und KI-Agenten, die Webseiten lesen. Eine Web Application Firewall vor Ihrem Server sieht diese Antworten nicht. br aus dem Accept-Encoding zu streichen hilft wenig, denn ein böswilliger Server schickt Brotli trotzdem.

Direkt: eigener Code entpackt Daten

Code, der zlib.brotliDecompress(), brotli.decompress() oder BrotliStream auf Dateien, Caches oder Nachrichten aus einer Warteschlange anwendet, ist betroffen, sobald diese Daten nicht aus vertrauenswürdiger Quelle stammen.

Wer ist betroffen?

Betroffen ist jede Software, die den C-Decoder von Brotli 1.0.3 bis 1.2.0 lädt oder mitbringt. Die wichtigsten Fälle, Stand 26. Oktober 2026:

Sichere Versionen

Die Fixstände der Systembibliothek und der Laufzeiten, Stand 26. Oktober 2026. Vergleichen Sie mit der Paketversion Ihrer Quelle:

1.Bestand prüfen

Beginnen Sie mit den Systemen, die fremde URLs abrufen oder komprimierte Anfragen annehmen. Jeder der folgenden Befehle gibt ein fertiges Ergebnis aus, je Fundstelle OK, VULNERABLE oder einen Hinweis. Wir haben alle gegen echte Images getestet; ein älteres node:22-alpine meldete etwa 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

Die Systembibliothek prüfen Sie auf Debian und Ubuntu gegen den Fixstand Ihrer Version aus der Tabelle, hier für Debian 12. Der zweite Befehl zählt die Prozesse, die noch eine ersetzte libbrotlidec im Speicher halten; bei 0 ist alles neu geladen:

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

Für .NET zählt die gemeinsame Laufzeit Microsoft.NETCore.App, die auch eine ASP.NET-Core-Anwendung unter IIS lädt. Unter Windows und 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"))}'

Ob Ihr eigener Code Brotli aus fremder Hand entpackt, zeigt eine Suche im Quelltext. Treffer sind keine Lücke, sondern die Stellen, die Sie zuerst ansehen:

# .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.Patchen, neu starten, neu bauen

Die Reihenfolge ist immer dieselbe: aktualisieren, laufende Prozesse neu starten, Images neu bauen. Wer den zweiten oder dritten Schritt auslässt, hat den alten Decoder weiter im Betrieb.

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: auf 22.23.4, 24.22.1 oder 26.12.1 wechseln, alle Node.js-Prozesse neu starten. Images, die auf einen festen Tag wie node:24.22.0 zeigen, auf den korrigierten Tag umstellen und neu bauen; das gilt auch für Single Executable Applications und Startup-Snapshots. Node.js 20, 21, 23 und 25 bekommen keinen Fix: auf 22 oder 24 wechseln.
• .NET unter IIS: das Hosting Bundle bzw. die Laufzeit 8.0.33, 9.0.22 oder 10.0.14 installieren und die Anwendungspools neu starten, etwa mit Restart-WebAppPool -Name <pool> oder iisreset. Self-contained Anwendungen mit dem aktualisierten SDK neu veröffentlichen; bei NativeAOT ersetzt ein Update der Laufzeit auf dem Server den eingebauten Decoder nicht.
• .NET in Containern: die Images von mcr.microsoft.com/dotnet neu ziehen und die Anwendung neu bauen.
• Container allgemein: Ein Update auf dem Host erreicht das Image nicht. Jedes Image mit eigener Laufzeit oder eigenem libbrotli auf gepatchter Basis neu bauen und neu ausrollen; bei Images mit fester Digest-Pinnung den Pin bewusst nachziehen.

3.Notbehelf bis zum Patch

Bis das Update läuft, helfen Sperren an zwei Stellen. Sie ersetzen das Update nicht; Microsoft und Imperva betonen das ausdrücklich. Testen Sie jede Sperre, denn sie verändert die Behandlung von Anfragen und Antworten.

Eingehend: Brotli-Bodies am Proxy ablehnen

# 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 der Anwendung: Brotli aus bestehender Konfiguration entfernen

Microsoft empfiehlt, Brotli nur dort zu entfernen, wo die Dekomprimierung bereits eingeschaltet ist, und keine neuen Dekomprimierungsfunktionen hinzuzufügen:

// 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: python3 -m pip uninstall -y Brotli brotlicffi und Extras wie httpx[brotli] entfernen, danach die Lockfiles neu erzeugen. requests, aiohttp und httpx fallen dann auf gzip und deflate zurück. Andere mitgelieferte Brotli-Kopien bleiben davon unberührt.
• Node.js: Für Antworten auf fetch() gibt es keinen Notbehelf, nur das Update. Eingehend hilft die Sperre am Proxy.
• curl: --compressed aus Skripten und .curlrc entfernen; curl -V zeigt, ob curl mit Brotli gebaut ist.
• Envoy und Istio: den Brotli-Decompressor-Filter entfernen, bis die Proxys aktualisiert sind.
• Ausgehende Abrufe begrenzen: Dienste, die fremde URLs laden, nur über eine Egress-Freigabeliste ins Internet lassen. Das senkt das Risiko für Webhooks, Vorschauen und KI-Agenten deutlich.

4.Woran man Angriffe erkennt

Ein Angriff über den ausgehenden Weg hinterlässt in Ihren Zugriffs-Logs keine Spur, denn die schädliche Antwort kommt vom fremden Server. Hier helfen nur Logs der ausgehenden Verbindungen und die Absturzmeldungen des Dienstes. Die Spuren im Überblick:

Häufige Fragen

Quellen

Externe Quellen, Stand 26. Oktober 2026 (öffnen in einem neuen 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 für .NET
• .NET Blog, Out-of-Band-Updates vom 25. Oktober 2026
• Imperva, Node2Shell: From Brotli Data to Remote Code Execution
• Aikido, Python-Pakete und weitere Ökosysteme
• OpenSourceMalware, Node2Shell betrifft Python
• Hadrian, What we know about the Node.js Brotli RCE
• broccoli2shell.com, Übersicht betroffener Projekte
• 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 bei Microsoft, Node.js und Python
• Microsoft Learn, IIS Request Filtering Rules

Dieser Beitrag dient der allgemeinen Information und ersetzt keine Prüfung im Einzelfall. Versionsstände und Befehle beziehen sich auf den genannten Stand und sind an Ihre Umgebung anzupassen. Stand: Oktober 2026.