Broccoli2Shell zeigt: Riskant ist der Code, den man nie ausgewählt hat

Welche Bibliothek entpackt die Daten, die Ihr Server empfängt? Wenn Sie das nicht in unter einer Minute beantworten können, ist Broccoli2Shell auch Ihr Problem – egal, ob Sie je das Wort „Brotli“ in Ihren Code getippt haben.

Der Fehler trägt die Kennung CVE-2026-111497 und ist ein Schreibzugriff außerhalb der Speichergrenzen im Brotli-Decoder von Google. Laut Strobes betrifft er die Brotli-Versionen 1.0.3 bis 1.2.0 und wird mit 9,2 (kritisch) nach CVSS 4.0 bewertet. Da HTTP-Clients und -Server Content-Encoding: br automatisch dekodieren, erreicht er Node.js, Python, Bun und andere Stacks über ganz normalen Webverkehr. Node.js lieferte am 21. Oktober Korrekturen in den Versionen 22.23.4, 24.22.1 und 26.12.1 aus, wie Qualys und andere berichten. Der Name hat sich mehrfach geändert (Node2Shell, HTTP2Shell, Broccoli2Shell), stets für dieselbe CVE.

Die Umbenennung ist die eigentliche Geschichte

Strobes weist treffend darauf hin: Der Spitzname wechselte dreimal in vier Tagen, und jeder Name spiegelte wider, wen die Branche für gefährdet hielt. Aus einem Patch für eine Laufzeitumgebung wurde ein Problem der Abhängigkeiten und der Lieferkette. Dieser Verlauf ist aus unserer Sicht die Lehre. Der verwundbare Code steckt in einer C-Bibliothek, die viele Projekte bündeln, einbinden oder erben. Niemand hat sie bewusst „installiert“. Sie kam mit der Laufzeitumgebung, dem HTTP-Client oder dem Image.

Deshalb handelt es sich um unsichtbare Infrastruktur. Semgrep merkt an, dass der Fehler weder in einem npm-Paket namens brotli noch in body-parser selbst liegt. Dennoch übergibt body-parser vom Angreifer kontrollierte komprimierte Daten an den Decoder. Ihr Abhängigkeitsscanner kann ruhig bleiben, während das Problem eine Ebene darunter liegt. Strobes verweist außerdem auf einen öffentlichen Tracker unabhängiger Forscher, der Projekte auflistet, deren gebündelte Kopien am 24. Oktober noch ungepatcht waren, darunter die.NET-Laufzeit, die PHP-Erweiterung brotli und das Ruby-Gem brotli. Ein Update der Distribution hilft nicht bei Software, die eine eigene private Kopie mitbringt.

Entscheidend sind die Pfade – und der schlimmste ist der ausgehende

Nicht jeder Node-Dienst ist gleichermaßen gefährdet, und das sollte man klar sagen, um Panik zu vermeiden. Semgrep betont, dass die Anwendung eine betroffene Version ausführen, einen Brotli-fähigen Parser verwenden, die Dekomprimierung aktiviert haben und eine Route bereitstellen muss, in der er eingebunden ist. Laut Strobes dekodiert Express 5 mit body-parser 2.x Brotli-Anfragekörper standardmäßig, sodass ein einziges app.use(express.json) den Decoder anonymem Traffic aussetzen kann.

Am unangenehmsten finden wir den Pfad, den niemand überwacht: Antworten, die Ihr eigener Code abruft. Das integrierte fetch von Node dekodiert Brotli automatisch, und laut Strobes tun urllib3, aiohttp und httpx in Python dasselbe, sobald ein Brotli-Paket installiert ist – selbst wenn Ihr Code es nie importiert. Webhooks, Link-Vorschauen, „Import per URL“, Crawler und surfende KI-Agenten sind alles Türen, durch die Außenstehende hereinkommen können. Strobes zufolge sieht keine WAF diesen Pfad. Die WAF von Vercel blockiert laut TuxCare die eingehende Route, nicht aber Antworten, die von anderswo abgerufen werden.

Heroisches Patchen skaliert nicht, Inventare schon

Die übliche Reaktion ist ein Wochenende hektischer Updates. Bei Node 22, 24 und 26 funktioniert das: Die Korrektur ist, so TuxCare, langweilig. Doch TuxCare warnt auch, dass Node.js 20, 18 und älter vom Upstream nichts mehr erhalten, und genau der vergessene Bestand beißt am Ende zu. Hinzu kommt die Neustart-Falle: Ein laufender Prozess behält den alten Decoder im Speicher.

Auch der Zeitverlauf sollte uns beunruhigen. TuxCare sagt unter Berufung auf The Hacker News, die Korrektur sei im Februar 2026 in den Brotli-Quellcode eingeflossen, aber erst am 21. Oktober in einem Sicherheitsrelease ausgeliefert worden. Strobes ergänzt, dass bis Oktober niemand sie mit Remote-Code-Ausführung in Verbindung gebracht habe. Ein öffentlicher Patch ist eine Landkarte, wie ein Medium-Autor es formulierte. Laut Strobes gibt es öffentliche Proofs of Concept, und laut TuxCare wurde bis zum 22. Oktober keine Ausnutzung in freier Wildbahn gemeldet. Wir würden diese Ruhe als vorübergehend betrachten, nicht als beruhigend.

In derselben Woche kam PHP2Shell, das Semgrep als Fehler beschreibt, der in PHP seit über einem Jahrzehnt existiert, und laut Google Cloud bleiben Anwendungen mit PHP 7.4 dafür anfällig. Zwei Enthüllungen zu Laufzeitumgebungen binnen eines Tages beweisen nicht, dass die Sicherheit kollabiert ist; Semgrep selbst sagt, der übergreifende Trend baue sich seit Jahren auf. Sie zeigen aber, wie wenig Zeit wir haben, um herauszufinden, was wir betreiben.

Unser Urteil

Selbstverständlich sofort patchen. Dann folgt die langweilige Arbeit, die tatsächlich schützt: ein Inventar führen, das unter die Paketmanifeste reicht – Laufzeitumgebungen, gebündelte native Bibliotheken, Basis-Images von Containern, CI-Runner und jede Stelle, an der Ihr Code eine URL abruft, die jemand anderes kontrolliert. Laufzeitumgebungen am Lebensende ausmustern, statt auf das Beste zu hoffen. Wir erwarten, dass der nächste Dekompressionsfehler früher oder später kommt, und das Team, das in Minuten beantworten kann, „wo setzen wir das ein?“, schlägt das Team mit den besten Patch-Heldentaten.