Die Brotli-Lücke Node2Shell reicht weit über Node.js hinaus

Die Lücke steckt in der Bibliothek selbst und nicht nur in Node.js: Betroffen ist der Brotli-Decoder in den Versionen 1.0.3 bis 1.2.0 (CVE-2026-111497, CVSS 4.0 mit 9,2); gepatcht ist Brotli ab 1.0.10, 1.1.1 und 1.2.1. Proof-of-Concepts existieren, Angriffe in freier Wildbahn sind laut heise bislang nicht bekannt (Stand 26. Oktober).

Ob Ihre Systeme betroffen sind, hängt also von der verwendeten Brotli-Version ab und davon, ob Brotli-Dekompression tatsächlich genutzt wird.

Welche Versionen betroffen sind und wo es Patches gibt

heise beschreibt einen potenziellen Pufferüberlauf des Brotli-Decoders „in den Versionen 1.0.3 bis 1.2.0 auf allen Plattformen“. Zur Einordnung der Begriffe (dm-Einordnung): Ein Pufferüberlauf bedeutet, dass ein Programm mehr Daten in einen Speicherbereich schreibt, als dieser fassen soll. Der Decoder ist der Teil einer Bibliothek, der komprimierte Daten wieder entpackt, also die Dekompression übernimmt. Brotli ist ein Kompressionsverfahren, das häufig bei der Übertragung von Webinhalten zum Einsatz kommt. Für die Abwehr genügt dieses Grundverständnis; entscheidend sind die Versionsnummern und die Frage, ob Brotli-Dekompression im Betrieb tatsächlich genutzt wird.

Google schließt die Lücke in den Brotli-Versionen 1.0.10, 1.1.1 und 1.2.1. Dass es drei Fixstände gibt, deutet auf parallel gepflegte Versionszweige hin (dm-Einordnung); belegt ist das nicht. Für Versionen vor 1.0.3 nennt heise keine Angabe zur Betroffenheit; ohne Angabe lässt sich dort weder Entwarnung noch Betroffenheit ableiten.

Node.js liefert die Korrekturen in den Versionen 26.12.1, 24.22.1 und 22.23.4. Wie golem schreibt, hat das Projekt die Lücke mit den Releases vom 21. Oktober behoben. Für Python gelten die Pakete „Brotli“ in Version 1.2.1 und „brotlicffi“ in Version 1.2.1.0. Für .NET verteilt Microsoft laut heise seit dem 25. Oktober Updates für unterstützte Runtimes und SDKs.

Besondere Aufmerksamkeit verdienen Bindings. Betroffen sind laut heise Software mit C-Code-Bindings, etwa Java-JNI-Wrapper, PHP- und Ruby-Erweiterungen sowie Go-cgo-Bindings. Zur Einordnung (dm-Einordnung): Bindings sind Brücken, über die andere Programmiersprachen die in C geschriebene Bibliothek aufrufen. Entscheidend ist, ob ein solches Paket Brotli als gebündelte Bibliothek mitbringt, also eine eigene Kopie im Paket statt der Systembibliothek zu verwenden. In diesem Fall hilft ein Update der Systembibliothek allein nicht, und das Paket selbst muss aktualisiert werden. Bei der Prüfung lohnt deshalb ein Blick in die Abhängigkeiten der jeweiligen Pakete, nicht nur in die Liste der Systempakete.

Weitere Software nennt heise unter Verweis auf Aikido: C++-Anwendungen, Bun und Envoy. Für diese Programme nennt heise keinen Fixstand, ebenso wenig für Ruby oder Java außerhalb der genannten Bindings. Ein Fixstand für diese Fälle ist nicht bekannt. Praktisch folgt daraus (dm-Einordnung): Solange keine Fixstände genannt werden, bleibt nur der regelmäßige Blick in die Hinweise der jeweiligen Projekte, und der Einsatz dieser Programme sollte bis dahin dokumentiert werden.

Die Entdeckung erfolgte laut Aikido, wie heise wiedergibt, schon im Februar, und zwar durch OpenAI. Die damalige Korrektur galt nicht als Sicherheitsfix. Das erklärt, warum sich der Patch-Stand nicht allein an Sicherheitsmeldungen ablesen lässt (dm-Einordnung). Wer nur auf entsprechend gekennzeichnete Updates achtet, könnte relevante Änderungen übersehen (dm-Einordnung). Ein Abgleich der konkreten Versionsnummern ist deshalb belastbarer als der Blick auf Release-Titel, und bei Paketen, die schon länger nicht aktualisiert wurden, lohnt sich die Prüfung der Version besonders.

Warum 9,2 und warum Node.js nur „high“ sagt

Zur Einordnung der Begriffe (dm-Einordnung): CVE steht für Common Vulnerabilities and Exposures und ist ein einheitliches Kennzeichnungssystem für Sicherheitslücken. CVE-2026-111497 bezeichnet diese Lücke eindeutig, egal in welchem Produkt sie auftaucht. CVSS 4.0 ist ein Bewertungssystem, das den Schweregrad auf einer Skala bis 10 einordnet. Der Wert von 9,2 beruht auf einer Kodierung der Voraussetzungen und Folgen eines Angriffs. Ein hoher Wert sagt etwas über das mögliche Ausmaß aus, nicht darüber, ob ein bestimmtes System betroffen ist; das hängt von Version und Nutzung ab.

Die GitHub-Advisory GHSA-9v8h-qqgm-4m35 (OSV) führt den Vektor AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H mit 9,2. Zur Deutung der Kürzel (dm-Einordnung): AV:N heißt Angriffsweg über das Netzwerk, AC:L geringe Angriffskomplexität. AT:P bedeutet, dass bestimmte Voraussetzungen vorliegen müssen. PR:N und UI:N stehen für keine nötigen Rechte und keine Interaktion der Nutzenden. VC:H, VI:H und VA:H bewerten Vertraulichkeit, Integrität und Verfügbarkeit des betroffenen Systems jeweils mit hoch. Als dm-Einordnung lässt sich AT:P mit der Beobachtung verbinden, dass Brotli-Dekompression tatsächlich genutzt werden muss.

Die Lücke wurde am 22. Oktober in der NVD veröffentlicht und unter CWE-252 geführt. Zur Einordnung (dm-Einordnung): Die NVD ist die US-Schwachstellendatenbank des Standardisierungsinstituts NIST. CWE ist eine Katalogisierung von Schwachstellenarten; was sich hinter der Nummer konkret verbirgt, lässt sich im Katalog nachlesen. Für die Praxis ist die Nummer vor allem ein Suchbegriff, mit dem sich Einträge zur Schwachstellenart finden lassen.

Bemerkenswert ist die Differenz der Bewertungen: Das Node.js-Projekt stuft CVE-2026-111497 in seinem Blog zu den Security Releases vom 21. Oktober mit „high“ ein, der CVSS-4.0-Wert von 9,2 liegt dagegen im kritischen Bereich; heise nennt das Risiko „kritisch“. Eine Erklärung für den Unterschied nennt der Node.js-Blog nicht. Plausibel ist (dm-Einordnung), dass ein Projekt die Lücke aus Sicht seiner eigenen Laufzeit bewertet, eine Bibliothekslücke dagegen breiter. Das ist eine Vermutung und keine belegte Begründung.

Zur Zuschreibung der Entdeckung: Der Node.js-Blog nennt „OpenAI Codex Security“ als Melder, golem spricht von „OpenAI-Forschern“, und heise gibt die Aussage von Aikido wieder. Die drei Formulierungen unterscheiden sich im Wortlaut, weisen aber alle auf OpenAI. Mehr lässt sich aus den Angaben nicht ableiten.

Für die Lücke kursieren mehrere Spitznamen: golem nennt Node2Shell, Brotli2Shell, HTTP2Shell und Broccoli2Shell. Für die Suche in Advisories ist die CVE-Nummer zuverlässiger, weil sie unabhängig vom Spitznamen bleibt. Wie bei der PHP-Sicherheitslücke gilt: erst Patch-Stand prüfen, dann die Dringlichkeit bewerten.

Was die Differenz für die Priorisierung bedeutet (dm-Einordnung): Weichen Bewertungen voneinander ab, legen Sie für Dienste mit Internetzugang den höheren Wert zugrunde, denn so entsteht keine zu optimistische Reihenfolge. Die CVE-Nummer dient dabei als gemeinsamer Schlüssel, um Advisories verschiedener Stellen einander zuzuordnen. Bei Rückfragen an Lieferfirmen nennen Sie beide Bewertungen, also 9,2 nach CVSS 4.0 und „high“ aus dem Node.js-Blog, damit die Antwort sich auf dieselbe Lücke bezieht und nicht an einer Einstufung hängen bleibt.

Wann eine Anwendung wirklich angreifbar ist

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptAbstract network of data pipes and nodes feeding into a server, glowing blue lines, one node highlighted in amber, clean technical illustration look as a photo composite. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

Eine verwundbare Version im Dateisystem macht noch keine angreifbare Anwendung. golem verweist darauf, dass die Brotli-Dekompression tatsächlich genutzt werden muss und die Betroffenheit teils von der Konfiguration abhängt. Wer Brotli-kodierte Daten nie entgegennimmt, nutzt den Decoder im Betrieb vermutlich nicht (dm-Einordnung). Die verwundbare Version bleibt dann trotzdem im System. Ein Update ist deshalb weiterhin sinnvoll, die Dringlichkeit unterscheidet sich jedoch (dm-Einordnung). Ob Brotli-Daten tatsächlich ankommen, lässt sich nur am konkreten Dienst klären.

Eine belegte Entlastung gibt es für zwei verbreitete Webserver: heise spricht von „leichter Entwarnung“, weil Apache und Nginx zumindest in den Standardkonfigurationen kein Brotli dekodieren.

Welche Software sonst betroffen ist, fasst golem unter Berufung auf The Hacker News zusammen: Apache Arrow, Ruby, Bun, .NET, Envoy, Istio und Python, teils konfigurationsabhängig. JFrog nennt laut golem zusätzlich FFmpeg und ClickHouse. Das sind Aufzählungen aus Sekundärberichten, keine vollständige Produktliste. Welche Konfigurationen darüber hinaus sicher sind, geben die Berichte nicht an.

Wichtig ist die Unterscheidung dreier Dinge. Erstens die Schwachstelle: Sie ist belegt, einschließlich CVE-Nummer, Bewertung und Patches. Zweitens die Proof-of-Concepts: Sie stehen laut heise inzwischen bereit, teils auch öffentlich. Das senkt die Hürde für Angriffe (dm-Einordnung), belegt aber keine Ausnutzung. Drittens die nachgewiesene Ausnutzung: Angriffe in freier Wildbahn sind laut heise bislang nicht bekannt, Stand 26. Oktober. Fehlende Meldungen sind kein Beweis, dass es keine Angriffe gibt (dm-Einordnung); es ist ein Stand, der sich ändern kann.

Zur Priorisierung (dm-Einordnung): Am dringlichsten sind Dienste, die Daten aus dem Internet annehmen und Brotli dekomprimieren. Interne Werkzeuge ohne Zugriff von außen haben weniger Eile, gehören aber trotzdem auf die Liste. Wie beim Patch-Stand bei Routern entscheidet die Versionsnummer, nicht das Bauchgefühl.

Besonders unübersichtlich sind Umgebungen, in denen Brotli indirekt mitkommt, etwa über Bibliotheken von Drittanbietern oder in fertigen Programmpaketen. Dort lässt sich die Betroffenheit selten an der Oberfläche erkennen. Wer nicht selbst nachsehen kann, sollte die Frage an die liefernde Stelle richten und nach Version, Fixstand und aktiver Dekompression fragen (dm-Einordnung).

Die Liste der genannten Software reicht von Laufzeitumgebungen über Proxys und Datenbanken bis zu Medienwerkzeugen. Eine Zahl betroffener Installationen nennt kein Bericht, und sie wird nicht geschätzt. Für die eigene Prüfung heißt das (dm-Einordnung): Nicht die Größe der Liste zählt, sondern der Abgleich mit dem eigenen Bestand, Programm für Programm.

Checkliste: So prüfen Sie Ihre Systeme

Die Schritte sind eine Arbeitsreihenfolge (dm-Einordnung) und kein Herstellerverfahren. Die einzige belegte Ausnahme ist die von heise genannte Handreichung der Aikido-Analyse zum Deaktivieren des Brotli-Decodings. Die Schritte richten sich an Teams, die Server betreiben oder Software entwickeln, und lassen sich auf kleine Umgebungen herunterskalieren.

1. Erstellen Sie ein Inventar der Brotli-Nutzung in Runtime, Paketen und gebündelten Bibliotheken. Ohne Überblick lässt sich keine Reihenfolge festlegen. Gebündelte Kopien fallen bei einer Prüfung nur der Systempakete durch, weshalb Sie die Abhängigkeiten der Anwendungen selbst ansehen sollten.
2. Gleichen Sie die gefundenen Versionen ab: gegen die Fixstände der Brotli-, Node.js-, Python- und .NET-Updates. Für Bun, Envoy und andere gelten die Hinweise der jeweiligen Projekte, weil für sie kein Fixstand genannt wird. So vermeiden Sie, einen Fund fälschlich als behoben zu verbuchen.
3. Bauen Sie Container-Images neu. Ein Image ist ein fertig geschnürtes Paket aus Anwendung und Systembestandteilen (dm-Einordnung). Es behält seine alte Brotli-Version, bis es mit aktualisierter Basis neu gebaut und ausgerollt wird; ein Update auf dem Host ändert daran nichts.
4. Deaktivieren Sie bis zum Update das Brotli-Decoding, wenn ein Dienst nicht sofort aktualisiert werden kann. Laut heise enthält die Aikido-Analyse Handreichungen dazu. Lesen Sie die Details dort nach, damit Sie keine Einstellungen aus zweiter Hand übernehmen.
5. Arbeiten Sie nach Internetzugang ab: zuerst Dienste, die Daten aus dem Internet annehmen, danach interne Systeme, zuletzt Entwicklungs- und Testumgebungen. Die Reihenfolge richtet den Aufwand dorthin, wo ein Angriff am ehesten möglich ist.
6. Fragen Sie Lieferfirmen nach Brotli-Version, Fixstand und aktiver Brotli-Dekompression. Bei Produkten, die Sie nicht selbst prüfen können, ist die Antwort die einzige belastbare Grundlage. Halten Sie die Antworten schriftlich fest, damit sich später nachvollziehen lässt, was geklärt ist.

Für die kommenden Stunden bietet sich (dm-Einordnung) diese Reihenfolge an: Zuerst prüfen Sie Dienste mit Internetzugang, die Brotli-Daten annehmen. Danach sehen Sie sich Webserver an, deren Konfiguration vom Standard abweicht, weil dort Brotli aktiviert sein könnte. Halten Sie in einer Notiz fest, welche Fixstände Lieferfirmen nennen und wann die Antwort einging. Legen Sie außerdem einen Wiedervorlagetermin an, sobald für Bun, Envoy und andere Projekte Fixstände genannt werden, und gleichen Sie dann die Notiz mit Ihrem Inventar ab.