Das Wichtigste in Kürze
- Node2Shell (CVE-2026-111497) ist eine kritische Lücke im Brotli-Decoder, der von Node.js und anderer Software genutzt wird. Fixes gibt es seit dem 21. Oktober 2026.
- Ein Update der Systembibliothek reicht nicht: Runtimes und Apps bringen oft eine eigene Kopie mit, und laufende Programme müssen neu gestartet oder neu deployt werden.
- Fragen Sie Ihre Entwickler, welche Runtimes Sie einsetzen, ob sie auf einer behobenen Version laufen und ob welche keinen Support mehr erhalten.
- Die Berichte gehen auseinander, ob Angriffe beobachtet wurden. Behandeln Sie das Update daher in jedem Fall als dringend.
Müssen Sie wegen Node2Shell etwas unternehmen? Wenn Ihre Website, App oder API auf Node.js läuft oder auf Software, die Brotli-komprimierte Daten liest: ja. Bitten Sie denjenigen, der sie betreut, zu bestätigen, dass sie aktualisiert wurde. Wenn Sie nur einen gehosteten Shop nutzen und keinen eigenen Code betreiben, ist das Patchen in der Regel Aufgabe Ihres Plattformanbieters. Alles Individuelle, das Sie selbst betreiben, müssen Sie aber weiterhin selbst prüfen.
Was ist Node2Shell?
Node2Shell ist der Spitzname für CVE-2026-111497, eine kritische Sicherheitslücke mit 9,2 von 10 Punkten auf der CVSS-Skala (dem Standardmaß für den Schweregrad von Schwachstellen). Sie steckt in Brotli, einer Kompressionsbibliothek. Brotli verkleinert Webinhalte, damit Seiten schneller laden. Server, Browser und Apps nutzen sie, wenn Daten mit Content-Encoding: br gekennzeichnet sind.
Forscher haben die Lücke auch HTTP2Shell und Broccoli2Shell genannt, deshalb liefern Suchen unterschiedliche Namen. Es handelt sich um dasselbe Problem.
Kurz gesagt: Ein speziell präparierter Brotli-Datenstrom bringt den Decoder dazu, über das Ende eines Speicherblocks hinaus zu schreiben. Laut Node.js kann das ein Programm zum Absturz bringen, Speicherinhalte offenlegen oder einem Angreifer erlauben, eigenen Code auszuführen. Trotz eines der Spitznamen ist die Lücke nicht auf HTTP/2 beschränkt.
Node.js und Google haben am 21. Oktober 2026 Fixes veröffentlicht, die öffentliche Bekanntgabe folgte am 22. Oktober.
Wird die Lücke bereits angegriffen?
Proof-of-Concept-Exploit-Code ist öffentlich verfügbar. Die Berichte gehen auseinander, ob Angriffe in der Praxis beobachtet wurden: Eine Sicherheitsfirma gibt an, Ausnutzung festgestellt zu haben, während andere Berichte zum Zeitpunkt ihrer Veröffentlichung keine gefunden hatten. Behandeln Sie die Sache in jedem Fall als dringend, denn Angreifer handeln meist schnell, sobald funktionierender Exploit-Code öffentlich ist.
Wer ist betroffen?
Jede Software, die eine verwundbare Version des Brotli-Decoders nutzt (Versionen 1.0.3 bis 1.0.9, 1.1.0 und 1.2.0). Sicherheitsanbieter nennen unter anderem:
- Node.js
- in den Versionslinien 22, 24 und 26 vor den unten genannten Fix-Releases.
- Python
- HTTP-Bibliotheken wie urllib3, requests, httpx und aiohttp, wenn ein verwundbares Brotli-Paket installiert ist.
- .NET
- hier hat Microsoft Notfall-Updates veröffentlicht.
- Bun
- außerdem Java-Stacks, curl, Proxys wie Envoy und einige Linux-Distributionen, jeweils mit eigenen Updates.
| Software | Behobene Version |
|---|---|
| Node.js 22 / 24 / 26 | 22.23.4 / 24.22.1 / 26.12.1 |
| Brotli (die C-Bibliothek) | 1.0.10, 1.1.1 oder 1.2.1 |
| Python Brotli / brotlicffi | 1.2.1 / 1.2.1.0 |
| Bun | 1.4.4 |
Prüfen Sie für alles, was hier nicht aufgeführt ist, den Sicherheitshinweis Ihres eigenen Anbieters. Distributionen und andere Produkte liefern eigene gepatchte Versionen aus.
Wie könnte ein Angreifer die Lücke erreichen?
Indem er Ihre Software dazu bringt, Daten zu dekomprimieren, die er kontrolliert. Das kann auf zwei Wegen geschehen:
- Er schickt eine komprimierte Anfrage direkt an Ihren Server.
- Ihre Software ruft eine Webadresse ab oder einen anderen Dienst auf und erhält eine bösartige komprimierte Antwort zurück.
Am meisten zu prüfen haben Dienste, die als Proxy arbeiten, externe APIs aufrufen oder komprimierte Uploads annehmen.
Warum ist das Aktualisieren nicht so einfach, wie es klingt?
- Mitgelieferte Kopien
- Ein Update der Brotli-Bibliothek auf Ihrem Server behebt das Problem nicht in Node.js oder in einer App, die ihre eigene Kopie mitbringt. Jede muss einzeln aktualisiert werden.
- Laufende Programme
- Ein lange laufender Dienst behält den alten Code im Speicher, bis er neu gestartet wird. Container müssen neu gebaut und neu deployt werden.
- Nicht mehr unterstützte Versionen
- Node.js-Versionslinien ohne Support, etwa 18 und 20, erhalten keinen offiziellen Fix. Die Lösung ist der Wechsel auf eine unterstützte Version, und das ist ein größerer Aufwand als ein Patch.
Was sollten Sie Ihre Entwickler fragen?
- Welche Runtimes und Bibliotheken setzen wir ein, und in welchen Versionen? Dazu gehören die Website, die Admin-Tools, Hintergrundjobs und etwaige Serverless-Funktionen.
- Welche davon lesen Brotli-Daten von außen? Kundenanfragen, Uploads und Antworten anderer Dienste zählen alle dazu.
- Wurden sie auf eine behobene Version aktualisiert und neu gestartet? „Installiert“ ist nicht dasselbe wie „läuft“.
- Bringt irgendetwas eine eigene Kopie mit? Container, gebündelte Apps und paketierte Tools tun das häufig.
- Läuft irgendetwas auf einer Version, die keine Fixes mehr erhält? Falls ja, verlangen Sie einen Plan und einen Termin.
- Wie erfahren wir von der nächsten Lücke? Jemand sollte ausdrücklich dafür zuständig sein, Sicherheitshinweise zu verfolgen.
Was, wenn Sie heute nicht patchen können?
Übergangsmaßnahmen verringern das Risiko, beseitigen es aber nicht. Sicherheitsanbieter empfehlen, eingehende Brotli-Anfragen an Proxy oder Firewall einzuschränken oder zu blockieren, die Größe von Anfragen zu begrenzen und bei Python-Apps, die darauf verzichten können, die Brotli-Unterstützung abzuschalten. Keine dieser Maßnahmen verhindert eine bösartige Antwort von einem Server, den Ihre eigene Software aufruft. Die eigentliche Lösung bleibt daher das Update.
Was sagt das über die Betreuung von Software?
Sicherheitsupdates sind kein einmaliges Projekt. Bibliotheken, von denen Ihre Software abhängt, ändern sich im Hintergrund, und eine Lücke in einer davon kann viele Produkte gleichzeitig betreffen. Jemand muss dafür verantwortlich sein, so etwas zu bemerken und zu handeln, mit vereinbarten Reaktionszeiten. Unsere Leitfäden dazu, was Anwendungssupport und Wartung tatsächlich umfassen und was ein fairer Wartungsvertrag enthält, erklären, was Sie verlangen sollten.
Wenn Sie nicht sicher sind, worauf Ihre Software läuft, listet ein technisches Audit Ihre Runtimes und Abhängigkeiten auf. Wenn jemand diese aktuell halten soll, sehen Sie sich unsere Leistung Laufender Support und Wartung an oder kontaktieren Sie uns.
Quellen
Dieser Artikel basiert auf den unten aufgeführten Berichten von Anbietern, abgerufen am 29. Oktober 2026. Versionen und Sicherheitshinweise können sich ändern, prüfen Sie daher den Hinweis Ihres eigenen Anbieters.
Weiterlesen
Aus dem Original auf Englisch übersetzt.