VamiSec × Wiz
DE EN
Prüfung anfragen

Lagebild der VamiSec GmbH · · Mitglied der Wiz Partner Alliance

Brotli2Shell: Sind Ihre Systeme betroffen?

Auch bekannt als Node2Shell, HTTP2Shell und Broccoli2Shell · CVE-2026-111497

Am 21. Oktober 2026 wurde eine kritische Schwachstelle im Brotli-Decoder von Google bekannt: CVE-2026-111497. Das Kompressionsverfahren Brotli steckt in Node.js, .NET, Bun, Envoy, Istio, Python-Paketen und vielen weiteren Produkten. Wer präparierte Brotli-Daten einschleusen kann, beschädigt damit Prozessspeicher und kann im schlimmsten Fall Code ausführen, ohne Anmeldung. Als Mitglied der Wiz Partner Alliance prüft VamiSec kurzfristig, wo der verwundbare Decoder bei Ihnen läuft: von außen mit Wiz ASM, dem Wiz Red Agent und VamiRedteam, von innen über Konnektoren, die den tatsächlichen Versionsstand belegen.

Betroffenheitsprüfung anfragen Zum 7-Punkte-Plan

Blackbox von außen Agentlos von innen Nur mit schriftlicher Freigabe

1 Decodersteckt in Laufzeiten, Proxys, Datenbanken und Bibliotheken
9.2CVSS v4.0 laut Google, kritisch
8 Byteinterner Puffer, über dessen Ende der Decoder schreibt
91 %der Cloud-Umgebungen haben laut Wiz verwundbare Ressourcen
21.10.2026Fixes und Offenlegung mit dem Node.js-Sicherheitsrelease

Auf einen Blick

Der 7-Punkte-Plan gegen Brotli2Shell

Von außen nach innen: Machen Sie zuerst sichtbar, wo Brotli-Daten aus fremden Quellen entpackt werden, schirmen Sie diese Stellen ab und patchen Sie sie. Erst danach folgen die internen Systeme. Lieferkette, Nachprüfung und Dokumentation laufen von Tag 1 an mit.

  1. Außen · sofort

    Sichtbar machen

    Alle Komponenten erfassen, die Brotli entpacken: Node.js, Bun, .NET, Python-Pakete, Envoy und Istio, Datenbanken und Medienwerkzeuge. Internet-exponierte zuerst. Wiz: Cloud und Kubernetes agentlos, On-Prem per Sensor.

  2. Außen · sofort

    Brotli am Eingang abweisen

    Requests mit Content-Encoding: br an WAF, CDN oder Reverse Proxy abweisen, bevor ein Proxy oder Body-Parser sie entpackt. Brotli-Filter in Envoy und Istio abschalten.

  3. Außen · parallel

    Extern zuerst patchen

    Internet-exponierte Dienste und Dienste, die fremde URLs abrufen, auf die gefixten Versionen heben, Images neu bauen, Prozesse neu starten. Bis dahin Übergangsschutz.

  4. Erst wenn extern gepatcht

    Innen · danach

    Intern nachziehen

    Interne Dienste, Datenpipelines, Build-Umgebungen sowie Werkzeuge, die Brotli-haltige Dateien verarbeiten, schrittweise aktualisieren.

  5. Lieferkette · ab Tag 1

    Berichte einfordern

    SaaS-Anbieter, Hoster und Hersteller von Appliances, die nicht von sich aus informiert haben, schriftlich nach Betroffenheit, Patch-Stand und Nachweis fragen.

  6. Ergänzend · begleitend

    Nachprüfen und Spuren suchen

    Code und Images mit den Scannern von JFrog und Trail of Bits prüfen, Abstürze und Neustarts seit dem 21. Oktober 2026 auswerten, bei Hinweisen Zugangsdaten tauschen.

  7. Begleitend

    Dokumentieren und melden

    Inventar, Patch-Zeitpunkte und Lieferantenantworten festhalten, bei Hinweisen auf eine Ausnutzung die Meldepflichten nach NIS2, DSGVO, DORA und CRA prüfen.

Bei Punkt 1 und 6 unterstützen wir kurzfristig: Betroffenheitsprüfung von außen und innen.

Alle Schritte im Detail

Kurzantwort

Brotli2Shell ist einer von mehreren Namen für CVE-2026-111497, eine kritische Schwachstelle im Brotli-Decoder von Google, bewertet mit CVSS v4.0 9.2. Stößt der Decoder auf einen ungültigen Blockwechsel, meldet er fälschlich, er brauche mehr Eingabe, statt den Datenstrom als fehlerhaft abzuweisen. Der Decoder hängt deshalb weitere Bytes an einen internen Puffer von acht Byte an und schreibt über dessen Ende hinaus.

  • Folge: Wer präparierte Brotli-Daten einspeisen kann, beschädigt Prozessspeicher. Das reicht vom Absturz über das Auslesen von Speicher bis zur Codeausführung. Imperva hat Codeausführung gegen Node.js gezeigt.
  • Reichweite: Betroffen ist keine einzelne Anwendung, sondern eine Bibliothek, die in vielen Produkten steckt: Node.js, Bun, .NET, Python-Pakete, Envoy, Istio, Java-Bibliotheken, Datenbanken wie ClickHouse und DuckDB, Apache Arrow und FFmpeg. Angreifbar ist ein System, wenn es Brotli-Daten aus nicht vertrauenswürdiger Quelle entpackt: eingehende Requests, Antworten fremder Server oder Dateien.
  • Abhilfe: Aktualisieren Sie jede betroffene Komponente auf ihre gefixte Version, bei Brotli selbst 1.0.10, 1.1.1 oder 1.2.1, bei Node.js 22.23.4, 24.22.1 oder 26.12.1. Bauen Sie Images neu und starten Sie die Prozesse neu. Brotli am Eingang abzuweisen überbrückt nur.
  • Reihenfolge: Von außen nach innen. Machen Sie zuerst sichtbar, welche Systeme Brotli aus dem Internet annehmen oder fremde Inhalte abrufen, schirmen Sie sie ab und patchen Sie sie parallel, danach die internen. Lieferanten, die nicht von sich aus informiert haben, bitten Sie um einen schriftlichen Bericht.
  • Prüfung: VamiSec ermittelt als Mitglied der Wiz Partner Alliance kurzfristig, welche Systeme aus dem Internet erreichbar sind, und mit der Innensicht auch, wo der verwundbare Decoder tatsächlich läuft.

Veröffentlicht: Aktualisiert: Autor: Valeri Milke, VamiSecPrimärquellen: CVE-Eintrag von Google, Node.js-AdvisoryAnalyse von Wiz: Broccoli2Shell

01 · Sofortmaßnahmen

Was jetzt zu tun ist

Die Reihenfolge folgt dem Risiko, von außen nach innen. Außen heißt bei Brotli2Shell: überall, wo Brotli-Daten aus fremder Hand ankommen. Das sind eingehende Requests, Antworten fremder Server, die Ihre Dienste abrufen, und hochgeladene Dateien. Machen Sie diese Stellen zuerst sichtbar, schirmen Sie sie ab und patchen Sie sie parallel, danach die internen Systeme. Die Lieferkette binden Sie von Anfang an ein.

  1. Außen · sofortPunkt 1

    Sichtbarkeit schaffen

    Erfassen Sie, wo Brotli entpackt wird. Das ist schwieriger als bei einem einzelnen Produkt, weil der Decoder meist fest eingebaut ist: in der Laufzeit (Node.js, Bun, .NET), als Bibliothek des Betriebssystems (libbrotli), als Python-Paket mit eigener Kopie des C-Codes, in Proxys wie Envoy und Istio, in Datenbanken und Analysewerkzeugen sowie in Medien- und Dokumentwerkzeugen. Die Paketliste des Betriebssystems allein reicht deshalb nicht. Durchsuchen Sie vorhandene SBOMs nach brotli, brotlicffi, brotli4j und nach Node.js-, Bun- und .NET-Laufzeiten. Markieren Sie zuerst, was aus dem Internet erreichbar ist oder Inhalte von fremden Servern abruft.

    Für die volle Sichtbarkeit in Ihrer eigenen Umgebung eignet sich Wiz: Cloud-Konten und Kubernetes-Cluster agentlos über Konnektoren, On-Prem-Systeme über den Wiz Runtime Sensor. Zusammen mit der Außensicht zeigt das, welche verwundbaren Workloads tatsächlich aus dem Internet erreichbar sind. Statisch gebaute Programme und Appliances prüfen Sie zusätzlich. Systeme, die Hoster oder SaaS-Anbieter für Sie betreiben, sieht Wiz von innen nicht. Deren Stand klären Sie über die Lieferkette.

  2. Außen · sofortPunkt 2

    Brotli am Eingang abweisen

    Weisen Sie Requests mit dem Header Content-Encoding: br an WAF, CDN oder Reverse Proxy ab, bevor ein Proxy, eine Middleware oder ein Body-Parser sie entpackt. Das gilt auch für Direktzugriffe auf den Origin-Server und für alternative Routen. Browser senden Request-Bodies üblicherweise unkomprimiert. Brotli-komprimierte Requests stammen meist von eigenen Clients oder Integrationen. Prüfen Sie Ihre Logs, bevor Sie blockieren.

    Schalten Sie in Envoy und Istio die Brotli-Decompressor-Filter für Requests und Antworten ab. Ohne Filter reicht der Proxy komprimierte Daten unter Umständen unverändert an das Backend weiter. Dessen Decoder muss dann ebenfalls geschützt sein. Die WAF verschafft Zeit, ersetzt aber keinen Patch, und sie schützt nicht die ausgehende Richtung (Übersicht der Anbieter).

  3. Außen · parallelPunkt 3

    Externe Systeme zuerst patchen

    Aktualisieren Sie parallel die Systeme, die aus dem Internet erreichbar sind oder fremde Inhalte abrufen, auf die gefixten Versionen aus der Versionstabelle. Bauen Sie Container-Images neu, aktualisieren Sie Lockfiles und starten Sie alle Prozesse neu. Programme, die den Decoder statisch einbinden oder eine eigene Kopie mitbringen, brauchen ein Update des jeweiligen Produkts. Ein Systemupdate von libbrotli hilft ihnen nicht.

    Node.js-Linien ohne Support, etwa 20 und älter, erhalten kein Update. Migrieren Sie auf 22, 24 oder 26 oder nutzen Sie einen Anbieter für erweiterten Support. Prüfen Sie nach dem Neustart, dass wirklich die neue Version läuft, etwa mit node -v im laufenden Container.

  4. Außen · bis zum PatchPunkt 3

    Übergangsschutz

    Wo Sie nicht sofort patchen können, nehmen Sie dem Decoder die fremden Daten weg. Eingehend weisen Sie Brotli wie in Punkt 2 ab oder schalten die Request-Dekompression in der Anwendung ab. Ausgehend schalten Sie die automatische Brotli-Dekompression in HTTP-Clients ab oder weisen Brotli-Antworten vor dem Entpacken ab. Nur br aus dem Header Accept-Encoding zu streichen genügt nicht: Ein bösartiger Server kann trotzdem Brotli senden, und viele Clients entpacken nach dem Header der Antwort. Die Verarbeitung nicht vertrauenswürdiger Brotli-Dateien setzen Sie aus, bis der Decoder gepatcht ist. Details stehen unter Übergangsmaßnahmen.

  5. Erst wenn die Systeme, die fremde Brotli-Daten verarbeiten, gepatcht und nicht mehr angreifbar sind, geht es nach innen.
  6. Innen · schrittweisePunkt 4

    Intern nachziehen

    Patchen Sie danach schrittweise interne Dienste, Datenpipelines mit Parquet- oder Arrow-Daten, Datenbanken, Build-Pipelines, Entwicklungsumgebungen und Desktop-Werkzeuge, die Brotli-haltige Dateien verarbeiten. Ein Patch auf dem Host schützt keine Container, die ihre eigene Laufzeit mitbringen.

  7. Lieferkette · ab Tag 1Punkt 5

    Berichte einfordern

    Brotli steckt in SaaS-Diensten, API-Gateways, Service-Meshes, Appliances und eingebetteten Produkten. Lieferanten, die nicht von sich aus informiert haben, bitten Sie schriftlich um einen Bericht: Betroffen? Gepatcht? Bis wann? Mit welchem Nachweis? Fremde Systeme prüfen Sie nicht selbst. Für Einrichtungen unter NIS2 und Finanzunternehmen unter DORA gehört das Steuern von Lieferkettenrisiken ohnehin zu den Pflichten.

  8. ErgänzendPunkt 6

    Selbst nachprüfen

    Mit den Open-Source-Scannern von JFrog und Trail of Bits durchsuchen Sie Quellcode, Abhängigkeiten, Images und Binärdateien nach dem verwundbaren Decoder und nach Aufrufen, die ihn erreichen. Die Werkzeuge greifen nichts an, sie lesen nur. Ein Treffer belegt mögliche Betroffenheit, aber noch keine Ausnutzbarkeit. Kein Treffer belegt nicht, dass alle Pfade erfasst sind.

  9. BegleitendPunkt 6

    Auf Angriffsspuren prüfen

    Werten Sie Abstürze, Speicherzugriffsfehler und unerklärliche Neustarts mindestens seit dem 21. Oktober 2026 aus, dem Tag der Offenlegung. Die Merkmale stehen im Abschnitt Erkennung.

  10. Bei HinweisenPunkt 6

    Zugangsdaten tauschen

    Die Schwachstelle kann Prozessspeicher offenlegen, und darin liegen oft Tokens, API-Schlüssel und Passwörter. Gibt es Anzeichen eines Angriffs vor dem Patch, rotieren Sie diese Geheimnisse und machen Sie Sitzungen ungültig.

  11. BegleitendPunkt 7

    Dokumentieren und Meldepflichten prüfen

    Halten Sie Inventar, Patch-Zeitpunkte, Lieferantenantworten und Befunde fest. Bei Hinweisen auf eine Ausnutzung prüfen Sie die Meldepflichten nach NIS2, DSGVO, DORA oder CRA.

Übergangsmaßnahmen · eingehend

Requests mit Brotli abweisen

  • Am Rand des Netzes: Requests mit Content-Encoding: br mit HTTP 415 abweisen, an WAF, CDN, Load Balancer oder Reverse Proxy. In nginx etwa: if ($http_content_encoding ~* "br") { return 415; }
  • Envoy und Istio: Brotli-Decompressor-Filter entfernen, für Requests und Antworten. Danach prüfen, ob das Backend die Daten selbst entpackt.
  • ASP.NET Core: in der Request Decompression Middleware den Brotli-Anbieter entfernen, etwa mit options.DecompressionProviders.Remove("br").
  • Node.js: Middleware, die Request-Bodies entpackt, für br abschalten oder solche Requests vorher abweisen. Bei body-parser und Express weist inflate: false komprimierte Bodies grundsätzlich ab.
  • Datenbanken mit HTTP-Schnittstelle wie ClickHouse: Zugriff aus dem Internet sperren, bis ein gefixtes Release vorliegt.
Übergangsmaßnahmen · ausgehend und Dateien

Fremde Brotli-Daten nicht entpacken

  • HTTP-Clients, die fremde URLs abrufen, ohne automatische Brotli-Dekompression betreiben. In .NET etwa AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate statt All.
  • Abrufe nicht vertrauenswürdiger URLs über einen Proxy leiten, der Antworten mit Content-Encoding: br abweist, oder solche Abrufe aussetzen. Das betrifft Webhooks, Link-Vorschauen, Crawler, Feed-Leser und KI-Agenten mit Web-Werkzeugen.
  • br nur aus Accept-Encoding zu streichen reicht nicht, ein bösartiger Server kann Brotli trotzdem senden.
  • Python: Requests, urllib3, HTTPX und aiohttp entpacken Brotli nur, wenn das Paket brotli oder brotlicffi installiert ist. Bis zum Update können Sie diese Pakete entfernen, sofern nichts anderes sie braucht.
  • Hochgeladene oder fremde Dateien mit Brotli-Anteilen, etwa JPEG XL oder Parquet, bis zum Patch nicht automatisch verarbeiten.

Diese Maßnahmen verkleinern die Angriffsfläche, ersetzen aber den Patch nicht. Prüfen Sie jede Änderung mit Ihrer Anwendung. Wer Brotli abweist, kann legitime Integrationen stören.

WAF und CDN: wer was bereitstellt

Mehrere Anbieter haben Regeln gegen die eingehende Richtung veröffentlicht. Alle betonen, dass sie den Patch nicht ersetzen. Keine WAF schützt die ausgehende Richtung: Was Ihre Dienste von fremden Servern abrufen und entpacken, sieht sie nicht. Fragen Sie Ihren Hoster oder CDN-Anbieter, welche Regeln für Ihre Systeme gelten, und ob sie blockieren oder nur protokollieren.

Schutzregeln der Anbieter für eingehende Requests, Stand 27.10.2026. Kein Ersatz für den Patch.
AnbieterSchutzAutomatisch aktiv?
CloudflareManaged Rule „Brotli - Request Content-Encoding - CVE:CVE-2026-111497“ seit 25.10., erkennt Brotli im Request, nicht im Accept-Encoding. Dazu eine Regel für den Bildoptimierer von Next.js, die im Blockiermodus optimierte Bilder verhindern kannnur protokollieren Standard ist „Log“, auf Blockieren umstellen
VercelWAF-Regeln für die eingehende Richtung auf allen Projekten. Auf noch ungepatchten Laufzeiten fordern ausgehende fetch()- und node:http-Clients nach einem Redeploy kein Brotli mehr an und weisen Brotli-Antworten ab. Projekte mit Node.js 20 müssen auf 22 oder 24 wechselnja eingehend; ausgehend erst nach Redeploy
ImpervaEigene WAF-Regeln seit 22.10., als Ergänzung zum Patchnicht angegeben

Akamai nennt in seiner Analyse keine WAF-Regel, empfiehlt aber für Express und body-parser inflate: false, komprimierte Bodies werden dann mit HTTP 415 abgewiesen. Für AWS WAF, Azure WAF und Fastly haben wir bis zum 27.10. keine CVE-spezifische Regel gefunden, die wir belegen können. Eine eigene Regel, die Requests mit br im Header Content-Encoding blockiert, lässt sich dort wie bei jeder WAF anlegen. Verkehr, der direkt zum Origin-Server geht, umgeht jede WAF.

02 · Überblick

Was hinter Brotli2Shell steckt

Brotli ist ein Kompressionsverfahren von Google, 2016 in RFC 7932 beschrieben. Webserver und CDNs komprimieren damit Webseiten, Browser und HTTP-Clients entpacken sie, erkennbar am Kürzel br im Header Content-Encoding. Weil das Verfahren so verbreitet ist, haben Laufzeiten, Proxys, Datenbanken und Bibliotheken den Decoder in C von Google übernommen, oft als feste Kopie im eigenen Quellcode.

Genau dieser Decoder enthält den Fehler. Gefunden haben ihn Khai Tran und Sylvie Mayer von OpenAI Codex Security. Google führt die Schwachstelle als zuständige CVE-Vergabestelle (CNA) unter CVE-2026-111497 und hat die Brotli-Versionen 1.0.10, 1.1.1 und 1.2.1 mit Fix veröffentlicht. Offengelegt wurde sie am 21. Oktober 2026 mit dem Sicherheitsrelease von Node.js. Den Fix in Node.js haben Matteo Collina und Antoine du Hamel umgesetzt.

Am 22. Oktober zeigte Ron Masas vom Imperva Red Team, dass sich der Fehler gegen Node.js bis zur Codeausführung ausnutzen lässt, und nannte ihn Node2Shell. Weil nicht nur Node.js betroffen ist, kamen weitere Namen hinzu: ab dem 23. Oktober HTTP2Shell, dann Broccoli2Shell, zurückgehend auf den Vorschlag des Sicherheitsforschers Juliano Rizzo, die Lücke „Broccoli“ zu nennen, genutzt von der unabhängigen Seite broccoli2shell.com und von Wiz, sowie am 25. Oktober Brotli2Shell bei JFrog, den auch Tenable übernommen hat. JFrog hält Node2Shell und HTTP2Shell für zu eng, weil der Fehler im Brotli-Decoder selbst steckt, den Software über Sprachen und Produktkategorien hinweg wiederverwendet. Gemeint ist immer dieselbe CVE.

Die Reichweite zeigen die Tests von JFrog: Ein einzelner Request mit Content-Encoding: br brachte einen ClickHouse-Server zum Absturz. Eine präparierte JPEG-XL-Datei brachte FFmpeg über die Bibliothek libjxl zum Absturz, an der Adresse 0x414141414141, also mit Angreiferdaten in einem Zeiger. Codeausführung hat JFrog dort nicht gezeigt. Für .NET nennt JFrog BrotliStream, die automatische Dekompression von HttpClient und die Request-Dekompression von ASP.NET Core als Wege zum Decoder und zeigte einen Absturz mit einem zweistufigen Brotli-Strom. Laut Microsoft sind die beiden Dekompressionswege standardmäßig aus. Apache Arrow geriet mit 534 Byte Eingabe in eine Endlosschleife. Laut Wiz haben 91 Prozent der Cloud-Umgebungen Ressourcen, die für CVE-2026-111497 verwundbar sind, und 82 Prozent betreiben öffentlich erreichbare Node.js-Instanzen.

Codeausführung ohne Anmeldung

Imperva hat Codeausführung gegen das offizielle Node.js-Image 24.22.0 für Linux auf ARM64 demonstriert: über eine Antwort, die fetch() entpackt, und über Express 5 mit body-parser 2, das Request-Bodies entpackt. Es brauchte mehrere Versuche. Der Code läuft mit den Rechten des betroffenen Prozesses. Ein einfacher Node.js-HTTP-Server entpackt eingehende Bodies laut Imperva nicht von selbst.

Eingehend und ausgehend

Angreifbar sind Server, die Brotli-komprimierte Requests entpacken, und ebenso Clients, die Antworten fremder Server entpacken. Ein Dienst, der eine vom Angreifer gewählte URL abruft, kann so angegriffen werden, ohne selbst aus dem Internet erreichbar zu sein.

Auch ohne HTTP

Brotli steckt auch in Dateiformaten. JPEG XL kann Brotli-komprimierte Metadaten enthalten, Parquet-Dateien Brotli-komprimierte Daten. Wer solche Dateien aus fremder Hand verarbeitet, erreicht den Decoder ohne jede Netzwerkverbindung zum Angreifer.

03 · Schwachstelle

Eine CVE, viele Wege zum Decoder

Google ist die zuständige CVE-Vergabestelle und beschreibt die Schwachstelle als Schreibzugriff außerhalb der Puffergrenzen im Brotli-Decoder. Welche Wege zum Decoder bei Ihnen offenstehen, hängt davon ab, welche Software ihn einbindet und welche Daten sie entpackt.

Titel im CVE-Eintrag: „Out-of-Bounds Write in Google Brotli Decoder“ · CNA Google

CVE-2026-111497: Schreibzugriff über das Pufferende im Brotli-Decoder

Der Fehler steckt in der Datei c/dec/decode.c des C-Decoders. Ein Angreifer ohne Anmeldung kann mit einem präparierten Brotli-Datenstrom den benachbarten Zustand des Decoders im Speicher beschädigen. Mögliche Folgen sind laut CVE-Eintrag das Auslesen von Speicher, ein Denial of Service und möglicherweise die Ausführung beliebigen Codes, auf allen Plattformen.

  • Betroffen: Brotli 1.0.3 bis vor 1.0.10, 1.1.0 bis vor 1.1.1 und 1.2.0 bis vor 1.2.1, also alle Versionen von 1.0.3 bis 1.2.0 ohne Fix
  • Behoben: Brotli 1.0.10, 1.1.1 und 1.2.1, dazu Updates der Produkte, die den Decoder mitbringen
  • Fehlerklassen: Schreibzugriff außerhalb der Puffergrenzen (CWE-787) und ein nicht geprüfter Rückgabewert (CWE-252)
  • Gefunden von: Khai Tran und Sylvie Mayer, OpenAI Codex Security

CVSS v4.0 9.2CWE-787 · CWE-252CAPEC-100

Zum CVSS-Wert: Google bewertet die Schwachstelle mit 9.2 nach CVSS v4.0 (Vektor AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H). Der Angriff läuft über das Netz, ohne Rechte und ohne Mitwirkung eines Nutzers. AT:P bedeutet, dass eine Voraussetzung erfüllt sein muss: Das Zielsystem muss Brotli-Daten des Angreifers entpacken. Node.js stuft die Lücke nach eigenem Schema als „hoch“ ein. Die US-Behörde CISA hat am 23. Oktober in ihrer Einordnung festgehalten: keine bekannte Ausnutzung, nicht automatisierbar, vollständige technische Wirkung.

Wie Angreifer den Decoder erreichen

Angriffswege und demonstrierte Folgen (Quellen: Node.js, Imperva, JFrog; Stand 27.10.2026)
WegTypische StellenDemonstriert
Eingehende Requests mit Content-Encoding: br Middleware und Body-Parser, die Request-Bodies entpacken, ASP.NET Core Request Decompression, Brotli-Filter in Envoy und Istio, HTTP-Schnittstellen von Datenbanken Codeausführung gegen Node.js über Express 5 und body-parser 2 (Imperva), Absturz eines ClickHouse-Servers mit einem Request von 23 MB (JFrog)
Antworten fremder Server fetch() in Node.js, HttpClient in .NET mit automatischer Dekompression, Python-Clients wie Requests, HTTPX oder aiohttp mit installiertem Brotli-Paket, Crawler, Webhooks, Link-Vorschauen, KI-Agenten mit Web-Werkzeugen Codeausführung gegen Node.js über eine Antwort, die fetch() entpackt (Imperva)
Dateien und Datenformate JPEG XL über libjxl, etwa in FFmpeg, Parquet-Daten in Apache Arrow, .br-Dateien, Brotli-Kommandozeile Absturz von FFmpeg mit präpariertem JPEG XL, Endlosschleife in Apache Arrow (JFrog)
Direkte Nutzung im Code node:zlib mit Brotli-Funktionen, BrotliStream in .NET, die Python-Pakete brotli und brotlicffi, Brotli4j in Java Speicherzugriffsfehler mit einem zweistufigen Brotli-Strom in .NET (JFrog)

Ob ein Treffer ausnutzbar ist, hängt von der Software, dem Eingabeweg und der Umgebung ab. JFrog betont: Dass eine verwundbare Version vorhanden ist, beweist noch keine Ausnutzbarkeit aus der Ferne. Umgekehrt ist sie ohne Prüfung des Eingabewegs auch nicht ausgeschlossen.

04 · Technischer Hintergrund

So wird aus komprimierten Daten ein Angriff

Der Decoder arbeitet als Strom: Er bekommt Daten in Stücken und merkt sich, wo er steht. Fehlen ihm Bits, um ein Symbol zu Ende zu lesen, sammelt er die nächsten Bytes in einem kleinen internen Puffer. Genau diese Unterscheidung zwischen „fehlerhaft“ und „noch nicht vollständig“ ging bei einem bestimmten Fehler verloren.

Eingabe

Präparierter Strom

Der Angreifer liefert Brotli-Daten mit einem unmöglichen Blockwechsel, etwa per Request, als Antwort eines Servers oder in einer Datei.

Fehldeutung

„Brauche mehr Eingabe“

Die Funktion DecodeBlockTypeAndLength() meldet den Fehler mit demselben Wert wie fehlende Eingabe. Der Decoder bricht deshalb nicht ab.

Puffer

Acht Byte laufen über

Bei jedem Versuch hängt der Decoder ein weiteres Byte an seinen internen Puffer von acht Byte an. Ohne wirksame Grenzprüfung schreibt er über dessen Ende hinaus.

Wirkung

Speicher in Angreiferhand

Das neunte Byte überschreibt laut Analysen die Längenangabe des Puffers. Damit lassen sich weitere Schreibzugriffe steuern, bis zum Absturz, Speicherleck oder Codeausführung.

Vereinfachte Darstellung nach dem Node.js-Advisory, dem Fix im Brotli-Quellcode und den Analysen von Cynet und JFrog. Blau: regulärer Zustand, gestreift: fehlgedeuteter Zustand, orange: überschriebener Speicher.
Ursache · CWE-252

Ein Rückgabewert mit zwei Bedeutungen

In den betroffenen Versionen lieferte DecodeBlockTypeAndLength() bei einem unmöglichen Blockwechsel BROTLI_FALSE zurück. Derselbe Wert bedeutete an dieser Stelle aber auch „zu wenig Eingabe“. Der Streaming-Decoder behandelte einen dauerhaften Formatfehler deshalb wie eine vorübergehende Pause und fragte immer neue Bytes an.

Folge · CWE-787

Der überlaufende Zwischenpuffer

Für Symbole, die über Eingabegrenzen hinweg reichen, sammelt der Decoder Bytes in einem Puffer von acht Byte. Laut Node.js hing der Decoder bei jedem Versuch weitere Eingabebytes an. Laut Cynet fehlt in Release-Builds eine wirksame Grenzprüfung. Ab dem neunten Byte landet Angreiferinhalt im angrenzenden Speicher. Ob daraus Codeausführung wird, hängt vom Speicherlayout des jeweiligen Programms ab.

Fix · Brotli 1.0.10, 1.1.1, 1.2.1

Ein eigener Fehlercode für den Blockwechsel

Der Fix trägt den Titel „Detect and report invalid stream earlier“. Die betroffenen Funktionen geben jetzt einen echten Fehlercode zurück. Für den unmöglichen Blockwechsel gibt es den neuen Code BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH, und die Aufrufer reichen ihn weiter. Der Decoder bricht damit sofort ab, statt auf weitere Eingabe zu warten.

Patch-Lücke

Warum der Fix früher sichtbar war

Der Fix liegt seit dem 27. Februar 2026 öffentlich im Brotli-Quellcode, Releases mit Fix kamen erst am 21. Oktober. Projekte, die den aktuellen Quellstand übernehmen, waren früher geschützt: Die heutigen Quellstände von Chromium und Firefox nutzen Brotli-Revisionen von März bzw. April 2026 mit dem Fix, und Envoy lieferte ihn am 6. Oktober ohne Hinweis aus. Wer feste Releases einbindet, blieb bis Oktober verwundbar, und wer Code-Änderungen gezielt auswertet, konnte die Stelle früher finden.

05 · Betroffenheit

Welche Versionen und Produkte betroffen sind

Entscheidend ist, welche Kopie des Decoders ein Programm tatsächlich nutzt. Viele Produkte bringen ihre eigene mit und brauchen deshalb ein eigenes Update. Distributionen und Hersteller portieren den Fix zudem oft zurück, ohne die Versionsnummer zu ändern. Die Versionsnummer allein entscheidet deshalb nicht, maßgeblich sind die Hinweise des jeweiligen Herstellers.

Komponenten mit dem Brotli-Decoder, Fix-Stand laut Herstellern und Advisories (Stand 27.10.2026)
KomponenteVerwundbarBehoben inHinweis
Google Brotli (C, libbrotli)1.0.3 bis 1.2.01.0.10 · 1.1.1 · 1.2.1Releases vom 21.10. Distributionen portieren zurück: Debian (DSA-6582-1, DLA-4855-1), Ubuntu (USN-8956-1), Alpine, Amazon Linux (ALAS2023-2026-3334), Red Hat für RHEL 8 und 9 (RHSA-2026:90501, RHSA-2026:90495). Für RHEL 10 und SLES 15/16 stand der Fix am 27.10. noch aus.
Node.js22.x vor 22.23.4, 24.x vor 24.22.1, 26.x vor 26.12.1 und alle Linien ohne Support22.23.4 · 24.22.1 · 26.12.1Node.js 20 und älter erhalten keinen Fix. Node.js aus Distributionspaketen nutzt teils die Systembibliothek libbrotli, dann hilft deren Update. Laut ELLIO zeigt process.versions.brotli bei gepatchten und verwundbaren Builds dieselbe Version. Maßgeblich ist die Node.js-Version.
Bun1.0.21 bis 1.4.31.4.4fetch() entpackt Brotli standardmäßig. Mit bun build --compile erstellte Programme neu bauen.
.NET8.0.0 bis 8.0.32, 9.0.0 bis 9.0.21, 10.0.0 bis 10.0.13, Vorabversionen von .NET 118.0.33 · 9.0.22 · 10.0.14Updates seit 25.10., .NET 11 ab RC 3. .NET Framework ist laut Microsoft nicht betroffen. NativeAOT- und eigenständig veröffentlichte Anwendungen neu veröffentlichen.
Python: brotli, brotlicffiab 1.0.3, vor 1.2.1 bzw. 1.2.1.01.2.1 · 1.2.1.0Requests, urllib3, HTTPX und aiohttp entpacken Brotli automatisch, sobald eines der Pakete installiert ist.
Envoyvor 1.36.12, 1.37.8, 1.38.6 und 1.39.31.36.12 · 1.37.8 · 1.38.6 · 1.39.3 · 1.40.0Nur mit konfiguriertem Brotli-Decompressor. 1.36.12, 1.37.8, 1.38.6 und 1.39.3 erschienen schon am 06.10., 1.40.0 am 13.10., jeweils ohne Hinweis in den Release Notes.
Istio1.29.0 bis 1.29.8, 1.30.0 bis 1.30.5, 1.31.0 bis 1.31.11.29.9 · 1.30.6 · 1.31.2Nur mit aktivierter Brotli-Dekompression, etwa über einen EnvoyFilter.
Java: Brotli4jbis 1.23.01.24.0Alle native-Artefakte mit aktualisieren. Der Encoder ist nicht betroffen.
Go: andybalholm/brotlivor 1.2.71.2.7Reine Go-Portierung mit demselben Logikfehler. Go prüft Speichergrenzen selbst, eine Speicherkorruption wie in C ist dort nicht belegt.
PHP für WindowsBuilds vor dem 26.10.8.5.12-1 · 8.4.27-1 · 8.3.36-1 · 8.2.35-1Erreichbar über die cURL-Erweiterung mit automatischer Dekompression, die standardmäßig aus ist.
ClickHouseBuilds mit Brotli 1.2.0Fix gemergt, Release offenFix am 25.10. gemergt, Backports angekündigt. HTTP-Schnittstelle bis dahin nicht aus dem Internet erreichbar machen.
libjxl, FFmpeglibjxl mit Brotli vor 1.2.1Fix gemergt, Release offenFix in libjxl am 24.10. gemergt. FFmpeg ist über libjxl betroffen. JPEG XL aus fremder Hand bis dahin nicht verarbeiten.
DuckDBmitgelieferte Brotli-Kopie 1.1.0kein FixFix noch in Arbeit. Der Pull Request mit dem Fix stuft die Dringlichkeit als gering ein, weil DuckDB von vertrauenswürdigen Dateien ausgeht.
Apache Arrow, pyarrowmitgelieferte Brotli-Kopie 1.0.9kein FixParquet- und IPC-Daten. JFrog löste mit 534 Byte eine Endlosschleife aus.
Chrome, Firefoxaktuelle Quellstände nichtQuellstände mit Brotli-Revisionen von März bzw. April 2026Ab welcher Browser-Version der Fix ausgeliefert wurde, ist nicht veröffentlicht. Browser aktuell halten. Red Hat führt Firefox-Pakete noch als betroffen.
nginx (ngx_brotli), Apache (mod_brotli)nicht über das Modulnicht nötigDie Module komprimieren nur Antworten, der Decoder bleibt ungenutzt. Die Anwendung dahinter kann trotzdem betroffen sein.

Weitere Produkte: Deno nutzt eine Brotli-Implementierung in Rust und hat kein Advisory veröffentlicht. Electron 45.0.0 bringt Node.js 24.22.0 mit, also eine Version vor dem Fix, und auch die Linien 42 bis 44 enthalten Node.js-Versionen vor dem Fix. Fragen Sie die Hersteller Ihrer Electron-Anwendungen nach dem Stand. Die Rust-Pakete brotli und brotli-decompressor haben am 25.10. ihre Fehlerbehandlung angeglichen, eine Speicherkorruption wie in C ist dort nicht bekannt. Eine laufend gepflegte Übersicht weiterer Produkte führt die unabhängige Seite broccoli2shell.com.

Wo Brotli oft unbemerkt entpackt wird

  • Laufzeiten: Node.js und Bun bringen den Decoder mit, ebenso .NET. Das gilt auch für Programme, die eine solche Laufzeit eingebaut haben, etwa Desktop-Anwendungen und Kommandozeilenwerkzeuge auf Node.js-Basis.
  • HTTP-Clients, die Antworten automatisch entpacken: fetch() in Node.js, HttpClient in .NET mit aktivierter Dekompression und Python-Clients, sobald das Paket brotli oder brotlicffi installiert ist
  • Server und Frameworks mit Request-Dekompression, etwa Middleware in Node.js oder die Request Decompression Middleware von ASP.NET Core
  • Proxys und Service-Meshes: Envoy und Istio mit aktivem Brotli-Decompressor, API-Gateways auf Envoy-Basis
  • Datenbanken und Analyse: ClickHouse, DuckDB und Apache Arrow bringen eigene Brotli-Kopien mit. Für sie lag laut JFrog und Cynet am 26. Oktober noch kein gefixtes Release vor.
  • Medien und Dateien: FFmpeg und andere Programme mit libjxl für JPEG XL, Werkzeuge für .br-Dateien
  • Java und Go: Brotli4j bringt native Bibliotheken mit, das Go-Paket andybalholm/brotli ist eine Portierung des C-Codes
  • Appliances und eingebettete Produkte, die Brotli fest einbauen. Hier hilft nur ein Update des Herstellers.

Version oder Ausgabe des Versionsbefehls einfügen. Läuft vollständig im Browser, es wird nichts übertragen. Ersetzt keine Prüfung aller Instanzen und keine Herstellerhinweise.

Versionen schnell inventarisieren

Diese Befehle verändern nichts an Ihren Systemen, einige laden aber Metadaten oder Images aus dem Netz. Sie helfen bei einer ersten Bestandsaufnahme, ersetzen aber keine vollständige Inventur.

# Laufzeiten: Node.js, Bun und .NET (Runtime-Versionen, nicht SDK)
node -v
bun --version
dotnet --list-runtimes

# Python: Brotli-Pakete der aktiven Umgebung
python -m pip show brotli brotlicffi

# Systembibliothek libbrotli und Changelog auf die CVE prüfen
dpkg -l | grep -i brotli                                     # Debian/Ubuntu
rpm -qa | grep -i brotli                                     # RHEL/Alma/Rocky/SUSE
apk info -vv | grep -i brotli                                # Alpine
apt-get changelog libbrotli1 | grep -E "CVE-2026-111497"     # Paketnamen anpassen
rpm -q --changelog brotli | grep -E "CVE-2026-111497"         # RHEL/SUSE

# Proxys und Service-Mesh
envoy --version
istioctl version

# Abhängigkeiten in Go- und Java-Projekten
go list -m all | grep -i andybalholm/brotli
mvn dependency:tree | grep -i brotli4j

# Mitgebrachte Decoder-Kopien in Programmen finden (Indiz, kein Beweis)
grep -rlas "BrotliDecoderDecompressStream" /usr/lib /usr/local /opt /app 2>/dev/null

# Container-Image: Node.js-Version aus den Metadaten (offizielle node-Images setzen NODE_VERSION)
docker image inspect --format '{{range .Config.Env}}{{println .}}{{end}}' <image> | grep NODE_VERSION

# Kubernetes: Pods mit typischen Images finden
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | grep -i -E "node|bun|dotnet|aspnet|envoy|istio|clickhouse|duckdb|ffmpeg|python"
Erkennung · Open Source · nur lesend

Prüfen mit den Scannern von JFrog und Trail of Bits

Anders als bei vielen anderen Lücken gibt es für Brotli2Shell Werkzeuge, die nichts angreifen: Sie suchen in Quellcode, Abhängigkeiten, Images und Binärdateien nach dem verwundbaren Decoder und nach Aufrufen, die ihn erreichen. Damit eignen sie sich für CI-Pipelines und Registries.

  • JFrog (jfrog/vulnerability_scanners, Ordner brotli2shell_cve_2026_111497): sucht in JavaScript, Python, nativen ELF-Binärdateien und Aufrufen der Brotli-Kommandozeile nach Aufrufen, die den Decoder erreichen. Versionen und Patch-Stand prüft es nicht.
  • Trail of Bits (trailofbits/brotli-checker): erkennt potenziell verwundbaren Brotli-Quellcode und Binärdateien, prüft ausgewählte Decoder-Aufrufe und Anwendungspfade und findet Aufrufstellen im Quellcode. Laut JFrog garantiert das Werkzeug nicht, jeden Pfad zu finden.
  • node2shell-detect (shivrajem/node2shell-detect): inventarisiert installierte und laufende Node.js- und Bun-Laufzeiten und vergleicht sie mit den gefixten Releases. Anwendungscode, eingebettete Node.js-Versionen und eigene Brotli-Kopien prüft es nicht.
JFrog-Scanner Trail of Bits brotli-checker

Vorsicht bei Exploit-Code

  • Auf GitHub kursieren mehrere Exploits. Laut ihren Autoren und laut broccoli2shell.com gelingt Codeausführung meist nur unter abgestimmten Bedingungen, sonst stürzt der Prozess ab. Fremden Exploit-Code führen Sie nur in isolierten Umgebungen aus, er kann selbst Schadcode enthalten.
  • Aktive Tests mit präparierten Brotli-Daten können Prozesse zum Absturz bringen. Testen Sie nur eigene oder freigegebene Systeme, bei produktiven Systemen im Wartungsfenster.
  • Gleichen Sie jeden Treffer mit Version, Paketstand und Herstellerhinweis ab.
VamiSec unterstützt

Analyse, Recon und Attack Surface Management

Wir setzen die Scanner in Ihren Pipelines und Registries ein, werten die Ergebnisse aus und trennen echte Treffer von Fehlalarmen. Ihre externe Angriffsfläche erfassen wir dabei mit VamiRedteam. Die agentische Plattform kartiert Domains, Subdomains, Hosts und exponierte Dienste und arbeitet nur im freigegebenen Umfang: mit signierter Autorisierung, harter Grenze am Scope und lückenlosem Audit-Log.

Analyse anfragen

06 · Erkennung

Woran Sie einen Angriff erkennen können

Für Brotli2Shell gibt es noch keine allgemein anerkannten Angriffsmerkmale. Die folgenden Punkte leiten sich aus dem Fehlerbild und den veröffentlichten Tests ab. Sie sind Ansatzpunkte für eine Untersuchung, kein Beweis.

Netzwerk und Requests

Auffälliger Brotli-Verkehr

  • Requests mit Content-Encoding: br an Endpunkte, die sonst keine komprimierten Bodies erhalten
  • Gehäufte oder auffällig große Brotli-Requests, oft von einzelnen Quellen
  • Ausgehende Abrufe zu unbekannten Servern, deren Antworten Brotli-komprimiert sind, vor allem über Webhooks, Link-Vorschauen oder Abrufe, deren Ziel ein Nutzer bestimmt
Logs und Laufzeit

Abstürze und Neustarts

  • Speicherzugriffsfehler (SIGSEGV) in Node.js-, Bun-, .NET-, Python- oder Envoy-Prozessen, Core Dumps
  • Container, die mit Exit-Code 139 enden, und Pods in CrashLoopBackOff nach Requests mit Brotli
  • Hängende Prozesse mit voller CPU-Last bei der Verarbeitung von Parquet- oder Brotli-Daten

Ein erfolgreicher Angriff muss keinen Absturz hinterlassen.

Host

Folgen einer Codeausführung

  • Prozesse wie node, bun, dotnet, python oder envoy, die Shells, Interpreter oder curl, wget und nc starten
  • Befehle wie /bin/sh -c, whoami, id, uname
  • Unerwartete ausgehende Verbindungen, neue Dateien, Cronjobs oder Konten

Grenzen der Spurensuche: Viele Anwendungen protokollieren weder den Header Content-Encoding eingehender Requests noch die Antworten fremder Server. Das Auslesen von Speicher kann ohne Absturz und ohne Codeausführung bleiben. Die Host-Merkmale fehlen dann. Werkzeuge, die vor allem nach Schadcode suchen, erkennen einen solchen Angriff schlechter. Spielen Sie den Patch deshalb ein, auch wenn Sie nichts Auffälliges finden.

Verdacht auf Kompromittierung? Unser CSIRT ist rund um die Uhr unter csirt@vamisec.com erreichbar. Ein Compromise Assessment klärt, ob Angreifer bereits im System sind.

07 · Lage und Hintergrund

Wird Brotli2Shell schon ausgenutzt?

Die Quellen widersprechen sich, und die Lage ändert sich schnell. Stand gilt: Exploits sind öffentlich, ein Sicherheitsanbieter hat Angriffsverkehr auf eigenen Sensoren gemeldet, eine erfolgreiche Ausnutzung bei echten Opfern hat niemand bestätigt.

Behörden

Noch keine bestätigte Ausnutzung

Im Katalog bekannter ausgenutzter Schwachstellen (KEV) der US-Behörde CISA steht CVE-2026-111497 nicht, Katalogstand 26.10. In ihrer Einordnung vom 23.10. hält die CISA fest: keine bekannte Ausnutzung. CERT-Bund führt die Lücke im Hinweis WID-SEC-2026-4117 zu Node.js mit der Einstufung „mittel“ und vermerkt seit dem 23.10. öffentlichen Proof-of-Concept-Code. Eine eigene Cyber-Sicherheitswarnung des BSI gibt es bisher nicht.

Sicherheitsanbieter

Exploit-Verkehr auf Sensoren gemeldet

ELLIO hat am 26.10. um 15:08 UTC auf eigenen Sensoren Exploit-Verkehr gegen Node.js 24.22.0 auf x86-64 beobachtet: einen Brotli-Request von rund 23 MB, dessen Zustellteil öffentlichen Exploits folgt, mit eigener ROP-Kette. ELLIO wertet das als erste Ausnutzung in freier Wildbahn. Ob der Angriff funktioniert hätte, ist offen. Tenable spricht von einem Versuch und hat ihn nicht unabhängig bestätigt, Rapid7 war am 26.10. keine Ausnutzung bekannt. Laut Akamai betreiben 61 Prozent der Netzwerke betroffene Node.js-Versionen. Laut Qualys liegen rund 15 Prozent der erfassten Node.js-Installationen auf Systemen mit Internetanbindung, und ein großer Teil läuft auf Versionslinien ohne Support.

Exploit-Code

Absturz leicht, Codeausführung aufwendig

Imperva hat seinen Exploit nicht veröffentlicht. Auf GitHub kursieren mehrere andere. Der erste öffentliche Exploit vom 22.10. schaffte Codeausführung laut broccoli2shell.com nur auf einem gezielt geschwächten Build, auf Standard-Builds einen Absturz und ein begrenztes Auslesen von Speicher. Neuere Exploits beanspruchen Codeausführung gegen Node.js 24.22.0 mit Express 5.3.0 auf x86-64, mit geratenen Speicheradressen und mehreren Versuchen. ELLIO berichtet von Shells im eigenen Labor, abhängig vom genauen Build. Für Verteidiger heißt das: Ein Absturz ist leicht auszulösen, Codeausführung braucht Aufwand, ist aber machbar.

Warum dieser Fehler so weit reicht

Brotli ist kein Produkt, das man an einer Stelle aktualisiert. Der Decoder steckt als Kopie in Laufzeiten, Paketen, Proxys, Datenbanken und Geräten. Jedes dieser Projekte muss den Fix übernehmen, ein Release bauen und an seine Nutzer bringen. Deshalb gibt es für einige Produkte schon Updates, für andere noch nicht, und für alte Versionslinien gar keine.

Hinzu kommt, dass die verwundbare Stelle oft nicht in Ihrem Code liegt. Eine Anwendung, die nie das Wort Brotli enthält, entpackt trotzdem Brotli, wenn ihr HTTP-Client oder ihr Framework das automatisch tut. Gerade Dienste, die URLs abrufen, die ein Nutzer vorgibt, sind gefährdet: Webhooks, Link-Vorschauen, Crawler, Feed-Leser und KI-Agenten mit Web-Werkzeugen. Ein Angreifer muss sie nur auf einen eigenen Server lenken.

Bemerkenswert ist der zeitliche Ablauf. Der Fix steht seit dem 27. Februar 2026 im öffentlichen Quellcode von Brotli, unter dem unauffälligen Titel „Detect and report invalid stream earlier“. Der CVE-Eintrag nennt dieses Datum als Tag der Veröffentlichung. Releases mit Fix und die Offenlegung folgten erst am 21. Oktober. Dazwischen lagen fast acht Monate, in denen Projekte mit festen Brotli-Releases verwundbar blieben. Gemeldet haben die Lücke Khai Tran und Sylvie Mayer von OpenAI Codex Security.

Zeitleiste

  1. Der Fix landet im öffentlichen Brotli-Quellcode („Detect and report invalid stream earlier“).
  2. Envoy 1.36.12, 1.37.8, 1.38.6 und 1.39.3 erscheinen mit aktualisiertem Brotli, ohne Hinweis in den Release Notes. Am 15.10. folgt das Istio-Advisory.
  3. Node.js veröffentlicht 22.23.4, 24.22.1 und 26.12.1 und legt die Lücke offen. Google veröffentlicht Brotli 1.0.10, 1.1.1 und 1.2.1. Vercel aktiviert WAF-Regeln.
  4. Google veröffentlicht den CVE-Eintrag. Imperva zeigt Codeausführung und nennt die Lücke Node2Shell. Bun 1.4.4 und die gefixten Python-Pakete erscheinen, der erste öffentliche Exploit kursiert.
  5. Der Name HTTP2Shell kommt auf. Envoy und Bun veröffentlichen Advisories, CERT-Bund vermerkt öffentlichen Exploit-Code.
  6. Brotli4j 1.24.0, Updates für Debian und Amazon Linux, Fix in libjxl gemergt.
  7. Microsoft liefert .NET-Updates, Cloudflare eine Notfallregel. Wiz und JFrog veröffentlichen Analysen, JFrog unter dem Namen Brotli2Shell.
  8. ELLIO meldet Exploit-Verkehr auf eigenen Sensoren. Ubuntu und Red Hat (RHEL 8 und 9) veröffentlichen Updates, PHP für Windows erscheint mit Brotli 1.2.1. Für ClickHouse, DuckDB und Apache Arrow gibt es noch kein Release.

08 · Wiz-Abdeckung

Was Wiz für Brotli2Shell bereitstellt

Wiz-Kunden finden im Wiz Threat Center ihres Wiz-Tenants das Advisory wiz-adv-2026-191 zu CVE-2026-111497 mit einer vorbereiteten Abfrage, die verwundbare Instanzen sucht (Anmeldung erforderlich). Im Wiz-Blog fasst Wiz betroffene Produkte, gefixte Versionen und Übergangsmaßnahmen zusammen.

Agentlose Schwachstellenerkennung

Wiz liest über read-only Cloud-Schnittstellen und Disk-Snapshots, welche Pakete und Laufzeiten auf VMs, in Container-Images, Registries und Serverless-Funktionen stecken, ohne Agenten. Der Security Graph zeigt, welche verwundbaren Workloads aus dem Internet erreichbar sind. Laut Wiz betreiben 82 Prozent der Cloud-Umgebungen öffentlich erreichbare Node.js-Instanzen.

Laufzeit-Sicht mit dem Sensor

Der eBPF-basierte Wiz Runtime Sensor zeigt, welche Prozesse tatsächlich laufen, und meldet allgemein verdächtiges Verhalten auf Workloads, etwa unerwartete Shells. Eine eigene Laufzeit-Erkennung für Brotli2Shell nennt Wiz bisher nicht.

Priorisierung und Behebung

Das Advisory verknüpft die betroffenen Ressourcen mit Gefährdung von außen und Hinweisen zur Behebung. So patchen Sie zuerst, was aus dem Internet erreichbar ist, wie es der 7-Punkte-Plan vorsieht.

Ob Wiz auch Decoder-Kopien erkennt, die fest in fremde Programme eingebaut sind, sagt Wiz nicht. Dafür setzen wir ergänzend die Scanner von JFrog und Trail of Bits ein. Für Wiz ASM und den Red Agent beansprucht Wiz keine Brotli2Shell-spezifische Erkennung. Wir nutzen sie für die Außensicht: Welche Systeme sind erreichbar, welche Technologien laufen dort, und wo liegen Geheimnisse offen?

09 · VamiSec-Betroffenheitsprüfung

Wir prüfen kurzfristig, ob Brotli2Shell Sie betrifft

Als Mitglied der Wiz Partner Alliance setzen wir die Wiz-Plattform gezielt für Brotli2Shell ein. Sie entscheiden, wie tief wir schauen: nur von außen, ohne Zugang zu Ihrer Umgebung, oder zusätzlich von innen über read-only Konnektoren. Am Ende steht eine priorisierte Liste, welche Systeme Sie zuerst patchen müssen.

Variante A · von außen

Blackbox-Prüfung

Wir betrachten Ihre Umgebung so, wie ein Angreifer sie aus dem Internet sieht. Sie brauchen uns dafür keinen Zugang zu geben.

  • Wiz ASM findet Ihre erreichbaren Domains, Subdomains, IP-Adressen und API-Endpunkte, ausgehend von Ihren Stammdomains
  • Wir identifizieren Technologien mit Brotli-Bezug wie Node.js, Express, Next.js, ASP.NET Core, Envoy und Istio und prüfen mit harmlosen, gültig komprimierten Requests, welche Endpunkte Brotli-komprimierte Bodies annehmen
  • Funktionen, die vom Nutzer gewählte URLs abrufen, etwa Webhooks, Importe oder Link-Vorschauen, markieren wir gesondert, weil sie den ausgehenden Angriffsweg öffnen
  • Der Wiz Red Agent testet erreichbare Web-Anwendungen und APIs als KI-gestützter Angreifer auf Logikfehler, Autorisierungslücken und offengelegte Daten. Einen eigenen Brotli2Shell-Test nennt Wiz dafür nicht
  • Ergänzend erfassen wir Ihre Angriffsfläche mit Recon und Attack Surface Management von VamiRedteam

Ergebnis: Liste Ihrer erreichbaren Systeme mit Brotli-Bezug und Risikobewertung. Von außen erhalten Sie Indizien, aber keine Gewissheit über Versionen und Patch-Stand.

Variante B · von innen

Cloud-, Kubernetes- und Code-Prüfung

Wir verbinden Wiz mit Ihren Cloud-Konten und Clustern, mit minimalen Leserechten und ohne Agenten auf Ihren Workloads. Für den Scan legt Wiz kurzzeitig Disk-Snapshots an und löscht sie danach wieder.

  • Read-only Cloud-Konnektoren für AWS, Azure, Google Cloud, Oracle Cloud, Alibaba Cloud und VMware vSphere
  • Agentloser Scan von VMs, Container-Images, Registries und Serverless-Funktionen auf Node.js-, Bun- und .NET-Laufzeiten, Python-Pakete und libbrotli. Paketstände mit zurückportierten Fixes gleichen wir mit den Hinweisen der Hersteller ab
  • Kubernetes-Konnektor per Helm-Chart mit lesenden Rechten für EKS, AKS, GKE, OpenShift und selbst betriebene Cluster, inklusive Envoy und Istio
  • Auf Wunsch die Scanner von JFrog und Trail of Bits in Ihren Repositories und Pipelines, um fest eingebaute Decoder und Aufrufpfade zu finden
  • Optional und nur nach gesonderter Freigabe der Wiz Runtime Sensor, ein eBPF-Sensor auf Hosts und Knoten. Er erfasst auch On-Prem-Server, die kein Konnektor erreicht. Er setzt eine passende Wiz-Lizenz voraus

Ergebnis: belastbares Inventar für die verbundenen Konten, Cluster und Repositories, welche Workloads welche Version nutzen und welche davon verwundbar sind. Appliances und Fremdprodukte prüfen wir gesondert.

Empfohlen · kombiniert

Außen und innen zusammen

Die Kombination beantwortet die entscheidende Frage: Welche verwundbaren Komponenten erreichen fremde Brotli-Daten tatsächlich, eingehend oder ausgehend?

  • Außensicht und Inventar werden im Wiz Security Graph verknüpft
  • Angriffspfade vom Internet bis zu verwundbaren Workloads und sensiblen Daten
  • Priorisierter Maßnahmenplan mit Patch-Reihenfolge, Übergangsschutz und Nachweisen für Audits
  • Kontrolle nach dem Patch, ob alle Instanzen den Fix haben und neu gestartet wurden

Ergebnis: belastbare Entscheidungsgrundlage für IT, CISO und Geschäftsführung.

01 · Erstgespräch

Umfang klären

In 30 Minuten klären wir Domains, Cloud-Anbieter, Cluster, Repositories und Ihre Prioritäten.

02 · Freigabe

Schriftlich autorisieren

Sie geben den Umfang schriftlich frei. Ohne Freigabe testen wir nichts.

03 · Prüfung

Außen- und Innensicht

Wir führen die vereinbarten Prüfungen durch und melden kritische Funde sofort.

04 · Ergebnis

Bericht und Maßnahmenplan

Sie erhalten eine Management-Zusammenfassung, die technische Befundliste und die Patch-Reihenfolge.

Was wir von Ihnen brauchen
  • Für die Außensicht: Ihre Stammdomains und bekannten IP-Bereiche sowie eine schriftliche Freigabe des Prüfumfangs
  • Für die Innensicht: eine read-only Rolle je Cloud-Konto, die wir gemeinsam anlegen, die Installation des Kubernetes-Konnektors per Helm und auf Wunsch Lesezugriff auf Repositories
  • Eine Ansprechperson aus Betrieb oder IT-Sicherheit für Rückfragen
So gehen wir vor
  • Wir arbeiten nur im freigegebenen Umfang und stimmen Testzeitfenster mit Ihnen ab. Systeme, die Hoster oder SaaS-Anbieter für Sie betreiben, testen wir aktiv nur mit deren Zustimmung
  • Tests mit präparierten Brotli-Daten nur nach gesonderter schriftlicher Freigabe und in einem abgestimmten Zeitfenster, weil sie Prozesse zum Absturz bringen können
  • Vertraulichkeit regeln wir vorab per NDA, die Verarbeitung von Prüfdaten bei Bedarf per Auftragsverarbeitungsvertrag
  • Bei Hinweisen auf eine Kompromittierung schalten wir auf Wunsch sofort unser CSIRT ein

Betroffenheitsprüfung anfragen

Buchen Sie direkt einen Termin oder schreiben Sie an wiz@vamisec.com. Wir antworten innerhalb von 24 Stunden. Nennen Sie gern schon Domains, Cloud-Anbieter und Cluster, dann können wir den Umfang sofort einschätzen.

Wiz Partner Badge Technical Foundations Wiz Partner Badge Demo Accreditation
Termin buchen E-Mail schreiben

10 · Meldepflichten

Wann Sie Brotli2Shell melden müssen

Eine ungenutzte Schwachstelle allein löst in Deutschland und der EU keine Meldepflicht aus. Das ändert sich, wenn sie bei Ihnen ausgenutzt wurde. Hersteller, die Brotli in eigenen Produkten ausliefern, müssen zudem melden, sobald es verlässliche Hinweise auf eine aktive Ausnutzung gibt. Die Fristen beginnen mit der Kenntnis vom Vorfall, nicht mit der Veröffentlichung der CVE. Diese Übersicht ist eine Orientierung und keine Rechtsberatung.

NIS2 · BSI-Gesetz

Wichtige und besonders wichtige Einrichtungen

Schwachstellen zu behandeln und zu patchen ist Teil des Risikomanagements, das das BSI-Gesetz vorschreibt. Melden müssen Sie einen erheblichen Sicherheitsvorfall, etwa einen erfolgreichen unbefugten Zugriff, der den Betrieb schwer stören kann. Dann gilt: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht einen Monat nach der Meldung.

DSGVO

Wenn personenbezogene Daten betroffen sind

Hat ein Angriff Speicher mit personenbezogenen Daten oder Zugangsdaten offengelegt, melden Sie das der Aufsichtsbehörde binnen 72 Stunden, außer es besteht voraussichtlich kein Risiko. Bei hohem Risiko informieren Sie die Betroffenen unverzüglich. Jede Datenpanne ist zu dokumentieren.

Cyber Resilience Act

Hersteller, die Brotli in Produkten ausliefern

Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen in ihren Produkten über die Meldeplattform der ENISA melden, auch für bereits verkaufte Produkte. Das betrifft etwa Geräte, Appliances und Software, die den Brotli-Decoder oder eine Laufzeit wie Node.js mitbringen. Fristen: 24 Stunden, 72 Stunden und ein Abschlussbericht 14 Tage nach Verfügbarkeit eines Fixes. Unabhängig davon verlangt der CRA, bekannte Schwachstellen in Komponenten zu behandeln.

DORA

Finanzunternehmen

Banken, Versicherer und andere Finanzunternehmen melden nicht nach dem BSI-Gesetz, sondern nach DORA an ihre Aufsicht. Ein erfolgreicher, böswilliger Zugriff ist dort ein zentrales Kriterium für einen schwerwiegenden IKT-Vorfall. Die Erstmeldung ist binnen 4 Stunden nach der Einstufung fällig, spätestens 24 Stunden nach Kenntnis.

Ein abgewehrter Angriffsversuch ist in der Regel kein meldepflichtiger Vorfall, sondern allenfalls ein Beinahevorfall. Freiwillige, auch anonyme Meldungen an das BSI sind trotzdem möglich. Vertiefung: NIS2, Cyber Resilience Act, DORA.

11 · FAQ

Häufige Fragen zu Brotli2Shell

Was ist Brotli2Shell?

Brotli2Shell ist ein Name für CVE-2026-111497, eine kritische Schwachstelle im Brotli-Decoder von Google mit CVSS v4.0 9.2. Bei einem ungültigen Blockwechsel meldet der Decoder fälschlich, er brauche mehr Eingabe, und schreibt dadurch über das Ende eines internen Puffers von acht Byte hinaus. Wer präparierte Brotli-Daten einspeisen kann, kann damit Speicher beschädigen, Speicher auslesen, Prozesse zum Absturz bringen und im schlimmsten Fall Code ausführen. Offengelegt wurde die Lücke am 21. Oktober 2026 mit dem Sicherheitsrelease von Node.js.

Warum hat die Lücke so viele Namen?

Imperva nannte sie Node2Shell, als es am 22. Oktober Codeausführung gegen Node.js zeigte. Ab dem 23. Oktober kam HTTP2Shell auf. Broccoli2Shell geht auf den Vorschlag des Sicherheitsforschers Juliano Rizzo zurück, die Lücke „Broccoli“ zu nennen. Den Namen nutzen die unabhängige Seite broccoli2shell.com und Wiz. JFrog wählte am 25. Oktober Brotli2Shell, weil der Fehler im Brotli-Decoder selbst steckt. Gemeint ist immer CVE-2026-111497. Suchen Sie in Herstellerhinweisen und Changelogs deshalb nach der CVE-Nummer.

Bin ich von Brotli2Shell betroffen?

Betroffen sind Sie, wenn eine Ihrer Komponenten einen verwundbaren Brotli-Decoder enthält und Brotli-Daten aus nicht vertrauenswürdiger Quelle entpackt. Typisch sind Node.js vor 22.23.4, 24.22.1 oder 26.12.1, Bun vor 1.4.4, .NET vor 8.0.33, 9.0.22 oder 10.0.14, die Python-Pakete brotli und brotlicffi vor 1.2.1, Envoy und Istio mit aktivem Brotli-Decompressor sowie Datenbanken und Werkzeuge mit eigener Brotli-Kopie. Fremde Brotli-Daten kommen über eingehende Requests, über Antworten fremder Server, die Ihre Dienste abrufen, oder über Dateien.

Welche Versionen sind sicher?

Brotli 1.0.10, 1.1.1 und 1.2.1, Node.js 22.23.4, 24.22.1 und 26.12.1, Bun 1.4.4, .NET 8.0.33, 9.0.22 und 10.0.14, die Python-Pakete brotli 1.2.1 und brotlicffi 1.2.1.0, Envoy 1.36.12, 1.37.8, 1.38.6, 1.39.3 und 1.40.0, Istio 1.29.9, 1.30.6 und 1.31.2, Brotli4j 1.24.0 sowie neuere Versionen. Distributionen portieren den Fix oft zurück, ohne die Versionsnummer zu ändern. Dann ist das Paket-Changelog maßgeblich.

Was gilt für Node.js 20 und andere Versionen ohne Support?

Node.js 20 und ältere Linien erhalten kein Update. Laut Node.js sind Versionen ohne Support bei jedem Sicherheitsrelease grundsätzlich betroffen. Migrieren Sie auf Node.js 22, 24 oder 26 oder nutzen Sie einen Anbieter für erweiterten Support. Bis dahin hilft nur, dem Decoder fremde Brotli-Daten vorzuenthalten.

Braucht ein Angreifer für Brotli2Shell ein Konto oder Zugangsdaten?

Nein. Laut CVE-Eintrag braucht ein Angreifer weder Rechte noch die Mitwirkung eines Nutzers. Er muss nur erreichen, dass ein verwundbares System seine Brotli-Daten entpackt, etwa per Request, über einen Server, den Ihr Dienst abruft, oder über eine Datei. Eine Login-Seite der Anwendung schützt nicht, wenn die Dekompression vorher stattfindet.

Sind Webserver wie nginx und Apache betroffen?

Nicht über ihre Brotli-Module. ngx_brotli und mod_brotli komprimieren nur Antworten, den Decoder nutzen sie nicht. Betroffen sein kann aber die Anwendung hinter dem Webserver, wenn sie Brotli-Requests entpackt oder fremde Inhalte abruft. Wer an nginx oder Apache Requests mit Content-Encoding: br abweist, schützt die Anwendung dahinter.

Sind Browser wie Chrome und Firefox betroffen?

Nach unserem Stand nicht in aktuellen Versionen. Die aktuellen Quellstände von Chromium und Firefox nutzen Brotli-Revisionen von März bzw. April 2026, die den Fix enthalten. Seit wann und ab welcher ausgelieferten Browser-Version das gilt, haben die Hersteller nicht veröffentlicht. Halten Sie Browser aktuell. Einige Distributionen führen Firefox-Pakete noch als betroffen.

In welcher Reihenfolge sollte ich vorgehen?

Von außen nach innen. Machen Sie zuerst sichtbar, welche Systeme Brotli-Requests aus dem Internet annehmen oder fremde Inhalte abrufen, und weisen Sie Brotli am Eingang ab. Patchen Sie diese Systeme parallel dazu, und zwar vor allen anderen. Erst wenn sie gepatcht sind, folgen interne Dienste, Datenpipelines und Werkzeuge. Fordern Sie von Anfang an schriftliche Berichte von Lieferanten an, die nicht von sich aus informiert haben.

Wird Brotli2Shell bereits aktiv ausgenutzt?

Stand 27. Oktober 2026 ist das nicht bestätigt. ELLIO hat am 26. Oktober Exploit-Verkehr gegen Node.js 24.22.0 auf eigenen Sensoren gemeldet und wertet ihn als erste Ausnutzung in freier Wildbahn. Ob der Angriff funktioniert hätte, ist offen. Tenable hat die Meldung nicht unabhängig bestätigt, Rapid7 war keine Ausnutzung bekannt, und die CVE steht nicht im KEV-Katalog der CISA. Öffentliche Exploits gibt es. Behandeln Sie erreichbare Systeme deshalb so, als würden sie angegriffen.

Schützt eine WAF oder ein CDN vor Brotli2Shell?

Nur in der eingehenden Richtung und nur, wenn die Regel blockiert. Cloudflare, Vercel und Imperva haben Regeln veröffentlicht, die Regel von Cloudflare protokolliert standardmäßig nur. Keine WAF sieht, was Ihre Dienste von fremden Servern abrufen und entpacken. Verkehr, der direkt zum Origin-Server geht, umgeht die WAF ebenfalls. Der Patch bleibt nötig.

Gibt es Workarounds, wenn ich nicht sofort patchen kann?

Ja, aber sie überbrücken nur. Weisen Sie Requests mit Content-Encoding: br am Rand des Netzes ab, schalten Sie Brotli-Decompressor-Filter in Envoy und Istio ab, betreiben Sie HTTP-Clients ohne automatische Brotli-Dekompression und verarbeiten Sie Brotli-haltige Dateien aus fremder Hand vorerst nicht. Nur br aus Accept-Encoding zu streichen reicht nicht, weil ein bösartiger Server Brotli trotzdem senden kann.

Gibt es einen Scanner oder Proof of Concept für Brotli2Shell?

Ja. JFrog und Trail of Bits haben Open-Source-Scanner veröffentlicht, die Code, Abhängigkeiten und Binärdateien nach dem verwundbaren Decoder und nach Aufrufpfaden durchsuchen, ohne etwas anzugreifen. Ein leerer Befund beweist aber keine Sicherheit. Auf GitHub kursieren außerdem mehrere Exploits. Führen Sie fremden Exploit-Code nur in isolierten Umgebungen aus und testen Sie nur eigene oder freigegebene Systeme. VamiSec unterstützt bei Einsatz und Auswertung.

Muss ich Dienste nach dem Update neu starten?

Ja. Laufende Prozesse behalten den alten Decoder im Speicher. Starten Sie Node.js-, Bun-, .NET- und Python-Dienste sowie Envoy-Proxys neu, rollen Sie Container mit neu gebauten Images aus und veröffentlichen Sie eigenständige Programme neu, die ihre Laufzeit mitbringen.

Wie finde ich verwundbare Komponenten in Containern und Kubernetes?

Prüfen Sie in jedem Image die Versionen von Node.js, Bun, .NET und den Python-Paketen sowie die Systembibliothek libbrotli, und gleichen Sie laufende Pods mit den Images ab. Basis-Images aus Registries und CI-Pipelines gehören dazu, ebenso Envoy-Sidecars und Istio. Wiz kann das agentlos für verbundene Cloud-Konten, Registries und Cluster übernehmen. Fest eingebaute Decoder-Kopien erkennt der Scanner von Trail of Bits, Aufrufpfade der Scanner von JFrog.

Welche Daten können abfließen, und muss ich Schlüssel tauschen?

Die Lücke kann Prozessspeicher offenlegen. Darin liegen oft Tokens, API-Schlüssel, Passwörter und Daten anderer Requests. Gibt es Hinweise auf einen Angriff vor dem Patch, rotieren Sie diese Geheimnisse und machen Sie aktive Sitzungen ungültig.

Muss ich Brotli2Shell melden?

Die Schwachstelle allein ist nicht meldepflichtig. Eine Meldepflicht entsteht bei einem erheblichen Sicherheitsvorfall nach NIS2, bei einer Datenpanne nach DSGVO, bei einem schwerwiegenden IKT-Vorfall nach DORA oder für Hersteller bei einer aktiv ausgenutzten Schwachstelle im eigenen Produkt nach dem Cyber Resilience Act.

Hängt Brotli2Shell mit PHP2Shell zusammen?

Nein. PHP2Shell betrifft den Kern der Programmiersprache PHP, Brotli2Shell den Brotli-Decoder von Google. Beide wurden im Oktober 2026 bekannt, und beide zeigen, wie weit eine einzelne Komponente in die Infrastruktur reicht. PHP für Windows berührt allerdings beide, weil die Windows-Builds Brotli mitbringen. Dort ist der Brotli-Pfad nur über die cURL-Erweiterung mit automatischer Dekompression erreichbar. Unser Lagebild zu PHP2Shell finden Sie unter php2shell.wiz.vamisec.com.

Wie läuft die Betroffenheitsprüfung von VamiSec ab?

Nach einem 30-minütigen Erstgespräch und Ihrer schriftlichen Freigabe prüfen wir von außen mit Wiz ASM, dem Wiz Red Agent und VamiRedteam. Auf Wunsch prüfen wir zusätzlich von innen über read-only Wiz-Konnektoren für Cloud und Kubernetes und mit den Scannern von JFrog und Trail of Bits in Ihren Repositories. Sie erhalten eine priorisierte Befundliste und einen Maßnahmenplan. Kritische Funde melden wir sofort.

Welchen Zugang braucht VamiSec für die Prüfung?

Für die Außensicht keinen, nur Ihre Domains, IP-Bereiche und eine schriftliche Freigabe. Für die Innensicht eine read-only Rolle je Cloud-Konto und den Kubernetes-Konnektor von Wiz. Beide arbeiten mit minimalen, überwiegend lesenden Rechten und installieren keine Agenten auf Ihren Workloads. Für den agentlosen Scan erstellt Wiz kurzzeitig Disk-Snapshots, und der Kubernetes-Konnektor darf standardmäßig alle Ressourcen im Cluster lesen, auch Secrets.

Wo werden die Daten bei der Prüfung verarbeitet?

Wiz bietet Tenants in der EU an. Welchen Tenant wir für Ihre Prüfung nutzen, legen wir vorab mit Ihnen fest. Scans verbundener Cloud-Ressourcen laufen laut Wiz in der Region der jeweiligen Ressource. Einzelne Verarbeitungen, etwa für Support und Nutzungsanalysen, finden laut Subprozessorliste auch außerhalb der EU statt. Für Analysen des Red Agent nutzt Wiz laut seiner Subprozessorliste einen globalen Endpunkt. Wenn Sie strikte Vorgaben zur Datenresidenz haben, stimmen wir den Einsatz des Red Agent vorab mit Ihnen ab.

12 · Quellen

Primärquellen und Hinweise der Anbieter

Diese Seite fasst die Veröffentlichungen mit eigenen Worten zusammen. Verbindlich sind die Originalquellen. Wir aktualisieren die Seite, sobald sich die Lage ändert.

  1. CVE-2026-111497: Out-of-Bounds Write in Google Brotli DecoderCVE-Eintrag der CNA Google, 22.10.2026
  2. NVD: CVE-2026-111497National Vulnerability Database
  3. GHSA-9v8h-qqgm-4m35GitHub Advisory, Python-Pakete brotli und brotlicffi
  4. Node.js October 2026 security releasesNode.js-Projekt, 21.10.2026
  5. Detect and report invalid stream earlier · Brotli v1.2.1Google Brotli, Fix vom 27.02.2026 und Release vom 21.10.2026
  6. oss-security: Brotli CVE-2026-111497Mailingliste oss-security, 23.10.2026
  7. Node2Shell: From Brotli data to remote code executionImperva, Ron Masas, 22.10.2026
  8. Broccoli2shell: Everything you need to knowWiz, 25.10.2026
  9. Brotli2Shell: Beyond Node(2Shell) and HTTP(2Shell)JFrog Security Research, 25.10.2026
  10. broccoli2shell.comUnabhängige Übersicht betroffener Produkte
  11. .NET Security Advisory für CVE-2026-111497Microsoft, 25.10.2026
  12. GHSA-663w-cv8g-jj2pBun, 23.10.2026
  13. GHSA-3wvj-j6qm-62mrEnvoy, 23.10.2026
  14. ISTIO-SECURITY-2026-007Istio, 15.10.2026
  15. GHSA-x524-jrqf-vwq6Brotli4j, 24.10.2026
  16. ClickHouse PR #127419 · Apache Arrow #55166Fix-Stand ClickHouse und Apache Arrow
  17. Debian · Ubuntu · Red Hat · SUSE · Amazon LinuxStand der Distributionen
  18. WID-SEC-2026-4117: Node.js, mehrere SchwachstellenCERT-Bund, Warn- und Informationsdienst, Version 3 vom 26.10.2026
  19. CERTFR-2026-AVI-1367CERT-FR, 22.10.2026
  20. Node.js security advisoryVercel, 21.10.2026
  21. WAF changelogCloudflare, Notfall-Release vom 25.10.2026
  22. Node2Shell: RCE on stock Node.js buildsELLIO, 25.10.2026, Update vom 26.10.2026
  23. CVE-2026-111497: Critical out-of-bounds write in the Node.js Brotli decoderRapid7, 26.10.2026
  24. Inside Node2ShellAkamai, 26.10.2026
  25. Node.js patches Brotli remote code execution flawQualys, 23.10.2026, aktualisiert 26.10.2026
  26. Brotli2Shell: Frequently asked questionsTenable, über Security Boulevard, 26.10.2026
  27. CVE-2026-111497 explainedCynet, 26.10.2026
  28. Node2Shell in Node.js · Python-PaketeAikido, 22. und 23.10.2026
  29. Node2Shell affects PythonOpenSourceMalware
  30. jfrog/vulnerability_scanners · trailofbits/brotli-checker · node2shell-detectOpen-Source-Werkzeuge zur Erkennung
  31. RFC 7932: Brotli Compressed Data FormatIETF, 2016
  32. VamiRedteamVamiSec, agentische Plattform für Recon, Attack Surface Management und Pentests
  33. Wiz ASM auto recon · Wiz Red Agent · Agentless scanningWiz, Produktinformationen
Valeri Milke
Valeri MilkeGeschäftsführer VamiSec GmbH · ISO/IEC 27001 & 42001 Lead Auditor · aktualisiert

Klarheit über Ihren Brotli-Bestand

Wir zeigen Ihnen, wo der Brotli-Decoder in Ihrer Umgebung läuft, welche Instanzen verwundbar und erreichbar sind und was Sie zuerst tun sollten.

Betroffenheitsprüfung anfragen