Mastodon Mastodon Mastodon Mastodon

CVE-2026-111497: Schwachstelle im Brotli-Decoder betrifft Node.js, Bun, Python und Envoy

Foto des Autors

CyberSecureFox Editorial Team

Veröffentlicht:

Aktualisiert:

Die Schwachstelle CVE-2026-111497 im Brotli-Kompressionsdecoder von Google ermöglicht einen Schreibzugriff außerhalb des Puffers bei der Verarbeitung speziell präparierter komprimierter Daten. Da zahlreiche Softwareprodukte – von Node.js und Bun bis hin zu Python-Paketen und Envoy-Proxys – eine eigene Kopie dieses Decoders mitliefern, ist der Umfang der betroffenen Software erheblich. Forschende von Imperva haben die Ausführung beliebigen Codes auf einem unveränderten Node.js-24.22.0-Build für Linux arm64 demonstriert. Patches sind bereits verfügbar: Das Aktualisieren der Runtime oder Bibliothek ist die einzige zuverlässige Methode zur Behebung.

Technische Details der Schwachstelle

Die Schwachstelle wird als CWE-787 (Schreiben außerhalb des Puffers) klassifiziert und befindet sich im C-Code des Brotli-Decoders. Laut Eintrag in der GitHub Advisory Database tritt das Problem bei der Verarbeitung eines Brotli-Datenstroms auf, bei dem die deklarierte Blockstruktur zu einem unmöglichen Wechsel des Blocktyps führt. Der verwundbare Decoder interpretiert diesen Zustand als Anforderung zusätzlicher Daten und arbeitet im ungültigen Zustand weiter, was zu einem Schreibzugriff außerhalb des zugewiesenen Puffers führt. Die korrigierte Version bricht das Dekodieren stattdessen mit einem Formatfehler ab.

Die Bewertung der Kritikalität variiert je nach Produktkontext. Die GitHub Advisory Database gibt 9.2 Critical nach CVSS v4.0 an. Red Hat stuft die Schwachstelle als Important mit einem Score von 8.1 nach CVSS v3.1 ein. Node.js vergibt den Schweregrad High. Istio nennt im Kontext seines Produkts 7.7. Diese Spannweite spiegelt die unterschiedlichen Bedingungen wider, unter denen der verwundbare Code in jedem Produkt erreichbar ist, und keine dieser Bewertungen sollte als allgemeingültig betrachtet werden.

Bemerkenswert ist die Historie der Korrektur: Der Patch, der die eigentliche Ursache schließt, wurde bereits am 27. Februar in den Brotli-Quellcode eingepflegt, jedoch war zu diesem Zeitpunkt nicht bekannt, dass die Änderung eine Sicherheitsschwachstelle behebt, und es erschien bis zum 21. Oktober keine neue Brotli-Version mit dieser Korrektur. Details finden sich auf der NVD-Seite.

Betroffene Produkte und Ausnutzungsbedingungen

Ein zentrales Merkmal dieser Schwachstelle: Jedes betroffene Produkt liefert eine eigene Kopie des Brotli-Decoders aus, daher muss jedes Produkt unabhängig aktualisiert werden. Bestätigte Liste der betroffenen Software:

  • Node.js – Linien 22.x, 24.x und 26.x. Korrigierte Versionen: 22.23.4, 24.22.1 und 26.12.1 (Node.js-Sicherheitshinweis)
  • Bun – Versionen von 1.0.21 bis 1.4.3. Behoben in 1.4.4 (Bun-Sicherheitshinweis)
  • Python-Paket Brotli (PyPI) – Versionen von 1.0.3 bis 1.2.0. Behoben in 1.2.1
  • Python-Paket brotlicffi (PyPI) – analog betroffen
  • Envoy – bei aktivierter Brotli-Dekompression (Envoy-Sicherheitshinweis)
  • Istio – Versionen 1.29.0–1.29.8, 1.30.0–1.30.5, 1.31.0–1.31.1 bei Nutzung des betroffenen Envoy-Pfads

Die Ausnutzungsbedingungen hängen von der Konfiguration ab. Ein Programm ist nur verwundbar, wenn es Brotli-Daten aus einer nicht vertrauenswürdigen Quelle dekodiert. Für Node.js und Bun geschieht dies beim Lesen einer Antwort mit dem Header Content-Encoding: br über das eingebaute fetch() sowie bei der Dekompression des Anfragebodys über Middleware. Der HTTP-Server von Node.js dekodiert den Request-Body im Brotli-Format nicht von sich aus – dafür ist ein expliziter Aufruf oder Middleware erforderlich. Laut Express-5-Dokumentation unterstützen die Middleware-Funktionen express.json(), express.urlencoded(), express.text() und express.raw() nun Brotli-Dekompression, was auf Routen, auf denen diese Handler aktiv sind, einen eingehenden Angriffsvektor schafft.

In Python ist die Situation besonders tückisch: Es genügt, dass das Paket Brotli oder brotlicffi installiert ist, damit die HTTP-Clients requests, urllib3, httpx und aiohttp Antworten im Brotli-Format automatisch dekodieren – ohne dass Brotli explizit im Anwendungscode importiert wird.

Für Envoy und Istio ist die Schwachstelle nur erreichbar, wenn die Brotli-Dekompression über den entsprechenden Filter aktiviert ist.

Status der Ausnutzung und Demonstration

Status der Ausnutzung – öffentlicher PoC verfügbar. Forschende von Imperva haben im Rahmen der Node2Shell-Demonstration die Ausführung beliebigen Codes auf einem Standard-Build von Node.js 24.22.0 für Linux arm64 erreicht – ohne Debugger und ohne modifizierten Build. Der Exploit ließ sich über beide Vektoren reproduzieren – den eingehenden Request-Body (Express 5) und die Antwort, die über fetch() empfangen wurde. Die Ausnutzung war dabei jedoch nicht stabil und erforderte mehrere Versuche; andere Architekturen sowie die Linien 22.x und 26.x wurden nicht getestet.

Laut Vercel-Sicherheitshinweis haben die Forschenden zudem eine Speicherlecksituation des Prozesses sowie die Ausführung von Befehlen auf ungepatchten Node.js-Linien demonstriert. Zum Zeitpunkt der Veröffentlichung wurden keine Ausnutzungen in realen Angriffen festgestellt. Die Schwachstelle ist nicht im CISA-KEV-Katalog aufgeführt.

Grenzen des WAF-Schutzes

Vercel hat am 21. Oktober WAF-Regeln zur Blockierung eingehender Angriffe ausgerollt. Wie im Vercel-Sicherheitshinweis ausdrücklich erwähnt, erfassen diese Regeln jedoch keine Antworten im Brotli-Format, die die Anwendung von externen Servern empfängt. Dies ist eine grundlegende Einschränkung: WAF-Telemetrie kann einen Teil der Angriffsversuche im eingehenden Traffic erkennen, kann aber nicht vor bösartigen Antworten schützen, die die Anwendung bei Zugriffen auf externe Ressourcen erhält. Daher bleiben die Inventarisierung der Runtimes und der Neuaufbau von Container-Images zwingend notwendig.

Empfehlungen

Priorität beim Aktualisieren sollten internetzugängliche Services und Clients haben, die nicht vertrauenswürdige Brotli-Daten automatisch dekodieren. Allein die Tatsache, dass HTTP-Traffic empfangen wird, bedeutet keine Verwundbarkeit von Node.js – es muss Code oder Middleware vorhanden sein, die die Dekompression durchführt.

  • Aktualisieren Sie Runtime oder Bibliothek auf eine korrigierte Version. Starten Sie den Service nach dem Update neu und bauen Sie Container-Images neu – ein laufender Prozess verwendet den alten Decoder bis zum Neustart.
  • Die Node.js-Linien 20.x und älter erhalten keinen Patch – eine Migration auf eine unterstützte Linie ist erforderlich.
  • Wenn eine sofortige Aktualisierung nicht möglich ist: Lehnen Sie eingehende Requests mit dem Header Content-Encoding: br ab, bevor Proxy oder Parser mit der Dekompression beginnen; deaktivieren Sie die automatische Brotli-Dekompression in HTTP-Clients.
  • In Python: Entfernen Sie die Pakete Brotli und brotlicffi, damit die Clients wieder auf gzip und deflate zurückfallen.
  • Prüfen Sie Dependency-Scanner: Der CVE-Eintrag verweist auf das Google-Brotli-Repository und nicht auf die PyPI-Pakete, und der GitHub Advisory nannte zum Zeitpunkt der Veröffentlichung das betroffene Paket nicht – Dependabot schlägt möglicherweise nicht an. Die Einträge PYSEC-2026-4322 und PYSEC-2026-4323 wurden am 23. Oktober hinzugefügt; prüfen Sie die installierten Versionen manuell.

Das Entfernen des Headers br aus Accept-Encoding bietet für sich genommen keinen Schutz: Der Server kann eine Antwort im Brotli-Format unabhängig von den Präferenzen des Clients senden. Für Node.js wurde kein Workaround innerhalb der Runtime veröffentlicht – das Update ist die einzige Möglichkeit zur Behebung der Schwachstelle.

Aktualisieren Sie alle Instanzen der betroffenen Runtimes und Bibliotheken und widmen Sie Diensten, die nicht vertrauenswürdigen Brotli-Traffic in beide Richtungen verarbeiten – sowohl eingehend als auch beim Empfang von Antworten externer Server –, besondere Aufmerksamkeit. Zuvor haben wir über Sicherheitsfixes in Google-Produkten berichtet – CVE-2026-111497 bestätigt, dass in Drittprodukte eingebettete Google-Komponenten separat überwacht und aktualisiert werden müssen.


CyberSecureFox Editorial Team

Die CyberSecureFox-Redaktion berichtet über Cybersecurity-News, Schwachstellen, Malware-Kampagnen, Ransomware-Aktivitäten, AI Security, Cloud Security und Security Advisories von Herstellern. Die Beiträge werden auf Grundlage von official advisories, CVE/NVD-Daten, CISA-Meldungen, Herstellerveröffentlichungen und öffentlichen Forschungsberichten erstellt. Artikel werden vor der Veröffentlichung geprüft und bei neuen Informationen aktualisiert.

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre, wie deine Kommentardaten verarbeitet werden.