← Zur Übersicht aller Beiträge
Node2Shell: Sicherheitsupdates schließen Brotli-RCE in Node.js
Präparierte Brotli-Daten können in betroffenen Node.js-Versionen Speicher beschädigen und Codeausführung ermöglichen. Ein unabhängiger Labortest bestätigt die RCE; aktualisierte 22.x-, 24.x- und 26.x-Versionen stehen bereit.
Node2Shell: Sicherheitsupdates schließen Brotli-RCE in Node.js
Präparierte Brotli-Daten können in betroffenen Node.js-Versionen Speicher beschädigen und Codeausführung ermöglichen. Ein unabhängiger Labortest bestätigt die RCE; aktualisierte 22.x-, 24.x- und 26.x-Versionen stehen bereit.
Für die noch unterstützten Node.js-Zweige 22.x, 24.x und 26.x stehen Sicherheitsupdates gegen eine hoch eingestufte Brotli-Schwachstelle bereit. CVE-2026-111497 entsteht im mitgelieferten Dekompressor: Ein ungültiger Blockwechsel kann falsch als vorübergehender Datenmangel behandelt werden. Der Decoder schreibt dann über das Ende eines internen Puffers hinaus. Nach Angaben des Node.js-Projekts sind Absturz, Offenlegung von Prozessspeicher und entfernte Codeausführung möglich.
Das Risiko betrifft nicht automatisch jeden Node-Dienst. Angreifbare Pfade entstehen dort, wo eine Anwendung nicht vertrauenswürdige Brotli-Daten mit `node:zlib` verarbeitet – beispielsweise komprimierte Antworten fremder Server oder eingehende Requests, die Middleware automatisch entpackt.
Unabhängiger Test bestätigt Codeausführung
Imperva hat die Auswirkung mit dem offiziellen Node.js-Image 24.22.0 unter Linux ARM64 praktisch nachvollzogen. In frischen Containern führte präparierter Brotli-Inhalt Code im Zielprozess aus. Der identische Input wurde von Node.js 24.22.1 abgewiesen. Getestet wurden sowohl eine über `fetch()` konsumierte Antwort als auch eingehende Brotli-Request-Bodies mit Express und body-parser.
Der Versuch belegt die technische Ausnutzbarkeit, aber keine laufende Angriffskampagne. Die Redaktion hat keine belastbare Quelle gefunden, die CVE-2026-111497 bereits als in freier Wildbahn ausgenutzt einstuft. Unternehmen sollten deshalb weder Entwarnung geben noch eine Kompromittierung behaupten, sondern Exposition und Patchstand nachvollziehbar prüfen.
Welche Versionen geprüft werden müssen
Node.js nennt die Linien 22.x, 24.x und 26.x als betroffen und hat dafür Sicherheitsveröffentlichungen bereitgestellt. Impervas Gegenprobe bestätigt die Korrektur konkret für 24.22.1. Für die eigene Umgebung ist die aktuelle Sicherheitsversion des jeweils verwendeten Zweigs maßgeblich; Container-Basisimages, Build-Pipelines, serverlose Laufzeiten und von Dienstleistern betriebene Anwendungen gehören ausdrücklich in die Bestandsaufnahme.
Praktische Reaktion für Betrieb und Entwicklung
Verantwortliche sollten zuerst laufende Node.js-Versionen und Images inventarisieren, dann alle Stellen erfassen, an denen Brotli automatisch oder ausdrücklich dekomprimiert wird. Internetseitige APIs, Proxy- oder Abrufdienste und Integrationen mit fremden Endpunkten haben Vorrang. Nach dem Update sollten Build und Laufzeit neu ausgerollt sowie die tatsächlich gestartete Version kontrolliert werden.
Bis zum Patch kann es sinnvoll sein, Brotli an nicht benötigten Eingängen abzuschalten oder die Annahme komprimierter Bodies zu begrenzen. Eine WAF-Regel ist höchstens eine zusätzliche Schutzschicht; sie ersetzt die korrigierte Laufzeit nicht. Für die Nachweisführung gehören betroffene Dienste, vorherige und neue Version, Rollout-Zeitpunkt und Funktionsprüfung in denselben Vorgang.
Der Beitrag ist keine Fortsetzung von PHP2Shell: Dort betreffen die Fehler die PHP-Laufzeit und bereits beobachtete Angriffsversuche. Hier liegt ein eigenständiger Node.js/Brotli-Fehler mit neuer Herstellerkorrektur und unabhängig reproduzierter RCE vor.
Konzept und redaktionelle Auswahl basieren auf Vorgaben von Christian Hohlfeld; Recherche und Formulierung wurden durch KI unterstützt. Eine individuelle menschliche Freigabe steht noch aus.
Ein Update nur der Anwendungspakete reicht nicht, wenn darunter weiterhin eine verwundbare Node.js-Laufzeit arbeitet. Umgekehrt bedeutet die bloße Installation von Express nicht, dass Brotli-Request-Bodies tatsächlich akzeptiert werden. Entscheidend ist der reale Datenpfad.
Für die noch unterstützten Node.js-Zweige 22.x, 24.x und 26.x stehen Sicherheitsupdates gegen eine hoch eingestufte Brotli-Schwachstelle bereit. CVE-2026-111497 entsteht im mitgelieferten Dekompressor: Ein ungültiger Blockwechsel kann falsch als vorübergehender Datenmangel behandelt werden. Der Decoder schreibt dann über das Ende eines internen Puffers hinaus. Nach Angaben des Node.js-Projekts sind Absturz, Offenlegung von Prozessspeicher und entfernte Codeausführung möglich.
Das Risiko betrifft nicht automatisch jeden Node-Dienst. Angreifbare Pfade entstehen dort, wo eine Anwendung nicht vertrauenswürdige Brotli-Daten mit `node:zlib` verarbeitet – beispielsweise komprimierte Antworten fremder Server oder eingehende Requests, die Middleware automatisch entpackt.
Unabhängiger Test bestätigt Codeausführung
Imperva hat die Auswirkung mit dem offiziellen Node.js-Image 24.22.0 unter Linux ARM64 praktisch nachvollzogen. In frischen Containern führte präparierter Brotli-Inhalt Code im Zielprozess aus. Der identische Input wurde von Node.js 24.22.1 abgewiesen. Getestet wurden sowohl eine über `fetch()` konsumierte Antwort als auch eingehende Brotli-Request-Bodies mit Express und body-parser.
Der Versuch belegt die technische Ausnutzbarkeit, aber keine laufende Angriffskampagne. Die Redaktion hat keine belastbare Quelle gefunden, die CVE-2026-111497 bereits als in freier Wildbahn ausgenutzt einstuft. Unternehmen sollten deshalb weder Entwarnung geben noch eine Kompromittierung behaupten, sondern Exposition und Patchstand nachvollziehbar prüfen.
Welche Versionen geprüft werden müssen
Node.js nennt die Linien 22.x, 24.x und 26.x als betroffen und hat dafür Sicherheitsveröffentlichungen bereitgestellt. Impervas Gegenprobe bestätigt die Korrektur konkret für 24.22.1. Für die eigene Umgebung ist die aktuelle Sicherheitsversion des jeweils verwendeten Zweigs maßgeblich; Container-Basisimages, Build-Pipelines, serverlose Laufzeiten und von Dienstleistern betriebene Anwendungen gehören ausdrücklich in die Bestandsaufnahme.
Praktische Reaktion für Betrieb und Entwicklung
Verantwortliche sollten zuerst laufende Node.js-Versionen und Images inventarisieren, dann alle Stellen erfassen, an denen Brotli automatisch oder ausdrücklich dekomprimiert wird. Internetseitige APIs, Proxy- oder Abrufdienste und Integrationen mit fremden Endpunkten haben Vorrang. Nach dem Update sollten Build und Laufzeit neu ausgerollt sowie die tatsächlich gestartete Version kontrolliert werden.
Bis zum Patch kann es sinnvoll sein, Brotli an nicht benötigten Eingängen abzuschalten oder die Annahme komprimierter Bodies zu begrenzen. Eine WAF-Regel ist höchstens eine zusätzliche Schutzschicht; sie ersetzt die korrigierte Laufzeit nicht. Für die Nachweisführung gehören betroffene Dienste, vorherige und neue Version, Rollout-Zeitpunkt und Funktionsprüfung in denselben Vorgang.
Der Beitrag ist keine Fortsetzung von PHP2Shell: Dort betreffen die Fehler die PHP-Laufzeit und bereits beobachtete Angriffsversuche. Hier liegt ein eigenständiger Node.js/Brotli-Fehler mit neuer Herstellerkorrektur und unabhängig reproduzierter RCE vor.
Konzept und redaktionelle Auswahl basieren auf Vorgaben von Christian Hohlfeld; Recherche und Formulierung wurden durch KI unterstützt. Eine individuelle menschliche Freigabe steht noch aus.
Quellen
Transparenz: Konzept, Auswahlkriterien und inhaltliche Vorgaben stammen von Christian Hohlfeld. Recherche und Formulierung wurden nach diesen Vorgaben mit KI-Werkzeugen unterstützt. Redaktionell geprüft und freigegeben von Christian Heinrich Hohlfeld am .