Broccoli2Shell: Kritische Lücke in Brotli – was jetzt zu tun ist

Kurz gesagt: Aktualisieren Sie Node.js auf 22.23.4, 24.22.1, 26.12.1 oder neuer, die Python-Pakete Brotli und brotlicffi auf 1.2.1 bzw. 1.2.1.0 und die Brotli-Pakete Ihrer Linux-Distribution. Starten Sie danach alle betroffenen Prozesse neu, und bauen Sie Container-Images neu. Prüfen Sie außerdem .NET, Firewalls mit TLS-Inspektion und eingekaufte Produkte, die Brotli mitbringen. Die EU-Agentur ENISA und die US-Behörde CISA führen die Lücke seit dem 27. Oktober 2026 als ausgenutzt. Stand der Angaben: 30. Oktober 2026 – wir aktualisieren den Beitrag, sobald sich die Lage ändert.

Was ist Broccoli2Shell?

Broccoli2Shell ist einer von mehreren Namen für die Schwachstelle CVE-2026-111497 im Decoder von Brotli. Brotli ist ein Kompressionsverfahren, mit dem unter anderem Webserver und HTTP-Clients Daten komprimiert übertragen, erkennbar am Header Content-Encoding: br. Die Referenzbibliothek in C stammt von Google und steckt als Baustein in Laufzeitumgebungen, Bibliotheken, Browsern und weiteren Produkten (Red Hat RHSB-2026-015).

Das Imperva Red Team hat seine Analyse vom 22. Oktober 2026 „Node2Shell“ genannt (Imperva). Weil die Lücke weit über Node.js hinausreicht, kursieren inzwischen auch die Namen „HTTP2Shell“, „Brotli2Shell“ und „Broccoli2Shell“ (Aikido, 23.10.2026, Tenable, ELLIO). Gemeint ist immer dieselbe Lücke.

Google hat den CVE-Eintrag am 22. Oktober 2026 veröffentlicht und die Lücke nach CVSS 4.0 mit 9,2 von 10 Punkten als kritisch eingestuft (CVE-2026-111497). Laut Beschreibung handelt es sich um einen Pufferüberlauf im Decoder von Brotli 1.0.3 bis 1.2.0. Mit einem präparierten Brotli-Datenstrom kann ein Angreifer über das Netz und ohne Anmeldung Speicher beschädigen, Speicherinhalte offenlegen, den Prozess zum Absturz bringen oder womöglich eigenen Code ausführen – eine Remote Code Execution. Laut CVE-Eintrag und Node.js haben Khai Tran und Sylvie Mayer von OpenAI Codex Security die Lücke gefunden.

Die Einstufungen gehen auseinander: Das Node.js-Projekt bewertet die Lücke als „high“ (Node.js-Sicherheitshinweis vom 21.10.2026). Red Hat stuft sie als „Important“ ein, weil ein exakt präparierter Datenstrom nötig sei und es keinen öffentlichen, zuverlässigen Proof of Concept für die Codeausführung gebe (Red Hat).

Der zeitliche Ablauf:

• 27. Februar 2026: Die Korrektur landet im Quellcode von Brotli, mit der Commit-Nachricht „Detect and report invalid stream earlier.“ und ohne Hinweis auf eine Sicherheitslücke (Commit 0ed4268). Fast acht Monate lang folgt kein Release.
• 21. Oktober 2026: Node.js veröffentlicht die Versionen 22.23.4, 24.22.1 und 26.12.1 (Node.js-Sicherheitshinweis), Google die Brotli-Versionen 1.0.10, 1.1.1 und 1.2.1 (Brotli-Release v1.2.1).
• 22. Oktober 2026: Der CVE-Eintrag erscheint, und Imperva beschreibt Codeausführung auf einem offiziellen Node.js-Image (Imperva). Ein erster öffentlicher Exploit als Proof of Concept funktioniert laut Aikido nur auf einem absichtlich geschwächten Test-Build (Aikido, 22.10.2026).
• 25. und 26. Oktober 2026: Microsoft, Red Hat, Ubuntu und Palo Alto Networks veröffentlichen Updates und Hinweise (Details im nächsten Abschnitt).
• 27. Oktober 2026: Die CISA nimmt die Lücke in ihren Katalog aktiv ausgenutzter Schwachstellen auf (CISA, 27.10.2026).
• 28. Oktober 2026: Das BSI ergänzt seine Warnung um den Hinweis auf einen Exploit und passt die Bewertung an (BSI WID-SEC-2026-4117).

Welche Software ist betroffen?

Die Lücke steckt in der Brotli-Bibliothek, nicht in einer bestimmten Anwendung. Gefährdet ist jede Software, die einen verwundbaren Decoder enthält und damit Daten aus nicht vertrauenswürdigen Quellen entpackt (Red Hat RHSB-2026-015). Den Stand der Korrekturen zeigt diese Übersicht:

• Brotli (C-Bibliothek): Betroffen sind 1.0.3 bis 1.2.0, behoben ist die Lücke in 1.0.10, 1.1.1 und 1.2.1 (CVE-2026-111497).
• Node.js: behoben in 22.23.4, 24.22.1 und 26.12.1 sowie in allen späteren Versionen (Node.js-Sicherheitshinweis). Node.js 20, 23 und 25 haben ihr Support-Ende erreicht und erhalten keine Updates mehr (Node.js-Release-Plan).
• Python: Die PyPI-Pakete Brotli vor 1.2.1 und brotlicffi vor 1.2.1.0 bringen den verwundbaren Decoder mit; korrigiert sind Brotli 1.2.1 und brotlicffi 1.2.1.0 (GHSA-9v8h-qqgm-4m35).
• .NET: Betroffen sind .NET 8, 9 und 10 vor 8.0.33, 9.0.22 bzw. 10.0.14 sowie Vorabversionen von .NET 11, nicht aber das .NET Framework (Microsoft-Advisory vom 25.10.2026). Im Security Update Guide führt Microsoft außerdem PowerShell 7 und mehrere Versionen von Visual Studio als betroffen (Microsoft Security Update Guide).
• Linux-Distributionen: Debian, Ubuntu und Red Hat haben ihre Brotli-Pakete aktualisiert, etwa brotli, libbrotli1 (bei Red Hat libbrotli) und python3-brotli (Debian, Ubuntu, Red Hat). Für andere Distributionen gilt der jeweilige Sicherheitshinweis.
• Firewalls: PAN-OS 11.2, 12.1 und 12.2 sind betroffen, wenn sowohl die Prüfung Brotli-komprimierten Datenverkehrs als auch die TLS-Entschlüsselung aktiviert sind. Die Brotli-Prüfung ist ab PAN-OS 11.2.4 standardmäßig ausgeschaltet. Nicht betroffen sind die Managementoberfläche, PAN-OS 11.1 und 10.2 sowie Panorama. Hotfixes liegen vor (Palo Alto Networks).
• Weitere Laufzeitumgebungen und Proxys: Laut Tenable sind auch Bun, die offiziellen Windows-Builds von PHP sowie Envoy und Istio betroffen, die beiden Letzteren nur mit konfiguriertem Brotli-Decompressor. Für alle vier liegen korrigierte Versionen vor (Tenable).
• Browser und E-Mail-Programme: Laut Red Hat bringen auch Firefox und Thunderbird eine eigene Brotli-Kopie mit (Red Hat RHSB-2026-015). Unter RHEL gelten beide ab Version 140.10.0 als korrigiert (Red Hat).

Drei Punkte werden leicht übersehen. Erstens übernehmen Distributionen die Korrektur meist per Backport unter der alten Versionsnummer, Ubuntu 24.04 etwa mit dem Paket brotli 1.1.0-2ubuntu0.1 (Ubuntu). Entscheidend ist deshalb die vollständige Paketversion im Sicherheitshinweis, nicht die Versionsspanne 1.0.3 bis 1.2.0. Zweitens nutzt Node.js aus Distributionspaketen teils die Brotli-Bibliothek des Systems: Bei Debian und bei Ubuntu ab 22.04 kommt es auf das aktualisierte Brotli-Paket an. Red Hat liefert dagegen Node.js 24 als Modul nodejs:24 unter RHEL 8 und 9 mit eigener Brotli-Kopie aus; korrigierte Pakete auf Basis von Node.js 24.22.1 gibt es dafür seit dem 29. Oktober 2026. Für das Modul nodejs:26 unter RHEL 9 und für .NET 8 unter RHEL gab es am 30. Oktober 2026 noch keine Korrektur (Debian, Ubuntu, Red Hat).

Drittens binden viele Projekte eigene, mitgelieferte Brotli-Kopien ein, etwa die Datenbanken ClickHouse und DuckDB, die JPEG-XL-Bibliothek libjxl und das UEFI-Entwicklungspaket EDK II. Keines dieser Projekte hat bisher ein Release mit der Korrektur veröffentlicht: ClickHouse und libjxl haben sie erst im Quellcode übernommen, DuckDB und EDK II noch gar nicht (eigene Recherche, Stand 30. Oktober 2026). Solche Kopien findet nur, wer seine Abhängigkeiten kennt, etwa über eine SBOM, die Stückliste einer Software.

Zur Einordnung: Nur das Entpacken ist betroffen. Wer Brotli lediglich zum Komprimieren nutzt, etwa ein Webserver für seine Antworten, löst den Fehler nicht aus (Aikido, 23.10.2026).

So funktioniert die Lücke

Ein Brotli-Datenstrom enthält Steueranweisungen, mit denen er zwischen verschiedenen Blocktypen wechselt. Genau dort liegt der Fehler: Laut Node.js meldete der Decoder einen ungültigen Blockwechsel nicht als Formatfehler, sondern so, als fehlten nur weitere Eingabedaten. Er hängte deshalb weitere Bytes an einen kleinen internen Puffer an und schrieb über dessen Ende hinaus (Node.js-Sicherheitshinweis). Die Korrektur erkennt den ungültigen Datenstrom früher und bricht mit einem eigenen Fehlercode ab (Commit 0ed4268). Normale, korrekt erzeugte Brotli-Daten lösen den Fehler nicht aus; nötig ist ein gezielt präparierter Datenstrom (Red Hat RHSB-2026-015).

Angreifbar ist eine Anwendung, sobald sie Brotli-Daten aus einer Quelle entpackt, die ein Angreifer kontrolliert. Hinweise und Analysen beschreiben vier Angriffswege:

• Eingehende Anfragen: Webanwendungen, die Request-Bodys mit Content-Encoding: br automatisch entpacken. In Node.js tun das Express 5 und body-parser 2.x mit allen Parsern standardmäßig, auch in der aktuellen body-parser-Version 2.4.0 (body-parser). Laut Sysdig entpacken auch Koa sowie Fastify mit @fastify/compress Brotli-Bodys, Express 4 mit body-parser 1.x dagegen nur gzip und deflate (Sysdig). Ein einfacher Node.js-HTTP-Server entpackt eingehende Daten nicht von sich aus (Imperva).
• Abgerufene Antworten: Anwendungen, die Inhalte von fremden Servern laden. Das in Node.js eingebaute fetch() entpackt Brotli-Antworten automatisch (Aikido, 22.10.2026), in Python tun das requests, urllib3, aiohttp und HTTPX, sobald Brotli oder brotlicffi installiert ist (Requests-Dokumentation, OpenSourceMalware). Gefährdet sind laut ELLIO vor allem Funktionen, die von Nutzenden angegebene URLs abrufen, etwa Webhooks, Link-Vorschauen und Crawler (ELLIO) – ein Muster, das auch bei SSRF eine Rolle spielt. Den Header Accept-Encoding anzupassen, genügt nicht: Ein bösartiger Server kann trotzdem Brotli senden, und der Client wählt den Decoder anhand der Antwort (Aikido, 23.10.2026).
• Direkte Nutzung: Programme, die hochgeladene Dateien oder andere Eingaben selbst mit Brotli entpacken, etwa über zlib.brotliDecompress() in Node.js oder BrotliStream in .NET (Red Hat RHSB-2026-015, Microsoft-Advisory).
• Netzwerk- und Sicherheitsgeräte: Firewalls und Proxys, die entschlüsselten Datenverkehr entpacken und prüfen, etwa PAN-OS mit aktivierter Brotli-Prüfung (Palo Alto Networks).

Das Imperva Red Team hat nach eigenen Angaben auf dem offiziellen, unveränderten Node.js-24.22.0-Image für Linux (arm64) Code ausgeführt, der in Brotli-Daten steckte – über Request-Bodys einer Express-5-Anwendung ebenso wie über eine per fetch() abgerufene Antwort. Das gelang nicht bei jedem Versuch; Node.js 24.22.1 wies dieselben Eingaben ab (Imperva). ELLIO reproduzierte die Codeausführung auch auf x86-64. Fehlgeschlagene Versuche lassen den betroffenen Prozess laut ELLIO meist abstürzen, was für sich schon einen Ausfall des Dienstes bedeutet (ELLIO).

Wird Broccoli2Shell bereits ausgenutzt?

Die Schwachstellendatenbank EUVD der EU-Agentur ENISA führt die Lücke seit dem 27. Oktober 2026 als ausgenutzt (EUVD-2026-108169). Am selben Tag hat die US-Behörde CISA sie in ihren Katalog Known Exploited Vulnerabilities (KEV) aufgenommen, nach eigenen Angaben auf Grundlage von Belegen für aktive Ausnutzung; Details zu den Angriffen nennt sie nicht (CISA, 27.10.2026). Das BSI stuft seine Warnung zu den Node.js-Lücken als „kritisch“ ein und hat am 28. Oktober 2026 den Hinweis auf einen Exploit für CVE-2026-111497 ergänzt (BSI WID-SEC-2026-4117).

Öffentlich bekannt ist Folgendes: Inzwischen sind mehrere Proof-of-Concept-Exploits veröffentlicht; mindestens einer soll laut Tenable unter engen Laborbedingungen Code auf Node.js 24.22.0 ausführen (Tenable). In einem Update vom 26. Oktober 2026 meldete ELLIO einen auf Node.js 24.22.0 zugeschnittenen Angriffsversuch. Er kombinierte Teile öffentlicher Exploits mit einer eigenen Endstufe, die in ELLIOs Tests keinen Treffer erzielte. ELLIO beobachtete zudem einen öffentlichen Prüf-Scanner, der gezielt testete, welche Server Brotli-Daten entpacken, und rät, die Lücke als ausgenutzt zu behandeln (ELLIO). Check Point meldet am 29. Oktober 2026 aus der Telemetrie seines Intrusion-Prevention-Systems breit angelegte, automatisierte Scans, teils gezielt auf Endpunkte für Uploads und Datenimporte. Auffällige Payloads und HTTP-500-Fehler wertet Check Point als klärungsbedürftig, nicht als Beleg einer erfolgreichen Kompromittierung (Check Point).

Bestätigte erfolgreiche Einbrüche über Broccoli2Shell sind bislang nicht öffentlich dokumentiert (eigene Recherche, Stand 30. Oktober 2026). Palo Alto Networks ist für seine Produkte keine böswillige Ausnutzung bekannt (Palo Alto Networks). CERT-SE empfiehlt dennoch, zügig zu aktualisieren (CERT-SE); NCSC-NL verweist in seinem Hinweis vom 23. Oktober 2026 auf die Sicherheitsupdates von Google und Node.js (NCSC-NL). Gehen Sie davon aus, dass aus dem Internet erreichbare Dienste, die Brotli-Daten entpacken, gezielt gesucht und angegriffen werden.

Sofortmaßnahmen: Updates zuerst

Nur ein Update schließt die Lücke vollständig; Übergangsmaßnahmen schützen laut Aikido insbesondere nicht vor präparierten Antworten fremder Server (Aikido, 22.10.2026). Gehen Sie in dieser Reihenfolge vor:

1. Bestand erfassen: Ermitteln Sie alle Node.js-Laufzeiten – auf Servern, CI-Runnern und Entwicklerrechnern, in Container-Images und Serverless-Funktionen. Für ein Image zeigt docker run --rm --entrypoint node <image> --version die tatsächlich enthaltene Version, ohne den Startbefehl des Images auszuführen. In Python-Umgebungen helfen pip show Brotli brotlicffi und pipdeptree -r -p Brotli, ebenso eine Suche in den Lockfiles (Aikido, 22.10.2026, Aikido, 23.10.2026). Statisch eingebundene Brotli-Kopien findet eine Suche nach geladenen Bibliotheken nicht (Tanium). Hier hilft eine aktuelle SBOM Ihrer Software und der eingekauften Produkte.
2. Richtig prüfen: process.versions.brotli taugt nicht als Nachweis. Node.js hat nur die Korrektur übernommen und die Versionskennung der mitgelieferten Bibliothek nicht angehoben (Node.js 24.22.1); gepatchte Versionen melden deshalb dieselbe Brotli-Version wie verwundbare, bei Node.js 24 etwa 1.2.0 (ELLIO). Maßgeblich ist node --version. Nutzt Node.js aus einem Paket Ihrer Distribution die Brotli-Bibliothek des Systems, entscheidet zusätzlich die Version des Brotli-Pakets (Red Hat).
3. Aktualisieren: Installieren Sie Node.js 22.23.4, 24.22.1, 26.12.1 oder neuer, Brotli 1.2.1 und brotlicffi 1.2.1.0 für Python sowie die Brotli-Pakete Ihrer Distribution. Unter .NET sind es 8.0.33, 9.0.22 oder 10.0.14, unter PAN-OS die Hotfix-Stände aus dem Hinweis von Palo Alto Networks. Node.js 20, 23 und 25 erhalten keine Korrektur mehr; wechseln Sie auf 22, 24 oder 26.
4. Neu starten und neu bauen: Ein aktualisiertes Paket auf der Festplatte ersetzt keinen Decoder, den ein laufender Prozess bereits geladen hat (Tanium). Starten Sie deshalb alle betroffenen Dienste neu, und bauen Sie Container auf gepatchten Basis-Images neu (Red Hat RHSB-2026-015). Bei einem Image-Tag wie node:24 kann der Neubau auf ein Image aus dem lokalen Cache zurückgreifen; führen Sie daher vorher docker pull aus, und prüfen Sie die Version im laufenden Container (Sysdig). Unter .NET müssen eigenständig ausgelieferte Anwendungen (self-contained) neu gebaut und NativeAOT-Anwendungen neu veröffentlicht werden (Microsoft-Advisory).
5. Hersteller und Dienstleister fragen: Bei Appliances, gehosteten Diensten und eingekauften Produkten liegt das Update beim Anbieter. Fragen Sie nach, ob und wann gepatcht wird, und verfolgen Sie die Hinweise der Hersteller.

Können Sie nicht sofort aktualisieren, verringern diese Übergangsmaßnahmen das Risiko für einzelne Angriffswege. Sicher machen sie ein System nicht:

• Brotli-Anfragen abweisen: Entfernen oder blockieren Sie Content-Encoding: br bei Anfragen nicht vertrauenswürdiger Clients am Reverse Proxy oder Load Balancer, wie Red Hat empfiehlt (Red Hat RHSB-2026-015). Erkennen Sie dabei br unabhängig von Groß- und Kleinschreibung und auch in Listen mehrerer Kodierungen (Aikido, 23.10.2026). Diese Filterung kann auch eine Web Application Firewall übernehmen. In Express 5 weist die Parser-Option inflate: false komprimierte Bodys ab, allerdings alle, auch gzip (body-parser).
• Brotli aus Python-Umgebungen entfernen: Wo die Unterstützung nicht gebraucht wird, deinstallieren Sie Brotli und brotlicffi, entfernen Extras wie httpx[brotli] und erzeugen die Lockfiles neu (Aikido, 23.10.2026). Die HTTP-Clients weichen dann auf gzip und deflate aus (OpenSourceMalware).
• Produktschalter nutzen: Unter .NET entfernen Sie br aus der Request-Dekompression von ASP.NET Core und DecompressionMethods.Brotli aus den Einstellungen von HttpClient (Microsoft-Advisory). In PAN-OS schalten Sie die Brotli-Prüfung mit set system setting brotli-encoding disable ab und kontrollieren das mit show system setting brotli (Palo Alto Networks).
• Ausgehende Abrufe begrenzen: Gegen präparierte Antworten fremder Server hilft letztlich nur das Update. Begrenzen Sie bis dahin, welche Ziele Ihre Anwendungen abrufen dürfen, etwa für Webhooks per Allowlist (Tanium), und entpacken Sie keine nicht vertrauenswürdigen Daten mit den Brotli-Funktionen von node:zlib (Red Hat RHSB-2026-015).
• Erreichbarkeit einschränken: Wo kein Update möglich ist, rät CERT-SE, den Zugriff per Firewall zu beschränken oder die Brotli-Funktion abzuschalten. Geht auch das nicht, sollen Systeme, die Brotli nutzen, weder aus unsicheren Netzen noch innerhalb von Cloud-Umgebungen erreichbar sein (CERT-SE).
• Schaden begrenzen: Betreiben Sie Node.js-Dienste mit einem Benutzer ohne besondere Rechte, und halten Sie Geheimnisse möglichst nicht in den Umgebungsvariablen des Prozesses (Sysdig).

Anzeichen eines Angriffs erkennen

Der Speicherfehler selbst hinterlässt in Anwendungslogs kaum Spuren. Tanium und ELLIO nennen Hinweise, denen Sie nachgehen sollten:

• wiederholte Abstürze oder Neustarts von Node.js-Workern und anderen Diensten, die Brotli entpacken – besonders, wenn im selben Zeitraum Anfragen mit Content-Encoding: br in den Logs von WAF oder Proxy stehen (Tanium)
• hängende Anfragen oder Worker mit dauerhaft hoher CPU-Last in Python-, PHP- oder Ruby-Diensten: Deren Decoder stürzen bei präparierten Daten laut ELLIO nicht ab, sondern liefern nichts und kehren nicht zurück (ELLIO)
• ungewöhnlich große Brotli-kodierte Request-Bodys; der von ELLIO aufgezeichnete Angriff umfasste rund 23 MB (ELLIO)
• Brotli-Antworten ungewöhnlicher Ziele in den Logs ausgehender Verbindungen (Tanium)
• Folgeaktivität wie Node.js-Prozesse, die eine Shell starten, Download-Werkzeuge aufrufen oder Programme aus temporären Verzeichnissen ausführen, sowie Änderungen an authorized_keys, cron oder systemd-Units (Tanium)

Ein einzelner Absturz beweist keinen Angriff. Imperva rät, Abstürze mit der Version der Laufzeitumgebung, den Anwendungslogs und der Herkunft der Daten abzugleichen (Imperva). Anfragen von Prüf-Scannern, die nur testen, ob ein Server Brotli entpackt, sind für sich noch kein Angriff. ELLIO wertet sie aber als Erkundung, die einer Angriffswelle vorausgehen kann. Erzwungene Abstürze können zudem Speicherabbilder (Core Dumps) mit Sitzungs- und Zugangsdaten anderer Nutzender erzeugen; ELLIO rät, Zugriff und Aufbewahrung solcher Abbilder zu begrenzen (ELLIO).

Lief ein aus dem Internet erreichbarer Dienst mit einem verwundbaren Decoder, prüfen Sie nach dem Update, ob Zugangsdaten, Tokens und Schlüssel erneuert werden müssen – die Lücke kann auch Speicherinhalte offenlegen. Bei konkretem Verdacht klärt ein Compromise Assessment, ob Angreifer Spuren hinterlassen haben. Ist ein Angriff bereits erkennbar, melden Sie den Notfall direkt bei unserem Team.

Sie wissen nicht, wo in Ihrer Umgebung Brotli steckt? Eine Schwachstellenanalyse prüft Ihre Systeme von außen und mit Anmeldung auch von innen, liest dabei installierte Pakete und Patchstände aus und priorisiert die Funde. Gebündelte und statisch gelinkte Bibliotheken in Ihrer eigenen Software deckt ein Security Code Review mit Abhängigkeitsprüfung und SBOM auf.

Checkliste: Broccoli2Shell abarbeiten

• Alle Node.js-Laufzeiten sind erfasst, auch in Containern, CI-Runnern und Serverless-Funktionen, und mit node --version geprüft, bei Distributionspaketen zusätzlich die Version des Brotli-Pakets
• Node.js läuft mit 22.23.4, 24.22.1, 26.12.1 oder neuer; Node.js 20, 23 und 25 sind abgelöst
• Brotli und brotlicffi für Python stehen auf 1.2.1 bzw. 1.2.1.0, die Brotli-Pakete der Distribution auf dem Stand des Sicherheitshinweises
• .NET ist aktualisiert, eigenständige und NativeAOT-Anwendungen sind neu gebaut
• Alle betroffenen Prozesse wurden neu gestartet, Container-Images neu gebaut und geprüft
• Firewalls mit TLS-Inspektion, Appliances und eingekaufte Produkte sind anhand der Herstellerhinweise geprüft
• Bis zum Update werden Brotli-kodierte Anfragen nicht vertrauenswürdiger Clients abgewiesen
• Logs sind auf Abstürze und Brotli-Anfragen durchgesehen, Zugangsdaten exponierter Systeme bewertet

Fazit: Patchen, neu starten, Abhängigkeiten kennen

Broccoli2Shell zeigt, wie weit ein einzelner Fehler in einer Bibliothek reicht, die oft nur als Abhängigkeit mitkommt: von Node.js und Python über .NET bis zu Firewalls und Browsern. Ein Node.js-Update allein genügt deshalb nicht. Entscheidend ist, jede Kopie des Decoders zu finden, sie zu aktualisieren und die Prozesse neu zu starten – Container eingeschlossen. Da die Lücke laut ENISA und CISA bereits ausgenutzt wird, gehören aus dem Internet erreichbare Dienste ganz nach vorn. Auf Dauer hilft ein Patch-Management, das auch gebündelte Bibliotheken erfasst und sich auf eine gepflegte SBOM stützt.

Quellen

Alle Quellen abgerufen am 30. Oktober 2026.

• Brotli-Projekt (Google): Release v1.2.1, 21.10.2026
• Brotli-Projekt (Google): Detect and report invalid stream earlier. (Commit 0ed4268), 27.02.2026
• CVE-Programm: CVE-2026-111497, 22.10.2026, Stand 28.10.2026, mit Einordnung der CISA
• Node.js-Projekt: Wednesday, October 21, 2026 Security Releases, 21.10.2026
• Node.js-Projekt: 2026-10-21, Version 24.22.1 'Krypton' (LTS), 21.10.2026
• Node.js-Projekt: Node.js Release Working Group, Release-Plan, Stand 21.10.2026
• Express-Projekt: body-parser, README der Version 2.4.0, 22.10.2026
• GitHub Advisory Database: GHSA-9v8h-qqgm-4m35 – Brotli: Out-of-bounds write in the Brotli decoder („Node2Shell“) also affects the PyPI Brotli package, 22.10.2026, Stand 29.10.2026
• Requests-Projekt: Quickstart — Requests 2.34.2 documentation, Stand 30.10.2026
• Microsoft: Microsoft Security Advisory CVE-2026-111497 – .NET Brotli Decoder Out-of-bounds Write Vulnerability, 25.10.2026
• Microsoft: Security Update Guide – Google: CVE-2026-111497 Buffer overflow vulnerability in the Brotli decoder, 25.10.2026, Stand 26.10.2026
• Palo Alto Networks: CVE-2026-111497 Portfolio Status: Impact of Brotli Vulnerability (CVE-2026-111497) on Palo Alto Networks Products, 26.10.2026, Stand 29.10.2026
• Red Hat: RHSB-2026-015 Out-of-Bounds Write – Google Brotli Decoder (CVE-2026-111497) – „node2shell“, 26.10.2026, Stand 27.10.2026
• Red Hat: CVE-2026-111497, 22.10.2026, Stand 29.10.2026
• Debian: Security Tracker – CVE-2026-111497, Stand 30.10.2026
• Ubuntu: CVE-2026-111497, 23.10.2026, Stand 29.10.2026
• BSI (CERT-Bund): WID-SEC-2026-4117 – Node.js: Mehrere Schwachstellen, 22.10.2026, Version 6 vom 29.10.2026
• NCSC-NL: NCSC-2026-0453 – Kwetsbaarheid in Google Brotli-decoder, 23.10.2026
• CERT-SE: Kritisk sårbarhet i Google Brotli, 28.10.2026
• ENISA: EUVD-2026-108169, Stand 28.10.2026
• CISA: CISA Adds Two Known Exploited Vulnerabilities to Catalog, 27.10.2026
• Imperva: Node2Shell: From Brotli Data to Remote Code Execution, 22.10.2026
• ELLIO: Node2Shell: remote code execution on stock Node.js builds (CVE-2026-111497), 25.10.2026, Stand 26.10.2026
• Aikido: Node2Shell: Node.js Brotli vulnerability allows remote code execution (CVE-2026-111497), 22.10.2026, Stand 27.10.2026
• Aikido: Node2Shell evolves to HTTP2Shell. Brotli flaw (CVE-2026-111497) blast radius affects many libraries & apps using HTTP., 23.10.2026, Stand 27.10.2026
• OpenSourceMalware: Python Packages Vulnerable to Node2Shell Brotli CVE, 23.10.2026, Stand 24.10.2026
• Tenable: Brotli2Shell: Frequently asked questions for Google Brotli decoder vulnerability (CVE-2026-111497), 26.10.2026, Stand 28.10.2026
• Check Point: HTTP2Shell: The Brotli Vulnerability That Extends Beyond Node.js, 29.10.2026
• Tanium: HTTP2Shell: Find and Fix Vulnerable Brotli Copies with Tanium, 24.10.2026, Stand 26.10.2026
• Sysdig: Node2Shell (CVE-2026-111497): Detecting the Node.js Brotli RCE, 24.10.2026, Stand 28.10.2026