Nach PHP2Shell sorgt inzwischen die nächste kritische Sicherheitslücke im Webserver-Umfeld für Aufmerksamkeit.

Diesmal betrifft es Node.js.

Die unter CVE-2026-111497 geführte Schwachstelle steckt im von Node.js verwendeten Brotli-Decoder und kann unter bestimmten Voraussetzungen dazu führen, dass Angreifer eigenen Code auf einem Server ausführen.

Die Sicherheitslücke wird inzwischen häufig als Node2Shell bezeichnet.

Besonders relevant ist die Entwicklung der vergangenen Tage:

Forscher konnten die Remote Code Execution inzwischen sowohl auf ARM64 als auch auf x86-64 mit offiziellen, unveränderten Node.js-Builds demonstrieren.

Und erste speziell präparierte Angriffsversuche wurden inzwischen auch im Internet beobachtet.

Was ist Node2Shell?

Node2Shell betrifft den Brotli-Dekomprimierer, der in Node.js integriert ist.

Brotli ist ein Kompressionsverfahren, das beispielsweise bei Webseiten und Webdiensten verwendet werden kann, um Daten kleiner zu übertragen.

Das Problem entsteht bei speziell manipulierten komprimierten Daten.

Der Decoder kann bei einer ungültigen Struktur in einen fehlerhaften Zustand geraten und anschließend Daten außerhalb des eigentlich vorgesehenen Speicherbereichs schreiben.

Technisch handelt es sich also um einen sogenannten:

Out-of-Bounds Write.

Die Folgen können unterschiedlich ausfallen.

Möglich sind unter anderem:

• Absturz des Node.js-Prozesses

• Offenlegung von Speicherinhalten

• Speicherbeschädigung

• im schlimmsten Fall Remote Code Execution

Letzteres wurde inzwischen praktisch demonstriert.

Kein theoretischer RCE mehr

Anfangs war noch nicht klar, wie zuverlässig sich aus dem Speicherfehler tatsächlich eine Codeausführung auf normalen Node.js-Systemen bauen lässt.

Frühe öffentliche Proofs of Concept führten auf normalen Builds teilweise lediglich zu Abstürzen oder begrenzten Speicherzugriffen.

Das hat sich inzwischen geändert.

Forscher von Imperva demonstrierten eine erfolgreiche Codeausführung auf einem offiziellen:

Node.js 24.22.0 für Linux ARM64

Dabei wurde kein speziell abgeschwächter Test-Build verwendet.

Auch ein Debugger war nicht notwendig.

Genau das macht die Sache deutlich interessanter.

Auch x86-64 wurde erfolgreich ausgenutzt

Wenig später legte das Sicherheitsunternehmen ELLIO nach.

Die Forscher konnten Node2Shell ebenfalls auf x86-64 ausnutzen.

Damit betrifft der praktische Nachweis auch die Architektur, die auf sehr vielen klassischen Servern und Cloud-Systemen eingesetzt wird.

Getestet wurde wieder Node.js 24.22.0 mit offiziellen Binärdateien und normalen Systemeinstellungen.

Die Adressraumrandomisierung ASLR blieb dabei eingeschaltet.

Das ist wichtig, denn ASLR soll eigentlich verhindern, dass Angreifer zuverlässig wissen, wo sich bestimmte Daten und Programmteile im Speicher befinden.

Trotzdem gelang die Codeausführung.

Mehrere typische Node.js-Umgebungen waren ausnutzbar

ELLIO konnte die Schwachstelle in mehreren verschiedenen Konfigurationen demonstrieren.

Dazu gehörten:

• ein Node.js-HTTP-Server

• das offizielle Node.js-24.22.0-Slim-Container-Image

• Express 5.3.0

• Koa 3

In allen getesteten Fällen konnte eine Shell innerhalb des Sicherheitskontexts des laufenden Node.js-Prozesses gestartet werden.

Das bedeutet allerdings nicht automatisch Root-Zugriff.

Die ausgeführten Befehle besitzen zunächst die Rechte des jeweiligen Node.js-Dienstes.

Läuft der Container oder Prozess allerdings als Root, sieht die Situation entsprechend unangenehmer aus.

Wann ist eine Node.js-Anwendung überhaupt gefährdet?

Hier ist eine wichtige Einschränkung notwendig.

Nur weil irgendwo Node.js installiert ist, bedeutet das nicht automatisch, dass ein Angreifer Node2Shell über das Internet ausnutzen kann.

Die Anwendung muss nicht vertrauenswürdige Brotli-Daten tatsächlich dekomprimieren.

Genau dort liegt der entscheidende Punkt.

Ein einfacher Node.js-HTTP-Server dekomprimiert einen eingehenden Brotli-Request nicht automatisch nur deshalb, weil er ihn empfängt.

Erst wenn die Anwendung oder verwendete Middleware die Daten tatsächlich durch den betroffenen Decoder schickt, entsteht der relevante Angriffspfad.

Express 5 kann betroffen sein

Bei Express 5 wird das Thema besonders interessant.

Die integrierten Body-Parser können inzwischen neben gzip und deflate auch Brotli-komprimierte Request-Bodies verarbeiten.

Dazu gehören Funktionen wie:

• express.json()

• express.urlencoded()

• express.text()

• express.raw()

Wenn eine entsprechende Route Brotli-Daten von nicht vertrauenswürdigen Clients entgegennimmt und dekomprimiert, kann die verwundbare Node.js-Runtime erreicht werden.

Das macht Node2Shell für reale Webanwendungen durchaus relevant.

Auch ausgehende Requests können ein Problem sein

Der Angriff muss allerdings nicht zwingend über einen eingehenden HTTP-Request erfolgen.

Auch die andere Richtung ist möglich.

Node.js-Anwendungen können beispielsweise über das integrierte:

fetch()

Daten von anderen Servern abrufen.

Wenn eine Anwendung dabei eine manipulierte Brotli-komprimierte Antwort erhält und Node.js diese dekomprimiert, kann ebenfalls der verwundbare Decoder erreicht werden.

Das bedeutet:

Eine vorgeschaltete Web Application Firewall schützt nicht automatisch vor jedem denkbaren Angriffspfad.

Genau deshalb reicht eine WAF allein nicht

Eine WAF kann eingehende manipulierte Requests erkennen oder blockieren.

Das kann durchaus als zusätzliche Schutzschicht sinnvoll sein.

Sie kann aber beispielsweise eine bösartige Brotli-Antwort eines externen Servers nicht unbedingt verhindern, die eine Node.js-Anwendung selbst per fetch() abruft.

Der eigentliche Fehler steckt außerdem im Brotli-Decoder.

Deshalb bleibt die wichtigste Maßnahme:

Node.js aktualisieren.

Alles andere ist lediglich zusätzliche Risikoreduzierung.

Diese Node.js-Versionen sind betroffen

Node.js bestätigt die Schwachstelle für die aktuell unterstützten Linien:

• Node.js 22.x

• Node.js 24.x

• Node.js 26.x

Die korrigierten Versionen wurden am 21. Oktober 2026 veröffentlicht.

Administratoren sollten mindestens auf folgende Builds wechseln:

Wer noch einen älteren beziehungsweise inzwischen eingestellten Node.js-Zweig verwendet, sollte auf eine unterstützte Version wechseln.

Node.js bewertet die Lücke als „High“

Bei der Einstufung gibt es eine interessante Besonderheit.

Das Node.js-Projekt selbst führt CVE-2026-111497 als Schwachstelle mit hoher Schwere.

Der CVSS-v4-Wert liegt allerdings bei 9,2, was formal im kritischen Bereich liegt.

Das klingt zunächst widersprüchlich.

Der praktische Grund dürfte in den Voraussetzungen liegen.

Ein Angreifer muss einen Anwendungspfad erreichen, der manipulierte Brotli-Daten tatsächlich dekomprimiert.

Node2Shell ist damit nicht zwangsläufig auf jedem Node.js-System direkt über das Internet ausnutzbar.

Wenn dieser Pfad aber vorhanden ist, kann das Ergebnis erheblich sein.

Was passiert technisch im Brotli-Decoder?

Vereinfacht gesagt meldet ein präparierter Brotli-Datenstrom eine Kombination von Zuständen, die eigentlich nicht auftreten dürfte.

Der verwundbare Decoder behandelt diesen Zustand jedoch nicht sofort als ungültiges Format.

Stattdessen verhält er sich so, als würde lediglich weiteres Eingabematerial fehlen.

Die Verarbeitung läuft weiter.

Dadurch kann der Decoder irgendwann über den vorgesehenen internen Puffer hinausschreiben.

Genau diese Speicherbeschädigung bildet die Grundlage für die weiterführende Ausnutzung.

Der Patch stoppt früher

Node.js hat einen Fix aus dem ursprünglichen Brotli-Projekt übernommen.

Nach der Korrektur erkennt der Decoder die ungültige Datenstruktur rechtzeitig.

Statt in einem fehlerhaften Zustand weiterzuarbeiten, wird der Datenstrom abgewiesen.

Das ist letztlich die entscheidende Änderung:

Ungültige Brotli-Daten führen zu einem Fehler – nicht mehr zu einer fortgesetzten Verarbeitung mit beschädigtem Speicherzustand.

Patch funktioniert gegen die demonstrierten Angriffe

Imperva testete denselben manipulierten Datenstrom auch gegen die korrigierte Node.js-Version:

24.22.1

Dort wurde der Inhalt zurückgewiesen.

Die Codeausführung funktionierte nicht mehr.

Auch ELLIO bestätigt bei seinen Untersuchungen, dass die korrigierten Builds den Angriff abweisen.

Damit gibt es keinen guten Grund, mit dem Update zu warten.

Exploits sind versionsabhängig

Eine interessante technische Einschränkung betrifft die Zuverlässigkeit der bisherigen Exploits.

Die Angriffe funktionieren nicht automatisch unverändert gegen jede Node.js-Version.

Bestimmte Speicheradressen und Offsets unterscheiden sich zwischen Builds.

Ein für:

Node.js 24.22.0

vorbereiteter Exploit funktionierte beispielsweise nicht einfach unverändert gegen andere getestete Node.js-Versionen.

Das erschwert eine universelle Ein-Klick-Ausnutzung.

Es ist aber kein Grund zur Entwarnung.

Angreifer können Builds einmal analysieren

Denn Serverlandschaften verwenden häufig sehr viele identische Versionen.

Hat ein Angreifer einen bestimmten Node.js-Build einmal erfolgreich analysiert, kann er die gewonnenen Informationen potenziell gegen weitere Systeme mit genau demselben Build verwenden.

Gerade Container machen dieses Szenario interessant.

Wenn tausende Systeme dasselbe unveränderte Image verwenden, ist diese Einheitlichkeit für Administratoren praktisch.

Leider manchmal auch für Angreifer.

Erste Scanner sind bereits unterwegs

Inzwischen geht die Entwicklung über reine Forschung hinaus.

ELLIO beobachtete zunächst einen Scanner, der offenbar nach öffentlich erreichbaren Systemen suchte, die Brotli-komprimierte Requests verarbeiten.

Dieser Scanner bezeichnete sich selbst als:

node2shell-check

Dabei wurden Systeme zunächst darauf getestet, ob sie Brotli-Daten überhaupt dekomprimieren.

Das ist ein typisches Vorgehen:

Erst verwundbare beziehungsweise interessante Ziele finden.

Danach gezielter angreifen.

Erster echter Exploit-Traffic beobachtet

Am 26. Oktober 2026 um 15:08 UTC registrierten die Sensoren von ELLIO anschließend einen deutlich interessanteren Request.

Der präparierte Request war gezielt für:

Node.js 24.22.0 auf x86-64

gebaut.

Dabei handelte es sich laut Analyse nicht mehr lediglich um einen Scanner.

Der Datenstrom enthielt tatsächlich Strukturen für einen Node2Shell-Angriff.

Teile basierten auf bereits veröffentlichten Proof-of-Concepts.

Andere Bestandteile waren dagegen vom Angreifer selbst verändert worden.

Der beobachtete Exploit funktionierte noch nicht

Das ist für die Einordnung entscheidend.

ELLIO testete den beobachteten Angriffsversuch anschließend selbst gegen eine passende verwundbare Umgebung.

Das Ergebnis:

Keine erfolgreiche Shell in 50 Versuchen.

Der Angriff war also real und speziell für die Sicherheitslücke gebaut.

Die eigentliche finale Exploit-Kette funktionierte aber offenbar noch nicht zuverlässig.

Das ist ein wichtiger Unterschied zu der Aussage:

„Node2Shell wird bereits erfolgreich massenhaft ausgenutzt.“

Dafür gibt es nach den bisher vorliegenden Informationen keinen Beleg.

Trotzdem ist die Entwicklung ernst

Ich würde daraus allerdings keine große Entwarnung ableiten.

Wir haben inzwischen:

• öffentlich bekannte technische Details

• funktionierende RCE-Demonstrationen

• funktionierende Exploit-Ketten im Labor

• ARM64-Nachweise

• x86-64-Nachweise

• öffentliche Scanner

• echten Exploit-Traffic

Die entscheidenden Bausteine liegen also längst auf dem Tisch.

Dass der erste beobachtete fremde Exploit noch nicht funktionierte, bedeutet nicht, dass das lange so bleiben muss.

Noch kein bestätigter erfolgreicher Angriff in freier Wildbahn

Nach dem Stand der vorliegenden Berichte gab es bis zum 27. Oktober 2026 noch keinen bestätigten erfolgreichen Kompromittierungsfall durch Node2Shell in freier Wildbahn.

Das sollte man ausdrücklich von den beobachteten Angriffen unterscheiden.

Exploit-Traffic wurde gesehen.

Eine erfolgreiche Kompromittierung wurde bislang nicht bestätigt.

Gerade bei Sicherheitsmeldungen finde ich diese Unterscheidung wichtig.

„Angreifer probieren es“ und „Angreifer haben erfolgreich Server übernommen“ sind zwei völlig unterschiedliche Aussagen.

Container nicht vergessen

Ein Punkt dürfte in vielen Umgebungen besonders wichtig sein:

Node.js steckt häufig in Docker- oder anderen Container-Images.

Nur das Node.js-Paket auf dem Hostsystem zu kontrollieren reicht dann nicht.

Admins sollten auch prüfen:

• verwendete Base Images

• bereits gebaute Container

• CI/CD-Pipelines

• Serverless-Artefakte

• eigene Runtime-Bundles

Ist dort ein verwundbares Node.js-Binary enthalten, muss das Image aktualisiert und anschließend neu ausgerollt werden.

Ein gepatchter Host macht einen alten Container nicht automatisch sicher.

Versionsprüfung allein kann ebenfalls täuschen

Auch bei der Brotli-Version ist Vorsicht angebracht.

Node.js hat den Fix in seine Sicherheitsupdates übernommen, ohne zwangsläufig die intern angezeigte Brotli-Versionsnummer entsprechend zu verändern.

Deshalb sollte man sich nicht nur auf eine Abfrage der eingebauten Brotli-Version verlassen.

Wichtiger ist, die tatsächlich installierte Node.js-Version mit den korrigierten Releases abzugleichen.

Systembibliotheken sind ein weiterer Sonderfall

Je nach Linux-Distribution kann Node.js außerdem gegen eine vom Betriebssystem bereitgestellte Brotli-Bibliothek gelinkt sein.

Dann kann nicht allein die Node.js-Versionsnummer entscheidend sein.

In solchen Umgebungen sollte man zusätzlich die Sicherheitsinformationen des jeweiligen Distributors kontrollieren.

Gerade bei Debian, Red Hat, Alpine und anderen Distributionen werden Sicherheitskorrekturen häufig in bestehende Paketversionen zurückportiert.

Was Administratoren jetzt tun sollten

Aus meiner Sicht ist die Priorität ziemlich eindeutig.

1. Node.js-Version prüfen

Betroffene produktive Systeme identifizieren.

Besonders interessant sind Server mit:

• Node.js 22.x

• Node.js 24.x

• Node.js 26.x

2. Auf gepatchte Releases aktualisieren

Mindestens:

• 22.23.4

• 24.22.1

• 26.12.1

verwenden.

3. Container neu bauen

Ein neues Node.js-Paket auf dem Host reicht nicht, wenn die Anwendung in einem alten Container läuft.

4. Prüfen, ob untrusted Brotli verarbeitet wird

Besonders beachten:

• Express-Body-Parser

• Koa-Middleware

• eigene node

• externe Abrufe über fetch()

• Proxy- und API-Komponenten

5. Netzwerkrechte begrenzen

Node.js-Dienste sollten ohnehin nur die Rechte und Netzwerkzugriffe besitzen, die sie tatsächlich benötigen.

Falls eine Anwendung kompromittiert wird, begrenzt das zumindest den möglichen Schaden.

Alte Node.js-Versionen gehören ebenfalls auf den Prüfstand

Besonders unschön ist die Situation bei nicht mehr unterstützten Node.js-Zweigen.

Diese erhalten keine entsprechenden offiziellen Sicherheitsupdates mehr.

Wer noch auf:

• Node.js 20

• Node.js 23

• Node.js 25

• oder noch älteren Versionen

sitzt, sollte nicht darauf warten, dass dafür plötzlich ein Sicherheitsrelease erscheint.

Hier führt der vernünftige Weg auf einen aktuell unterstützten Zweig.

Node2Shell betrifft letztlich nicht nur Node.js

Der eigentliche Fehler steckt im Brotli-Decoder.

Damit ist das Problem grundsätzlich größer als nur das Node.js-Ökosystem.

Auch andere Anwendungen und Programmiersprachen können verwundbare Brotli-Versionen enthalten oder verwenden.

Für diesen Artikel ist Node.js der wichtigste Fall, weil dort inzwischen eine vollständige Remote Code Execution auf offiziellen Builds demonstriert wurde.

Administratoren sollten aber durchaus im Hinterkopf behalten:

Brotli steckt an ziemlich vielen Stellen.

Mein Eindruck

Node2Shell erinnert mich ein wenig an die Entwicklung bei PHP2Shell.

Nicht technisch – die Ursachen sind völlig unterschiedlich.

Aber beim zeitlichen Ablauf.

Zuerst gibt es die Sicherheitsmeldung.

Dann erscheinen Proofs of Concept.

Dann zeigen Forscher, dass aus einem zunächst eher kompliziert wirkenden Speicherfehler tatsächlich Codeausführung auf normalen Systemen möglich ist.

Kurz darauf beginnen Scanner.

Und irgendwann tauchen die ersten echten Exploit-Versuche auf.

Genau deshalb sollte man mit dem Patchen nicht warten, bis der erste erfolgreiche Angriff öffentlich dokumentiert wird.

Dann ist man ohnehin schon spät dran.

Keine Panik, aber auch kein Grund zum Aussitzen

Node2Shell ist trotzdem kein Fall, bei dem automatisch jeder öffentlich erreichbare Node.js-Server sofort übernommen werden kann.

Die Anwendung muss einen passenden Weg besitzen, über den untrusted Brotli-Daten dekomprimiert werden.

Die bisherigen Exploits sind außerdem stark vom jeweiligen Build abhängig.

Das reduziert die einfache Massenausnutzung.

Aber:

Eine funktionierende RCE auf offiziellen ARM64- und x86-64-Builds wurde inzwischen demonstriert.

Damit ist die Frage, ob aus dem Fehler Codeausführung werden kann, beantwortet.

Die Antwort lautet eindeutig:

Ja.

Fazit

Die unter CVE-2026-111497 geführte Node2Shell-Schwachstelle ist inzwischen deutlich ernster einzuschätzen als noch unmittelbar nach ihrer Veröffentlichung.

Der Fehler im Brotli-Decoder kann manipulierte komprimierte Daten außerhalb eines vorgesehenen Speicherbereichs schreiben lassen.

Forscher haben daraus inzwischen eine funktionierende Remote Code Execution auf offiziellen Node.js-Builds entwickelt.

Nachgewiesen wurde dies unter anderem auf:

• Linux ARM64

• Linux x86-64

• Node.js 24.22.0

• Express

• Koa

• offiziellen Node.js-Container-Images

Zusätzlich wurden inzwischen erste Scanner und speziell präparierter Node2Shell-Exploit-Traffic im Internet beobachtet.

Der bislang analysierte fremde Exploit führte in Tests allerdings noch nicht erfolgreich zu einer Shell.

Eine bestätigte erfolgreiche Kompromittierung in freier Wildbahn war zum Stand der vorliegenden Berichte ebenfalls noch nicht bekannt.

Trotzdem würde ich hier nicht lange überlegen.

Wer betroffene Node.js-Dienste betreibt, sollte mindestens auf:

• Node.js 22.23.4

• Node.js 24.22.1

• Node.js 26.12.1

aktualisieren und auch Container beziehungsweise andere gebündelte Runtimes neu bauen und ausrollen.

Denn bei Node2Shell sind wir inzwischen an dem Punkt angekommen, an dem die Frage nicht mehr lautet:

„Kann man die Lücke wirklich für RCE ausnutzen?“

Sondern eher:

„Wie lange dauert es, bis jemand daraus einen zuverlässig funktionierenden Massenangriff baut?“

Quellen

The Hacker News – Researchers Demonstrate Node2Shell RCE Exploit on Node.js Build Using Crafted Brotli Data
https://thehackernews.com/2026/10/researchers-demonstrate-node2shell-rce.html

Node.js – October 2026 Security Releases
https://nodejs.org/en/blog/vulnerability/october-2026-security-releases

Node.js – Node.js 22.23.4
https://nodejs.org/en/blog/release/v22.23.4/

Node.js – Node.js 24.22.1
https://nodejs.org/en/blog/release/v24.22.1/

Node.js – Node.js 26.12.1
https://nodejs.org/en/blog/release/v26.12.1/

Imperva – Node2Shell: From Brotli Data to Remote Code Execution
https://www.imperva.com/blog/

ELLIO – Node2Shell: Remote Code Execution on Stock Node.js Builds
https://ellio.tech/en/blog/node2shell-cve-2026-111497-rce-on-stock-nodejs-builds/

Akamai – Inside Node2Shell: A Closer Look at CVE-2026-111497
https://www.akamai.com/blog/security-research/inside-node2shell-closer-look-cve-2026-111497