Speicher Korruptionsversagen in Brotli C (CVE-2026-111497) betrifft Node.js, Bun und Python

In den letzten Wochen wurde in Brotlis C-Decoder - dem von Google entwickelten Kompressionsalgorithmus - ein Speicherfehler entdeckt, der sich auf Programme ausbreitet, die diese Implementierung beinhalten, um Daten mit Content-Encoding zu komprimieren: br. CVE-2026-111497, kann manipulierte Brotli-Daten über das Ende eines Puffers schreiben und den Speicher des verletzlichen Prozesses verändern. In der Praxis kann dies zu Blockaden, Speicherlecks oder in für den Angreifer günstigen Szenarien zur Ausführung beliebigen Codes führen.

Konfirmierte Fakten: Der Defekt liegt im C-Code, der Brotli fließt und, da viele Anwendungen und Laufzeiten eine lokale Kopie dieses Codes enthalten, erscheint die Schwachstelle in mehreren Projekten unabhängig. Unter den Betroffenen sind Node.js (Patching), die Laufzeit Bun, Python Pakete wie Brotli und Brotlicffi und Proxies wie Envoy, wenn Brotli Dekompression aktiviert ist. Das Scheitern wurde am 21. Oktober mit bereits in einigen Produkten verfügbaren Patches öffentlich verbreitet; jedes Projekt muss jedoch seine eigene Kopie des Decoders aktualisieren, da es keine einzige gemeinsame Bibliothek gibt, die global aktualisiert wird. Das offizielle Projekt Repository befindet sich in https: / / github.com / google / brotli.

Wie es technisch funktioniert (Zusammenfassung): Brotli arbeitet mit internen Strukturen und Schiebefenstern, um komprimierte Daten wieder aufzubauen. Bug ist eine klassische Speicherverfälschung in C: eine Dekompressionsroute ermöglicht fehlerhafte Eingaben, um den Algorithmus Kopierdaten über den vorgesehenen Speicher für einen Puffer zu machen. Dies kann Prozessmetadaten oder kritische Daten im Stack/Hap überschreiben. Der endgültige Effekt hängt vom Speicherlayout, vom Systemschutz (ASLR, DEP) und dem spezifischen Binär, der den Decoder enthält, ab; daher kann der gleiche Defekt in einem Build ausnutzbar und in einem anderen nicht ausnutzbar sein.

Was demonstriert wurde und was nicht: Impervas Forschungsteam gelang es, Code in einem unmodifizierten Node.js 24.22.0-Gebäude für Linux ARM64 mit böswilligem Brotli zu führen, beide, wenn die Nutzlast als Fitch () Antwort kam und wenn es in den Körper einer Express-Anforderung gesendet wurde. Die Explosion erforderte mehrere Versuche, die PoC wurde nicht veröffentlicht und die Autoren behaupteten nicht, an anderen Gebäuden oder Plattformen zu arbeiten. OpenAI und andere Unternehmen haben bestätigt, dass die Sicherheitslücke unter bestimmten Bedingungen zu einer Fernabwicklung führen kann, aber es gibt bisher keine überprüften Betriebsberichte in realen Umgebungen; CISA hat die Ausbeutung als "none" registriert. Kurz gesagt, es gibt einen privaten Konzepttest für eine bestimmte Konfiguration von Node.js, während die Ausbeutung im Rest des Ökosystems unsicher bleibt.

Wer beeinflusst: jede Software, die Brotli mit dem anfälligen C-Decoder dekomprimiert und von einem Dritten kontrollierte Daten empfängt. Praktische Beispiele: In Node.js und Bun erscheint die Ausstellung, wenn fitch () eine Antwort mit Content-Encoding verarbeitet: br oder wenn Middleware wie Express 5 oder Body-parser 2 einen Körper dekomprimiert, der vom Kunden gesendet wird. Gesandte oder Istio sind nur gefährdet, wenn die Brotli-Dekompression aktiviert wird (z.B. durch einen Filter); wenn sie deaktiviert ist, wird die Angriffsroute geschlossen. In Python ist die Situation hinterlistiger: die bloße Präsenz der Brotli- oder Brotlicffi-Pakete in der Umgebung verursacht beliebte HTTP-Kunden (Requests, urllib3, httpx, aiohttp) automatisch zu dekomprimieren, so dass eine Anwendung freigelegt werden kann, egal ob Ihr Code explizit Brotli importiert. Die Seiten der Pakete in PyPI sind auf https: / / pypi.org / Projekt / Brotli / und https: / / pypi.org / Projekt / brotlicffi /.

Reale Folgen: Je nach Anwendung und Abschwächung des Systems könnte ein Angreifer zu einer Denialisierung des Dienstes (Crash), zu einem filterempfindlichen Speicher oder im schlimmsten Fall eine Remote-Ausführung innerhalb des anfälligen Prozesses führen. Der operative Einfluss ist konkret: Updates pro Produkt, Neustart von Dienstleistungen und Containerrekonstruktion sind notwendig, da ein Prozess, der nicht neu gestartet wird, weiterhin die alte Version des Decoders im Speicher verwendet.

Spezifische Maßnahmen von Managern und Entwicklern (bestätigt und praktisch): (1) Aktualisieren so schnell wie möglich die Laufzeit oder die Buchhandlung zu den von jedem Projekt veröffentlichten parched Versionen und starten Sie die betroffenen Prozesse neu; in Containerumgebungen, bauen Sie die Bilder wieder auf, so dass die parched binär beim Start vorhanden ist. 2) Wenn Sie nicht sofort aktualisieren können, stoppen Sie die Annahme oder Verarbeitung unzuverlässig Brot: Ablehnung eingehender Anfragen, die Content-Encoding tragen: br bevor ein Proxy oder Parser versucht, den Körper zu dekomprimieren. 3) Für HTTP-Kunden, bei denen eine Verhaltenssteuerung möglich ist: Deaktivieren Sie Brotlis automatische Dekompression und deinstallieren Sie gegebenenfalls Brotli / Brotlicffi-Pakete in Python-Umgebungen, um gzip / deflate fall zu zwingen. Wichtig: Entfernen Sie "br" vom Akzept-Header - Encoding garantiert keinen Schutz - ein Server kann den Header ignorieren und mit Brotli reagieren -; daher ist die Empfehlung, die Antworten mit Content-Encoding explizit zu blockieren oder abzulehnen: br in der Eingabe / Ausgabe es steuert.

Spezifische Schritte nach Plattform (Status und Empfehlungen): Node.js und Bun: Update auf die offiziellen parcheed Versionen. In Node.js gibt es keine dokumentierte Workaround, um das Update zu ersetzen; Neustart der Laufzeit ist obligatorisch. Envoy / Istio: aktualisieren Sie auf Versionen, die den Brotli-Dekompressionsfilter korrigieren oder deaktivieren, wenn nicht erforderlich. Python: Entfernen Sie die Brotli- und Brotlicffi-Pakete aus der Umgebung, wenn Sie die geparchete Version nicht sofort installieren können; außerdem setzen Sie explizit HTTP-Kunden ein, um unkomprimierende Reaktionen zu vermeiden. Betriebssysteme und Pakete: die Distributionen korrigieren ihre Pakete zu verschiedenen Zeiten - zum Beispiel, Debian veröffentlichte einen Fix für brotli in Debian 13 am 23. Oktober in Version 1.1.0-2 + deb13u1 - aber überprüfen Sie die Politik seiner Festplatte und aktualisieren.

Warnungen und noch unsichere Elemente: Obwohl es private Beweise für die Codeausführung in einem bestimmten Gebäude von Node.js gibt, gibt es keine einfachen öffentlichen Explosionsnachweise, die auf allen Plattformen funktionieren. Die Gravity-Scores variieren zwischen den Lieferanten: Google hat eine kritische Note (CVSS 4.0 9.2) zugeordnet, während andere Projekte sie nach eigenem Kontext als hoch oder wichtig aufgelistet haben. Darüber hinaus können Unit-Analyse-Tools die Bedingung in Python-Umgebungen nicht automatisch erkennen, da die CVE auf das Brotli-Repository verweist und nicht ursprünglich auf die PyPI-Pakete; es wird daher empfohlen, manuell die installierten Versionen und die von den Projekten veröffentlichten Sicherheitseingänge zu überprüfen.

Kurz gesagt: der Vektor ist klar und das Mittel auch - Update und Neustart - aber die Fragmentierung des Ökosystems (jedes Produkt verpackt seine eigene Kopie des Decoders) erfordert einen koordinierten Aufwand von Administratoren, Entwicklern und Sicherheitsausrüstung. Für direkte technische Anleitungen und Referenzen siehe die Originalquellen des Brotli-Projekts in GitHub ( github.com / google / brotli) und die offiziellen Seiten der Python Pakete in PyPI ( Brot, Bronlicffi), zusätzlich zu den Sicherheitswarnungen ihrer Laufzeiten und Verteilungen.