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

Aus Node2Shell ist am 23. Oktober HTTP2Shell geworden – ein neuer Name, keine neue Lücke. Gemeint ist weiterhin CVE-2026-111497 im Brotli-Decoder, deren Folgen für Node.js im Beitrag von gestern stehen. Neu ist, wie weit dieselbe Bibliothek reicht: in Python-Pakete, Bun, Envoy, curl und Git for Windows. Gefährlich wird sie dort unter einer Bedingung, die in vielen Warnungen fehlt – die Software muss Brotli-Daten aus fremder Quelle entpacken.

Was ist HTTP2Shell?

HTTP2Shell ist der Name, unter dem das Sicherheitsunternehmen Aikido am 23. Oktober 2026 die Reichweite von CVE-2026-111497 über Node.js hinaus beschrieben hat: einem Out-of-Bounds-Write im Brotli-Decoder von Google, betroffen sind die Fassungen 1.0.3 bis 1.2.0. Der Name verschiebt den Blick vom Laufzeitsystem auf das Protokoll. Betroffen sein kann jede Software, die Brotli-komprimierte HTTP-Daten entpackt. Fehler, Fix und die korrigierten Fassungen 1.0.10, 1.1.1 und 1.2.1 sind dieselben wie am 21. Oktober; den CVE-Eintrag hat Google selbst herausgegeben.

Wer betroffen ist – und unter welcher Bedingung

Betroffen ist eine Software nur, wenn sie eine verwundbare Brotli-Fassung enthält und damit Daten entpackt, die ein Angreifer liefern kann. Bei den meisten der jetzt genannten Projekte ist genau das optional:

Für Python hat GitHub am 22. Oktober ein eigenes Advisory veröffentlicht, GHSA-9v8h-qqgm-4m35. Die Pakete kommen oft als indirekte Abhängigkeit in eine Umgebung. Istio hat den Fix bereits am 15. Oktober ausgeliefert, vor der Offenlegung. Kopien, die fest in ein Programm eingebaut sind, brauchen einen neuen Build: Git for Windows 2.56.0.windows.3 vom 22. Oktober führt in seiner Paketliste weiterhin brotli 1.2.0-1.

Server und Client: Die Richtung entscheidet

Die Lücke wirkt in beide Richtungen, und die zweite wird leicht übersehen. Auf der Serverseite entpackt eine Anwendung Brotli-komprimierte Anfragen, bei Node.js etwa über die Parser von Express 5. Auf der Clientseite entpackt sie die Antwort eines Servers, den sie selbst aufruft: Bun und Nodes fetch() tun das automatisch, urllib3 und damit requests nach dem Content-Encoding der Antwort.

Für die Clientseite muss ein Angreifer keinen Server angreifen, sondern einen betreiben. Jede Funktion, die eine fremde Adresse abruft, ist ein solcher Weg: Webhooks, Link-Vorschauen, Avatar-Importe, ein git clone von einem unbekannten Server. Ein Test des Blogs lilting.ch vom 24. Oktober zeigt, dass urllib3 eine Brotli-Antwort selbst dann entpackt, wenn der Client mit Accept-Encoding: identity keine Kompression verlangt hat. Ein Reverse Proxy, der Anfragen mit Content-Encoding: br abweist, schützt diese Richtung nicht.

Bun nennt im Advisory ausdrücklich keinen Workaround für den ganzen Prozess; einzelne Abrufe lassen sich mit decompress: false schützen. Die verbreiteten Webserver sind dagegen selten der Weg: Apache und nginx komprimieren mit Brotli, entpacken laut Aikido aber standardmäßig nicht.

Versionsnummern zeigen den Fix nicht

Ob eine Komponente den Fix enthält, lässt sich an ihrer Brotli-Versionsangabe nicht zuverlässig ablesen. Node.js hat in 24.22.1 und 26.12.1 nur den Fix-Commit übernommen; die Versionsdatei im Quellbaum steht weiter auf 1.2.0, in 22.23.4 auf 1.1.0, und process.versions.brotli meldet diese Werte. Debian hat den Fix zurückportiert: 1.0.9-2+deb12u1 für Bookworm (DLA-4855-1) und 1.1.0-2+deb13u1 für Trixie (DSA-6582-1), beide vom 23. Oktober. Wer nur die Upstream-Version vergleicht, meldet gepatchte Systeme als verwundbar.

Dazu kommt der Zeitplan. Der Fix-Commit 0ed4268 liegt seit dem 27. Februar 2026 öffentlich im Brotli-Repository, beschrieben als „Detect and report invalid stream earlier.“ Ein Release folgte erst am 21. Oktober. Knapp acht Monate stand die Korrektur damit im Quellcode, aber in keiner Fassung, die Distributionen und Paketmanager ausliefern – ein stiller Fix wie zuletzt beim Hardening-Release von Fortinet, nur länger.

Wie kritisch die Lücke wirklich ist

Die Lage hat sich seit dem 21. Oktober nicht verschärft, sondern geklärt: Bekannt ist jetzt, wo der Decoder überall steckt, Angriffe sind weiterhin keine bekannt. Google bewertet die Lücke mit CVSS 9.2 nach Version 4.0, der Vektor enthält aber AT:P – ein erfolgreicher Angriff setzt bestimmte Einsatzbedingungen des Systems voraus. Andere bewerten niedriger: Node.js und Bun mit „high“, Amazon Linux mit 8.1 nach CVSS 3.1, Ubuntu mit der Priorität „medium“.

CISAs Einschätzung im CVE-Eintrag lautet für Ausnutzung „none“ und für Automatisierbarkeit „no“; im KEV-Katalog steht die Lücke mit Stand 24. Oktober nicht. Die einzige dokumentierte Codeausführung bleibt Impervas Exploit gegen Node.js, der nicht bei jedem Versuch gelang. Auf GitHub sind seit dem 21. Oktober mehr als 30 Repositories mit Proof-of-Concepts, Testlaboren und Prüfskripten zur CVE erschienen; ob darunter ein verlässlicher Exploit ist, ist offen.

Was jetzt zu tun ist

Die Arbeit verschiebt sich von der Frage nach der Version zur Frage, wer fremde Daten entpackt:

• Python-Umgebungen prüfen, nicht nur die Projektdateien: brotli und brotlicffi auf 1.2.1 bzw. 1.2.1.0 heben, auch in Container-Images.
• Fest eingebaute Kopien neu bauen. Mit bun build --compile erzeugte Programme bleiben laut Bun verwundbar, bis sie mit 1.4.4 neu gebaut sind; dasselbe gilt für statisch gelinktes curl.
• Proxy-Konfigurationen durchsuchen. Envoy und Istio erreichen den Decoder nur mit aktivem Brotli-Decompressor; wo er konfiguriert ist, hat das Update Vorrang.
• Ausgehende Abrufe einbeziehen. Dienste, die Adressen von Nutzern abrufen, entpacken die Antworten fremder Server.
• Distributionspakete aktualisieren und Prozesse neu starten. Ubuntu führt die Lücke als „needs evaluation“, Amazon Linux 2023 das Brotli-Paket als „pending fix“ (Stand 24. Oktober); dynamisch gelinkte Programme wie curl profitieren vom Bibliotheks-Update ohne eigenes Release.
• Versionsbefunde gegen den Fix-Stand prüfen. Brotli 1.2.0 in Node 24.22.1 oder 1.0.9 in Debian Bookworm ist kein Befund.

Was hilft – und warum Sichtbarkeit entscheidet

Bei HTTP2Shell zählt weniger, welche Brotli-Version installiert ist, als welche Systeme fremde Daten entpacken: öffentliche APIs, Proxys, Dienste, die Adressen von Nutzern abrufen. blacklens.io erfasst über Attack Surface Management laufend von außen, welche Dienste und Webanwendungen erreichbar sind und welche Technologien in welchen Versionen darauf laufen. Das Threat Center gleicht neue CVEs in Echtzeit mit diesem Inventar ab und weist je Treffer aus, ob er auf der exakten Version beruht oder nur auf dem Produkt.

Die Grenze ist hier enger als bei Node2Shell. Der CVE-Eintrag nennt als betroffenes Produkt nur Brotli, eine Bibliothek, die ein Dienst nach außen nicht anzeigt; erkennbar sind ihre Träger, etwa Node.js-Anwendungen und Proxys. Ein Brotli-Paket in einer Python-Umgebung oder einem kompilierten Programm findet nur eine Prüfung auf dem System. Von außen lässt sich eingrenzen, wo sie zuerst nötig ist.