Technik & Sicherheit · · 7 Min. Lesezeit
Node2Shell: Was Website-Betreiber jetzt prüfen müssen
Node2Shell bezeichnet eine schwere Sicherheitslücke im Brotli-Decoder von Node.js. Dieser entpackt komprimierte Daten. Manipulierte Eingaben können Speicher beschädigen und unter bestimmten Bedingungen fremden Code ausführen lassen. Entscheidend ist, ob eine ungepatchte Node.js-Laufzeit solche Daten verarbeitet. Lassen Sie den Hoster oder Entwickler die tatsächlich laufende Anwendung prüfen und betroffene Laufzeiten aktualisieren. Stand: 23. Oktober 2026.
Was ist passiert?
CVE-2026-111497 betrifft Brotlis Decoder, den Node.js verwendet. Ein präparierter Datenstrom kann außerhalb des vorgesehenen Speicherbereichs schreiben. Mögliche Folgen sind Speicherbeschädigung, Offenlegung von Speicherinhalten, Absturz und unter geeigneten Bedingungen Codeausführung.
Node.js bewertet die Lücke als „high“. Google nennt als zuständige CVE-Vergabestelle (CNA) für Brotli nach CVSS 4.0 einen Wert von 9,2 und „Critical“. Das sind unterschiedliche Bewertungen; ein Widerspruch folgt daraus nicht. Der Wert stammt nicht aus einer hier verifizierten eigenen NVD-Bewertung. Er beschreibt weder eine Einbruchswahrscheinlichkeit noch beobachtete Angriffe.
Die Node.js-Fixes erschienen am 21. Oktober 2026. Imperva berichtete am 22. Oktober über Codeausführung im Labor auf dem unveränderten offiziellen Node.js-Image 24.22.0 unter Linux arm64. Getestet wurden `fetch()` und bestimmte Express-/body-parser-Konfigurationen mit komprimierten Anfragen. Version 24.22.1 wies dieselben Eingaben zurück. Die Übertragbarkeit auf andere Umgebungen bleibt offen.
Wie gefährlich ist das wirklich?
Impervas Proof of Concept (PoC) ist ein berichteter Machbarkeitsnachweis unter Laborbedingungen. Er ist weder ein belegter Angriff auf eine produktive Website noch ein bestätigter Einbruch. Zum Rechercheabschluss am 23. Oktober enthielten die geprüften Primärquellen keine bestätigte aktive Ausnutzung. Auch im geprüften CISA-KEV-Katalog mit Stand 21. Oktober fehlte die CVE. Unbekannte Angriffe sind damit nicht ausgeschlossen.
Ein einfacher Server mit `http.createServer()` entpackt eingehende Brotli-Bodies nicht automatisch. Bei Express/body-parser müssen Route, Medientyp und aktivierte Dekompression zusammenpassen. Express allein belegt keine Betroffenheit. Weitere Einstiegspunkte sind Brotli-Antworten auf externe Abrufe mit Nodes `fetch()` sowie direkte Dekompression über `node:zlib`.
Lassen Sie deshalb auch URL-Importe, Vorschauen und Bildabrufe prüfen. Entscheidend ist, ob von Angreifern beeinflussbare Daten den verwundbaren Decoder erreichen. Das Komprimieren eigener Antworten ist ein anderer Vorgang.
Welche Versionen beheben die Lücke?
Die folgenden Grenzen gelten für reguläre Node.js-Builds und ausschließlich für diese CVE, nicht als allgemeine Sicherheitsgarantie.
Distributionen können Korrekturen in Pakete mit älterer Versionsnummer zurückportieren. Lassen Sie vollständige Paketrevision, Distribution und Hersteller-Advisory nachweisen. Prüfen lassen sollten Sie auch, ob Node.js eingebettetes oder systemseitiges Brotli nutzt. Bei Debian ist System-Brotli maßgeblich; der recherchierte Trackerstand enthielt noch kein Fixpaket. Ubuntu führte Node.js und Brotli auf „Needs evaluation“. Diese Recherche bestätigt für beide keine Fixpaketnummer.
- Node.js 22.x: mindestens 22.23.4.
- Node.js 24.x: mindestens 24.22.1.
- Node.js 26.x: mindestens 26.12.1.
- Node.js 20: Supportende (EOL) seit 30. April 2026; kein offizielles Upstream-Fixrelease in der Recherche belegt. Auf eine unterstützte, gepatchte Linie wechseln.
- Node.js 18 und ältere sowie 21, 23 und 25: ebenfalls ausgelaufen. Migrieren oder einen konkreten Anbieter-Fix nachweisen lassen. Historische Einzelversionen wurden nicht vollständig auf diese Lücke geprüft.
Wie kläre ich meine Betroffenheit?
Bei Shared oder Managed Hosting ohne Shell-Zugriff lassen Sie den Hoster prüfen, ob und wo Ihr Projekt Node.js verwendet. „Der Server ist aktuell“ belegt den Patchstand Ihrer Anwendung nicht. Node.js ist hier die Laufzeit, in der die Anwendung ausgeführt wird.
WordPress selbst benötigt PHP. Zusätzliche Node-Backends, separate Frontends und Build-Werkzeuge bleiben zu prüfen. Bei ausschließlich statisch ausgelieferten HTML-, CSS- und JavaScript-Dateien besteht beim Abruf kein Node.js-Serverpfad dieser Anwendung. Ihre Erstellung, der Build, kann dennoch Node.js und externe Abrufe nutzen.
Bei Next.js zählen Betriebsart und Laufzeit: Serverseitige Seitenerzeugung, API-Routen, Route Handlers und Bildoptimierung prüfen lassen. Ein statischer Export erfordert weiterhin die Build-Prüfung. Für Edge-Funktionen muss der Anbieter die tatsächliche Implementierung nennen; Node.js-Versionsgrenzen lassen sich nicht pauschal übertragen.
- Entwickler prüfen im Anwendungskontext `node --version`. Zusätzlich müssen `process.version` und `process.execPath` aus dem laufenden Anwendungsprozess oder dessen Startprotokoll Version und Programmpfad belegen. Eine beliebige SSH-Shell genügt nicht.
- Bei Containern Image, Tag und Digest dokumentieren; Basis aktualisieren, neu bauen, vollständig ausrollen und im neuen laufenden Container nachprüfen. Ein Host-Update ändert das Image nicht.
- Bei Plesk die ausgewählte Runtime der Domain prüfen. Panel-Version und verfügbare Runtimes belegen nicht den laufenden Anwendungsstand.
- Auch automatische Build-Jobs, CI-Runner und deren Container kontrollieren. Lokale Entwicklerinstallationen belegen deren Stand nicht.
Was schreibe ich meinem Hoster oder Entwickler?
Diese Anfrage können Sie mit Ihrer Domain oder Ihrem Projektnamen weitergeben:
„Betreff: CVE-2026-111497 für [Domain/Projekt]. Guten Tag, bitte prüfen Sie, ob unsere Anwendung Node.js verwendet und fremde Brotli-Daten verarbeitet. Die korrigierten offiziellen Releases sind 22.23.4, 24.22.1 und 26.12.1. Welche Version und welcher Programmpfad laufen tatsächlich? Bitte belegen Sie dies aus dem Anwendungsprozess oder Startprotokoll. Bei Containern: Welches Image mit Tag und Digest ist ausgerollt? Bei Backports: Welche Paketrevision und welches Hersteller-Advisory belegen den Fix, und wird systemseitiges Brotli verwendet? Sind alle Webprozesse, Worker und Instanzen neu gestartet oder ersetzt und danach kontrolliert worden? Bitte prüfen Sie auch Express/body-parser, `fetch()`, Bildoptimierung, `node:zlib`, zusätzliche Backends und Build-Runner. Falls das Update aussteht: Welche Übergangsmaßnahme greift, welche Pfade bleiben offen und wann folgt das Update? Bitte bestätigen Sie den ausgerollten Stand mit Nachweis. Vielen Dank.“
Ein neu gebautes Image muss auch ausgerollt werden. Nach dem Update alle betroffenen Prozesse neu starten oder ersetzen und den aktiven Stand erneut prüfen lassen.
Was hilft bis zum Update?
Übergangsmaßnahmen ersetzen den Patch nicht. Entwickler können in allen betroffenen Express-/body-parser-Parsern mit `inflate: false` komprimierte Anfragen zurückweisen. Das betrifft nicht nur Brotli und kann legitime Clients beeinträchtigen. Andere Parser, externe Abrufe und direkte Decoder-Aufrufe bleiben gesondert zu prüfen.
Ein vorgeschalteter Proxy oder eine Web Application Firewall (WAF) kann Brotli-kodierte Anfragen abweisen. Dafür müssen alle einschlägigen Zugänge erfasst sein; direkte Zugriffe auf den Ursprungsserver dürfen den Filter nicht umgehen. Externe Antworten an `fetch()` werden dadurch nicht abgesichert.
Betroffene Import-, Vorschau- oder Abruffunktionen lassen sich bis zum Patch einschränken oder pausieren. Ein anderer `Accept-Encoding`-Header ist gegenüber einem bösartigen Antwortserver keine belastbare Sperre. Auch das Abschalten der Brotli-Auslieferung am CDN belegt keinen Schutz des Decoders.
Vercel beschreibt in seinem Bulletin vom 21. Oktober WAF-Regeln und einen laufenden Runtime-Patchrollout; ein Abschluss ist hier nicht belegt. Bei 22.x/24.x verwaltet Vercel die Patchversionen. Projekte auf 20.x sollen auf 22 oder 24 wechseln und neu deployen. Externe Backends sind separat zu prüfen.
Häufige Fragen zu Node2Shell
Reichen aktuelle WordPress-Plugins?
Nein, falls zusätzliche Node.js-Dienste betroffen sind. WordPress selbst benötigt PHP; Plugin-Updates ersetzen keinen Node.js-Patch. Andere Software mit betroffener Brotli-Bibliothek ist dadurch ebenfalls nicht geprüft.
Schützt Cloudflare oder eine WAF?
Eine konkrete Cloudflare-Regel zu dieser CVE ist in der Recherche nicht belegt. WAF-Schutz ersetzt weder das Runtime-Update noch die Prüfung externer Antworten und direkter Decoder-Nutzung.
Was gilt für eine statische Website?
Die fertigen Dateien haben keinen Node.js-Serverpfad dieser Anwendung. Build-Umgebung und zusätzliche API-Dienste bleiben separat zu prüfen.
Ich habe keinen Konsolenzugriff. Was tun?
Senden Sie dem Hoster die Anfrage oben. Verlangen Sie einen Nachweis für Ihre Domain einschließlich des laufenden Patchstands und des Neustarts oder Redeploys.
Was gilt für Next.js auf Vercel?
Den aktuellen Stand beim Anbieter bestätigen lassen. Vercels WAF erfasst Verkehr durch dessen Netzwerk, ausdrücklich keine externen Antworten an `fetch()`. Selbst gehostetes Next.js blockiert laut Vercel Brotli-Antworten bei der Bildoptimierung nicht.
Beweist der PoC einen Einbruch bei mir?
Nein. Der Laborbericht belegt keinen Vorfall auf Ihrer Website. Umgekehrt beweisen fehlende bestätigte Fälle in den recherchierten Quellen nicht, dass Angriffe ausgeschlossen sind.