HTTP2Shell: Brotli-Lücke erreicht Python, Bun und Envoy

Ein Speicherfehler im Brotli-Dekomprimierer von Google hat jetzt einen eingängigeren Namen und eine größere Reichweite. CVE-2026-111497 wurde am 21. Oktober 2026 zuerst in Node.js als „Node2Shell“ behoben. Seit dem späten 23. Oktober (UTC) heißt die Lücke „HTTP2Shell“. Der neue Name zeigt, wie weit sie reicht: Python-HTTP-Bibliotheken, die Laufzeitumgebung Bun sowie die Proxys Envoy und Istio enthalten allesamt betroffenen Code.

Das Sicherheitsunternehmen Aikido bewertet sie nach CVSS v4.0, der gängigen Skala für den Schweregrad, mit 9,2 von 10 Punkten (kritisch). Brotli ist ein Kompressionsformat, mit dem Webserver und Browser Daten verkleinern. Jedes Programm, das Brotli-Daten von Fremden entpackt, kann angreifbar sein.

Ein Fehler, zwei Namen

HTTP2Shell ist keine zweite Lücke. „Es ist eine CVE, keine zweite Lücke“, schreibt das Threat-Intelligence-Unternehmen Brandefense in seinem Tracker. Es ist derselbe Fehler im Brotli-Decoder unter neuem Namen.

Tech AI Wire hat über die erste Runde von Korrekturen im Oktober-Sicherheitsupdate von Node.js berichtet. Seitdem hat sich die Liste der betroffenen Projekte geändert.

So funktioniert der Fehler

Die Lücke steckt in den Brotli-Versionen 1.0.3 bis 1.2.0. Der Sicherheitsbeitrag von Node.js erklärt sie. Ein ungültiger „Block Switch“ in einem komprimierten Datenstrom wurde als vorübergehender Bedarf an weiteren Eingabedaten behandelt statt als Formatfehler. Der Decoder schrieb dann weiter in einen acht Byte großen internen Puffer, über dessen Ende hinaus.

Ein Schreibzugriff über das Ende eines Puffers hinaus kann ein Programm abstürzen lassen, Speicherinhalte preisgeben oder im schlimmsten Fall einem Angreifer die Ausführung von Code erlauben. Laut den Release Notes von Brotli selbst „erlaubt der Schreibzugriff außerhalb der Grenzen Remote-Codeausführung“.

Der Node.js-Beitrag schreibt die Meldung OpenAI Codex Security zu, dem automatischen Code-Review-Werkzeug von OpenAI. Laut Aikido fand OpenAI heraus, dass der Fehler in beide Richtungen wirkt. Ein bösartiger Client kann einen ungepatchten Server angreifen, und ein bösartiger Server kann einen ungepatchten Client angreifen.

Aikido ergänzt, dass die Ursache bereits im Februar im Quellcode von Brotli behoben wurde. Niemand kennzeichnete das als Sicherheitskorrektur, daher enthielt bis zum 21. Oktober kein Release die Änderung.

Warum Python-Apps angreifbar sind

Viele Python-Apps nutzen Brotli, ohne es je zu importieren. Laut Aikido verwenden urllib3 und requests, httpx, aiohttp und Scrapy Brotli automatisch, sobald es installiert ist. Pythons Brotli-Paket wird 82,8 Millionen Mal im Monat heruntergeladen.

Es gibt einen zweiten Haken. Laut Aikido verknüpften der CVE-Eintrag, die OSV-Datenbank und die Advisory-Datenbank von GitHub die CVE mit Stand 23. Oktober mit keinem der beiden Python-Pakete. Deshalb würden pip-audit, Dependabot und Safety eine verwundbare Version nicht melden.

Korrigierte Versionen

Projekt	Behoben in
Google Brotli (C-Bibliothek)	1.0.10, 1.1.1, 1.2.1
Brotli auf PyPI	1.2.1
brotlicffi auf PyPI	1.2.1.0
Node.js	22.23.4, 24.22.1, 26.12.1
Bun	1.4.4
Envoy	1.40.0, 1.39.3, 1.38.6, 1.37.8
Istio	1.29.9, 1.30.6, 1.31.2

Manche Versionen erhalten keine Korrektur. Node.js 20.x, 25.x und 18.x haben das Ende ihrer Lebensdauer überschritten, und Brandefense zitiert Vercel, wonach Node 20 „diese Korrektur nicht erhalten wird“. Brandefense führt außerdem die neueren Brotli-Pakete von Debian auf, für die es noch keine korrigierte Version gibt. Laut Aikido dekodieren Apaches mod_brotli und Nginx Brotli standardmäßig nicht.

Wird die Lücke ausgenutzt?

Bis 22:00 Uhr UTC am 23. Oktober waren laut Brandefense keine Angriffe in freier Wildbahn gemeldet worden. Die Lücke steht nicht auf der CISA-Liste bekannter ausgenutzter Schwachstellen.

Wie schwer sie in der Praxis wiegt, ist noch umstritten. Der Forscher Ron Masas sagt, sein Team habe Remote-Codeausführung ohne Anmeldung reproduziert. Brandefense merkt an, dass veröffentlichter Proof-of-Concept-Code meist nur Abstürze auslöst, und eine Analyse argumentiert, dass nur ein Denial of Service möglich ist.

Was das für Entwickler bedeutet

Erst patchen, dann die Lock-Dateien von Hand prüfen. Weil Scanner die Python-Pakete womöglich nicht melden, suchen Sie in Ihren Abhängigkeitslisten nach Brotli und brotlicffi und aktualisieren Sie auf 1.2.1 oder 1.2.1.0.

Gehen Sie nicht davon aus, dass nur Server ein Ziel sind. Wenn Ihr Code mit requests, httpx oder aiohttp Daten von fremden Servern abruft, kann ein feindlicher Server den manipulierten Datenstrom senden. Aikido warnt, dass „eine Änderung von Accept-Encoding allein nicht ausreicht“, weil dieser Header den Server nur bittet, nicht zu komprimieren.

Prüfen Sie unter Node.js, was Ihr Framework dekodiert. Nach Lesart von Brandefense dekodiert Express 5 Brotli-komprimierte Request-Bodies standardmäßig, Express 4 dagegen nicht. Masas bringt das Risiko auf den Punkt: „app.use(express.json()) genügt.“

Wenn Sie Envoy oder Istio als Service Mesh betreiben, aktualisieren Sie auch die Proxys. Alles, was eine eigene Kopie von Brotli mitbringt, muss neu gebaut werden, ein System-Update allein reicht nicht. Wo es noch keinen Patch gibt, empfiehlt Aikido, die Brotli-Dekodierung abzuschalten.

Anfang dieser Woche zog eine andere PHP-Lücke, PHP2Shell, schon vor ihrer Offenlegung Angriffsversuche auf sich. Behandeln Sie diese Lücke mit derselben Eile.