Brotli-Lücke CVE-2026-111497: Node.js, Python und .NET betroffen, was jetzt neu gebaut werden muss
Am 21. Oktober haben Node.js und Google Fixes für einen Fehler im Brotli-Decoder veröffentlicht. Er trägt die Kennung CVE-2026-111497, heise nennt einen CVSS-4-Wert von 9.2. Seit dem 25. Oktober gibt es auch Updates für .NET. Der Fehler ist ein Pufferüberlauf, und öffentliche Beispielcodes existieren. heise und BleepingComputer berichten übereinstimmend, dass bisher keine Angriffe im Netz bekannt sind. Die Lücke läuft auch unter den Namen Node2Shell, HTTP2Shell und Broccoli2Shell.
Dieser Beitrag beruht auf den Berichten von heise und BleepingComputer, dem Sicherheitshinweis des Node.js-Projekts und eigenen Messungen am 26. Oktober. Was wir selbst gemessen haben, steht als gemessen dabei, alles andere ist die Angabe der Quellen.
Was der Fehler macht
Der Decoder meldet einen ungültigen Blockwechsel als vorübergehenden Bedarf an weiteren Eingabedaten und nicht als dauerhaften Formatfehler. Das Node.js-Projekt beschreibt die Folge: Der Streaming-Decoder hängt weiter Bytes an einen internen Puffer von acht Byte an und schreibt über dessen Ende hinaus. Das kann den Prozess zum Absturz bringen, Speicherinhalt preisgeben oder Code ausführen. Imperva hat laut heise Codeausführung auf einem unveränderten Node.js-Build erreicht, allerdings erst nach mehreren Versuchen.
Gefunden haben den Fehler laut dem Node.js-Hinweis OpenAI Codex Security (Khai Tran) und Sylvie Mayer. Nach Angaben von Aikido, die heise wiedergibt, lag der Fix im Quellcode seit Februar vor, wurde damals aber nicht als Sicherheitsfix behandelt. Ein Release folgte erst jetzt.
Zwei Wege zum Opfer
Ein Angreifer kann komprimierte Daten direkt an einen Server schicken, der Brotli entpackt. Er kann auch eine manipulierte Antwort ausliefern, wenn eine Anwendung eine von ihm kontrollierte URL abruft. Der zweite Weg betrifft jeden Dienst, der Webhooks, Vorschauen, Importe oder Abrufe durch Agenten macht. Wer nur eingehende Brotli-Anfragen am Proxy sperrt, schließt den ersten Weg und lässt den zweiten offen (BleepingComputer).
Apache und Nginx entpacken Brotli in der Standardkonfiguration nicht und sind dort laut heise weniger gefährdet. Das gilt nur für diese beiden und nur ohne zusätzliche Module.
Betroffene Versionen und Fixes
- Brotli (Google): betroffen 1.0.3 bis 1.2.0, gefixt in 1.0.10, 1.1.1 und 1.2.1.
- Node.js: gefixt in 22.23.4, 24.22.1 und 26.12.1.
- Python:
Brotli1.2.1 undbrotlicffi1.2.1.0. Betroffen sind laut BleepingComputerurllib3[brotli],requests,httpxundaiohttp[speedups], wenn sie mit einem verwundbaren Decoder laufen. - .NET: Updates seit dem 25. Oktober. Microsoft warnt laut BleepingComputer vor einer Rechteausweitung auf nicht aktualisierten Versionen. Versionsnummern nennt keine der Quellen.
- Bun: nach Aikido betroffen, einen Fix nennt heise nicht.
- Eigene Kopien: Software, die Brotli über C-Anbindungen nutzt (Java-JNI, PHP- und Ruby-Erweiterungen, Go mit cgo), bringt den Decoder oft selbst mit.
Was wir an unseren Systemen gemessen haben
Am 26. Oktober haben wir in den laufenden Containern nachgesehen, nicht in den Build-Dateien. Die beiden Next.js-Container auf unserem Entwicklungshost, darunter der von senn-tech.com, laufen auf v24.22.1, der gefixten Version. Das Basis-Image ist laut Dockerfile auf diesen Patch-Tag und einen Digest festgelegt.
Eine Falle dabei: process.versions.brotli meldet in diesen gefixten Containern weiter 1.2.0. Die Versionsangabe der Bibliothek taugt deshalb nicht als Prüfmerkmal. Warum das so ist, steht im Node.js-Hinweis nicht. Wir vermuten, dass Node den Fix in die eigene Kopie eingespielt hat, ohne die Nummer zu ändern (abgeleitet). Entscheidend ist die Node-Version selbst.
Auf zwei unserer LiteLLM-Gateways haben wir geprüft, ob brotli oder brotlicffi in der Python-Umgebung installiert ist. Beide Module fehlen, der Python-Weg ist dort nicht offen. Ein Image-Tag wie weekly-20261026 sagt übrigens nichts über die Laufzeit darin, die Node-Version muss im Container gelesen werden.
Was jetzt zu tun ist
- Alle Dienste mit Node.js, Python-HTTP-Clients, .NET und Bun auflisten, auch Hilfsdienste und CI-Runner.
- Die Version in der laufenden Umgebung lesen:
node -vim Container,pip listfürBrotliundbrotlicffi. - Laufzeit oder Paket auf die oben genannten Versionen heben, Prozess neu starten, Image neu bauen und ausrollen. Eine aktualisierte System-Bibliothek ändert an einer mitgelieferten Kopie nichts.
- Wenn ein sofortiges Update nicht geht: Brotli in Python-Anwendungen abschalten und eingehende Brotli-komprimierte Anfragen am Proxy sperren, das empfiehlt BleepingComputer. Nach dem Node.js-Hinweis hilft außerdem, keine nicht vertrauenswürdigen Brotli-Daten an
node:zlibzu geben.
Dienste, die fremde URLs abrufen, sind über die manipulierte Antwort erreichbar, auch wenn kein Port aus dem Internet auf sie zeigt. Sie kommen beim Patchen zuerst dran.
Weiterführende Quellen
- heise: Brotli-Decoder-Lücke nicht nur in Node.js: CVSS 9.2, betroffene Software, Bun, Imperva
- BleepingComputer: HTTP2Shell Brotli vulnerability: Zeitlinie, Python-Bibliotheken, Gegenmaßnahmen
- Node.js: October 2026 Security Releases: Ursache, gefixte Versionen, Reporter
- Simple Icons: PyPI: Logo, CC0
Welche Versionen sind von CVE-2026-111497 betroffen?+
Betroffen ist der Brotli-Decoder von Google in den Versionen 1.0.3 bis 1.2.0 (heise). Gefixt ist er in 1.0.10, 1.1.1 und 1.2.1. Bei Node.js sind die Linien 22, 24 und 26 betroffen, die korrigierten Versionen sind 22.23.4, 24.22.1 und 26.12.1. Die Python-Pakete Brotli 1.2.1 und brotlicffi 1.2.1.0 enthalten den Fix. Für .NET gibt es seit dem 25. Oktober Updates, eine Versionsnummer nennt keine der Quellen.
Reicht es, die Brotli-Bibliothek des Betriebssystems zu aktualisieren?+
Nein, wenn die Software eine eigene Kopie mitbringt. BleepingComputer schreibt, ein Update der System-Bibliothek behebe das Risiko bei Node.js nicht, weil Node den Decoder selbst enthält. Nach dem Update der Laufzeit müssen Prozesse neu gestartet und Container-Images neu gebaut werden.
Hilft es, eingehende Brotli-Anfragen am Proxy zu blocken?+
Nur teilweise. Der Angriff läuft über zwei Wege: ein komprimierter Request an den Server und eine manipulierte komprimierte Antwort, wenn die eigene Anwendung eine fremde URL abruft. Der Filter am Proxy schließt nur den ersten Weg. Das schreibt BleepingComputer.
senn-tech