Schwachstelle im Node.js-Brotli-Decoder ermöglicht Remote-Code-Ausführung in offiziellen Builds

Sicherheitsforscher bei Imperva haben eine kritische Schwachstelle für Remote-Code-Ausführung (RCE) in der offiziellen Node.js-Laufzeitumgebung demonstriert. Durch das Einspeisen speziell präparierter Brotli-Komprimierungsdaten in den mitgelieferten Decoder konnten sie beliebigen Code auf einem Standard-Linux-arm64-Build von Node.js 24.22.0 ausführen. Das Node.js-Team hat die Schwachstelle, die als CVE-2026-111497 verfolgt wird, offengelegt und am 21. Oktober Fixes veröffentlicht. Entwickler werden dringend aufgefordert, jede Anwendung zu aktualisieren, die nicht vertrauenswürdige Brotli-Streams verarbeitet.

Was passiert ist

Die Demonstration, genannt "Node2Shell", stellt eine erhebliche Eskalation gegenüber früheren Proof-of-Concept-Versuchen dar. Bisherige Forscher hatten Code-Ausführung nur auf absichtlich geschwächten Test-Builds erreicht, während Standard-Builds lediglich abstürzten oder begrenzte Speicherlesungen zuließen. Das Team von Imperva führte seinen Exploit jedoch auf einem offiziellen Node.js-24.22.0-Image ohne Debugger oder eigene Modifikationen aus. Obwohl der Exploit nicht deterministisch war und mehrere Versuche zum Erfolg in ihrer Linux-arm64-Umgebung erforderte, bestätigte er, dass eine vollständige Code-Ausführung auf produktionsreifen Setups möglich ist.

Diese Schwachstelle betrifft eine breite Palette von Anwendungen, da sie sich im Brotli-Decoder befindet, der direkt in Node.js integriert ist. Sie wirkt sich auf die aktiven Release-Linien 22.x, 24.x und 26.x aus. Das Risiko besteht immer dann, wenn eine Anwendung komprimierte Brotli-Daten dekodiert. Dies kann auf zwei Hauptwegen geschehen: beim Lesen einer komprimierten Antwort über die eingebaute fetch()-API oder wenn Middleware explizit einen komprimierten Request-Body dekodiert. Beispielsweise verarbeiten die Body-Parser von Express 5 nun Brotli neben gzip und deflate, was bedeutet, dass viele moderne Backend-Services gefährdet sind, wenn sie eingehende Anfragen aus nicht vertrauenswürdigen Quellen verarbeiten.

Imperva testete diesen Vektor unter Verwendung von Express 5.0.0 bis 5.3.0 und body-parser 2.0.0 bis 2.3.0 und reproduzierte die Code-Ausführung sowohl über Request- als auch über Response-Pfade. Ein einfacher Node.js-HTTP-Server ist standardmäßig nicht verwundbar, es sei denn, er verwendet Middleware oder explizite Aufrufe zur Dekodierung des Bodies. Stand 22. Oktober gab es keine Berichte über aktive Ausnutzung in freier Wildbahn, aber die Verfügbarkeit eines funktionierenden Proof of Concept auf offiziellen Builds erhöht die Dringlichkeit für das Patching.

Wie es funktioniert

Die Ursache liegt darin, wie der integrierte Brotli-Decoder ungültige Zustandsübergänge innerhalb eines komprimierten Streams behandelt. Ein Brotli-Stream kündigt die Typen der Blöcke an, die während des Dekodierens verwendet werden. In dem von Imperva präparierten bösartigen Input erreichte der Stream einen Blockwechsel, der durch seine eigene Struktur ausdrücklich als unmöglich ausgeschlossen wurde. Anstatt diesen Widerspruch abzulehnen, interpretierte der verwundbare Decoder ihn als Anforderung nach mehr Eingabe und fuhr fort, in einem ungültigen Zustand zu verarbeiten.

Wenn der Decoder in diesem korrupten Zustand weiterläuft, erzwingt er keine ordnungsgemäßen Boundary-Checks. Tests mit einem Memory Sanitizer zeigten, dass dieser Logikfehler zu einem Out-of-Bounds-Write führt, bei dem Daten über die vorgesehenen Buffer-Grenzen hinaus geschrieben werden. Diese Speicherbeschädigung schafft die Möglichkeit für einen Angreifer, Code zu injizieren und auszuführen. Das Node.js-Projekt löste das Problem durch die Übernahme eines Upstream-Patches aus der Brotli-Bibliothek. Dieser Fix stellt sicher, dass der Decoder sofort stoppt und einen Formatfehler zurückgibt, wenn solche unmöglichen strukturellen Widersprüche auftreten, wodurch verhindert wird, dass der ungültige Zustand jemals eintritt.

Wichtige Details

• Vulnerability ID: CVE-2026-111497 betrifft den integrierten Brotli-Decoder in Node.js.
• Betroffene Versionen: Die aktiven Release-Linien 22.x, 24.x und 26.x sind verwundbar; End-of-Life-Versionen wie 20.x erhalten keine Fixes.
• Angriffsvektor: Präparierte Brotli-Daten, die über HTTP-Request-Bodies (dekodiert durch Middleware) gesendet oder über fetch()-Antworten empfangen werden.
• Exploit-Zuverlässigkeit: Der Proof of Concept von Imperva erforderte mehrere Versuche zum Erfolg auf Linux arm64 und wurde auf anderen Architekturen nicht getestet.
• Fix-Status: Patches wurden am 21. Oktober veröffentlicht; Version 24.22.1 lehnt die bösartigen Daten sicher ab.
• Kein Runtime-Workaround: Die Advisory besagt, dass es keine Konfigurationsänderung innerhalb von Node.js gibt, um dies zu mildern; das Update ist das einzige Mittel.

Warum es wichtig ist

Für Software-Ingenieure und technische Leads hebt diese Schwachstelle ein verstecktes Risiko in Abhängigkeitsketten hervor. Da der Fehler in der Laufzeitumgebung selbst liegt und nicht in einem Drittanbieter-npm-Paket, erkennen Standard-Tools zur Paketinventarisierung ihn möglicherweise nicht. Entwickler gehen oft davon aus, dass Kompressionsbibliotheken sichere Low-Level-Utilities sind, aber dieser Vorfall beweist, dass sie ein direkter Weg zur Remote-Code-Ausführung sein können. Services, die externe APIs proxyen oder User-Uploads akzeptieren, sind besonders gefährdet, wenn sie Inhalte automatisch ohne strenge Validierung dekomprimieren.

Das Fehlen eines Runtime-Workarounds bedeutet, dass operative Teams nicht einfach ein Feature-Flag umschalten können, um sicher zu bleiben. Wenn Ihre Infrastruktur auf Container-Images oder vorgefertigten Artefakten basiert, müssen Sie sicherstellen, dass die zugrunde liegende Node.js-Binary aktualisiert ist. Oft erfordert dies das Neuaufbauen und erneute Bereitstellen von Services, nicht nur deren Neustart. Darüber hinaus haben Plattformen wie Vercel Web Application Firewall-Regeln hinzugefügt, um eingehende Angriffe zu blockieren, aber diese schützen nicht vor bösartigen Brotli-Antworten, die Ihr Server von anderen Hosts abruft, sodass der ausgehende Pfad bis zum Patching verwundbar bleibt.

Was Sie tun können

• Aktualisieren Sie alle Node.js-Instanzen sofort auf die neuesten gepatchten Versionen in den Linien 22.x, 24.x oder 26.x.
• Prüfen Sie Ihre Container-Images und CI/CD-Pipelines daraufhin, ob die Basis-Node.js-Binary aktualisiert ist, nicht nur der Anwendungscode.
• Identifizieren Sie Services, die Express 5 oder body-parser verwenden und nicht vertrauenswürdige Request-Bodies akzeptieren, und priorisieren Sie deren Patching.
• Überprüfen Sie die Nutzung der eingebauten fetch()-API, um sicherzustellen, dass Antworten von externen, nicht vertrauenswürdigen Servern vorsichtig behandelt werden.
• Migrieren Sie alle Anwendungen, die noch auf End-of-Life-Versionen wie 20.x laufen, auf eine unterstützte Release-Linie, um Sicherheitsfixes zu erhalten.
• Überwachen Sie Logs auf ungewöhnliche Abstürze oder Speicherfehler in Services, die komprimierte Daten verarbeiten, was auf versuchte Ausnutzung hinweisen kann.