Node2Shell CVE-2026-111497: Aktive RCE-Gefahr

1. Executive Summary

CVE-2026-111497 („Node2Shell“, auch „HTTP2Shell“ oder „Broccoli2Shell“) ist ein Out-of-Bounds Write im Decoder der Google-Brotli-Bibliothek. Der offizielle CVE-Record bewertet die Schwachstelle mit CVSS v4.0 9.2 (Critical); ein nicht authentisierter Angreifer kann über einen präparierten Brotli-Stream Prozesse abstürzen lassen, Speicherinhalte offenlegen oder potenziell Code ausführen. Betroffen sind Brotli 1.0.3 bis 1.2.0 sowie unter anderem unterstützte Node.js-Release-Linien, die den verwundbaren Decoder bündeln. [1] [2]

Die Bedrohungslage ist akut: CISA hat CVE-2026-111497 am 27. Oktober 2026 aufgrund nachgewiesener aktiver Ausnutzung in den Known Exploited Vulnerabilities (KEV) Catalog aufgenommen. Das ist keine reine PoC-Lage. Für die allgemeine Wirtschaft nennt CISA keine pauschale gesetzliche Frist; für US-Bundesbehörden gilt als KEV-Stichtag der 10. November 2026. [3] [4]

2. Betroffene Systeme & Versionsmatrix

Der Upstream-Fehler betrifft Google Brotli 1.0.3 bis 1.2.0 auf allen Plattformen. Als bereinigte Zielstände nennt der offizielle CVE-Record je nach Release-Zweig 1.0.10, 1.1.1 oder 1.2.1. [1]

Für direkt eingesetztes Node.js gelten folgende, öffentlich dokumentierte Mindestversionen:

CISA weist ausdrücklich darauf hin, dass es sich um eine Open-Source-Komponente handelt, die in unterschiedlichen Produkten, Libraries und Appliances eingebunden sein kann. Prüfen Sie daher nicht nur Host-Pakete, sondern auch Container-Basisimages, Build-Artefakte, Software Bill of Materials (SBOMs) und Herstelleradvisories von Produkten mit eingebettetem Node.js oder Brotli. [3]

3. Technischer Angriffsvektor

Die Schwachstelle liegt in der Behandlung eines ungültigen Blockwechsels beim Streaming-Dekodieren. Statt den Zustand als permanenten Formatfehler zurückzugeben, behandelte der verwundbare Decoder ihn als vorübergehenden Bedarf nach weiteren Eingabedaten. Dadurch werden weitere Bytes in einen internen Acht-Byte-Puffer geschrieben, bis ein Schreibzugriff außerhalb der Puffergrenze entsteht. Der Patch führt einen dedizierten Formatfehler (BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH) ein und verwirft den fehlerhaften Stream. [2] [5]

Ein Angriff setzt voraus, dass ein Angreifer kontrollierte Brotli-komprimierte Daten an einen Decoder liefern kann. Bei Node.js entsteht dieser Pfad nicht nur durch einen expliziten Aufruf von zlib.brotliDecompress() oder zlib.createBrotliDecompress(). Er kann auch über automatisch dekomprimierte Antworten der integrierten fetch()-API oder über komprimierte Request-Bodies in Express 5 beziehungsweise body-parser 2 entstehen, wenn diese mit der Voreinstellung inflate: true akzeptiert werden. Ein reiner Node.js-HTTP-Server dekodiert eingehende Brotli-Bodies hingegen nicht selbst. [5]

4. Status der Ausnutzung & Bedrohungslage

Aktiv in freier Wildbahn ausgenutzt: Ja. Die Aufnahme in den CISA-KEV-Katalog am 27. Oktober ist die maßgebliche Bestätigung. Der Katalog nennt als Status für bekannte Ransomware-Kampagnen jedoch „Unknown“. Eine Ransomware-Zuordnung wäre daher unbelegt und wird hier nicht behauptet. [3]

Die Fachberichterstattung ergänzt diese Einstufung: Sicherheitsforscher meldeten Angriffsversuche gegen Honeypots, während CISA keine technischen Details zu den konkreten Vorfällen veröffentlicht hat. Der berichtete Versuch zeigte nach Angaben des analysierenden Labs eine unvollständige beziehungsweise nicht erfolgreiche Shell-Stage. Das ändert die KEV-Einstufung nicht: Bereits erreichbare Prozessabstürze sind für öffentlich erreichbare Dienste kritisch, und funktionsfähige Codeausführung wurde in mehreren Umgebungen demonstriert. [6]

5. Konkrete Sofortmaßnahmen & Patch-Anleitung

1. Internet-exponierte Node.js-Workloads priorisieren. Erfassen Sie zuerst API-Gateways, SSR-Frontends, BFFs, Webhooks und Worker mit eingehenden komprimierten Bodies oder ausgehenden fetch()-Aufrufen. Die lokale Versionsabfrage lautet:

   node --version
   node -p "process.versions.brotli"

2. Node.js auf einen bereinigten Zielstand aktualisieren. Nutzen Sie mindestens 22.23.4, 24.22.1 oder 26.12.1. Für NVM-Installationen lautet ein möglicher Ablauf, hier beispielhaft für die 24er-Linie:

   nvm install 24.22.1
   nvm use 24.22.1
   node --version

   Über Distributionen installierte Node.js- oder Brotli-Pakete müssen ausschließlich über das Security-Repository des jeweiligen Distributors aktualisiert werden. Prüfen Sie danach die tatsächlich gelieferte Paketversion und den jeweiligen Herstellerhinweis; ein blindes Versions-Mapping zwischen Distribution und Upstream wäre fehlerhaft.

3. Container vollständig neu bauen und ausrollen. Ein Laufzeit-Update auf dem Host genügt nicht für Container mit eigener Node.js- oder Brotli-Library. Pinnen Sie ein bereinigtes Basisimage, bauen Sie ohne Cache neu, starten Sie neue Container und entfernen Sie die vorherige Revision erst nach einem Health-Check:

   FROM node:24.22.1-bookworm-slim

   docker compose build --pull --no-cache
   docker compose up -d --force-recreate
   docker compose ps

4. Bis zum Patch die Angriffsfläche reduzieren. Das Update ist die einzige vollständige Behebung. Wenn Ihre API keine komprimierten Request-Bodies benötigt, lehnen Sie Content-Encoding: br vorübergehend am Reverse Proxy oder an der WAF ab. Für Express-Parser kann die Annahme komprimierter Bodies pro Parser deaktiviert werden; testen Sie dies vor dem Rollout, da Clients dann einen HTTP-415-Fehler erhalten können:

   app.use(express.json({ inflate: false }));
   app.use(express.urlencoded({ extended: true, inflate: false }));

   Diese Maßnahme entschärft eingehende Request-Bodies, schützt aber nicht gegen eine bösartige oder kompromittierte Gegenstelle, deren Brotli-kodierte Antwort von fetch() automatisch dekomprimiert wird. Begrenzen Sie zusätzlich ausgehende Verbindungen der betroffenen Workloads auf notwendige Ziele. [5]

5. Nach Patch und vor Neu-Freigabe prüfen. Vergleichen Sie die laufende Version mit den Mindestständen, starten Sie die Prozesse kontrolliert neu und prüfen Sie Monitoring-Daten auf ungewöhnliche Node-Prozessabstürze, Restarts, OOM-Ereignisse und eingehende Content-Encoding: br-Requests. Da die Schwachstelle bereits aktiv ausgenutzt wird, sollten auffällige Ereignisse im Zeitraum vor dem Patch nach dem eigenen Incident-Response-Verfahren bewertet werden. CISA verlangt für diesen KEV-Eintrag keine verpflichtende Forensik-Triage nach BOD 26-04; das ersetzt keine eigene Risikobewertung. [3]

6. Fazit & strategische Einordnung

Node2Shell ist ein Beispiel dafür, warum Runtime- und Bibliotheksrisiken nicht allein über die Liste direkter App-Abhängigkeiten steuerbar sind. Der betroffene Decoder kann über Node.js, Container-Images, transitive Komponenten oder Produkte mit eingebetteter Laufzeit in die Infrastruktur gelangen. Eine belastbare Reaktion kombiniert daher KEV-getriebene Priorisierung, SBOM-gestützte Asset-Erfassung, reproduzierbare Container-Rebuilds und kontrollierte Egress-Regeln.

Für öffentlich erreichbare Node.js-Services ist ein Update auf 22.23.4, 24.22.1 oder 26.12.1 beziehungsweise ein vom Hersteller bestätigter Backport jetzt angemessen. Ein WAF-Filter oder das Abschalten komprimierter Bodies ist nur eine zeitlich begrenzte Risikoreduktion. Wenn Sie Unterstützung bei der Expositionsanalyse, Priorisierung oder Absicherung Ihrer Web- und KI-Services benötigen, erreichen Sie Gato Dynamics unter support@gatodynamics.tech oder auf gatodynamics.de.

7. Offizielle Quellen & Referenzen

• [1] CVE.org: CVE-2026-111497 CVE Record (Offizielle Datenbank)
• [2] Node.js Foundation: Node.js Security Releases vom 21. Oktober 2026
• [3] CISA: CISA Known Exploited Vulnerabilities Catalog zu CVE-2026-111497
• [4] CISA Alerts: CISA Adds Two Known Exploited Vulnerabilities to Catalog
• [5] Akamai Security Research: Akamai technische Analyse zu Node2Shell
• [6] SecurityWeek: SecurityWeek zu beobachteten Node2Shell-Angriffsversuchen