Auf einen Blick:

Produkt / Komponente	Betroffene Versionen	Gepatcht in
Node.js 26.x	vor 26.12.1	26.12.1
Node.js 24.x (LTS)	vor 24.22.1	24.22.1
Node.js 22.x (LTS)	vor 22.23.4	22.23.4
Node.js 25.x, 23.x, 20.x und älter	End-of-Life, betroffen	kein Update vom Node.js-Projekt (Distributionspakete siehe unten)
Google Brotli (Bibliothek)	1.0.3 bis 1.2.0	1.0.10, 1.1.1, 1.2.1
Bun	vor 1.4.4	1.4.4

• Schwachstelle: CVE-2026-111497 (Node.js: hoch; CVE-Eintrag: CVSS 9.2, kritisch)
• Proof of Concept: öffentlich, Codeausführung bisher nur im Labor nachgewiesen; aktive Ausnutzung bis 22.10. nicht gemeldet
• Patch verfügbar seit: 21.10.2026
• Offizieller Workaround: keiner

Zeitleiste: Was bisher passiert ist

• 21. Oktober 2026: Node.js veröffentlicht Sicherheitsupdates für alle unterstützten Versionslinien mit insgesamt zehn Sicherheitskorrekturen. Am selben Tag erscheinen die Brotli-Versionen 1.2.1, 1.1.1 und 1.0.10, und Vercel schaltet Firewall-Regeln für eingehende Anfragen. Gemeldet hat die Lücke laut Node.js-Advisory OpenAI Codex Security. Am selben Tag schließt auch das PHP-Projekt die kritischen Lücken rund um PHP2Shell; auch an deren Entdeckung war OpenAI Codex Security beteiligt.
• 22. Oktober 2026: Der CVE-Eintrag wird veröffentlicht (CVSS 9.2). Imperva zeigt Codeausführung gegen das offizielle Node.js-24.22.0-Image. Ein separater Proof of Concept wird öffentlich, erreicht Codeausführung aber nur auf einem absichtlich geschwächten Testbuild. Bun schließt die Lücke mit Version 1.4.4.

Welche Software ist von Node2Shell betroffen?

Die Schwachstelle sitzt in Node.js selbst, genauer in der Brotli-Bibliothek, die Node.js mitbringt. Ein Update einzelner npm-Pakete schließt sie deshalb nicht. Es kommt auf die Node.js-Laufzeitumgebung an und, bei Node.js aus Distributionspaketen, auf deren Brotli-Paket.

Gefährdet ist eine Anwendung, wenn sie Brotli-komprimierte Daten aus einer nicht vertrauenswürdigen Quelle entpackt. Die wichtigsten Wege dorthin:

• Eingehende Anfragen mit Express 5 oder body-parser 2.x: Diese Versionen entpacken Request-Bodies mit Content-Encoding: br automatisch. Imperva hat die Codeausführung mit Express 5.0.0 und 5.3.0 sowie body-parser 2.0.0 bis 2.3.0 nachvollzogen; nicht jede Zwischenversion wurde einzeln getestet.
• Ausgehende Abrufe mit fetch(): Die in Node.js eingebaute Funktion entpackt Brotli-Antworten automatisch. Ein Server, der von Angreifenden kontrolliert wird oder kompromittiert ist, kann die Anwendung so erreichen. Typische Fälle sind Webhooks, Link-Vorschauen und Funktionen, bei denen Nutzer eine URL angeben.
• Direkte Nutzung von node:zlib: Anwendungen und Bibliotheken, die Brotli-Daten aus unsicherer Quelle mit brotliDecompress oder createBrotliDecompress entpacken.

Ein einfacher HTTP-Server mit dem Node.js-Modul http entpackt eingehende Brotli-Bodies nicht von selbst. Betroffen ist er trotzdem, sobald die Anwendung einen der genannten Wege nutzt.

Betroffen sein kann auch andere Software, die den Brotli-Decoder in den Versionen 1.0.3 bis 1.2.0 einbettet und damit Daten aus unsicherer Quelle entpackt. Die JavaScript-Laufzeit Bun war bis Version 1.4.3 betroffen.

Node2Shell-Exploit: Was Angreifende erreichen können

• Code ausführen: Laut CVE-Eintrag können Angreifende ohne Anmeldung über einen präparierten Brotli-Datenstrom Speicher des Decoders beschädigen und möglicherweise beliebigen Code ausführen. Der Code läuft dann im Kontext des Node.js-Prozesses.
• Speicher auslesen: Auch die Offenlegung von Speicherinhalten des Prozesses ist laut CVE-Eintrag möglich.
• Dienst lahmlegen: Mindestens möglich ist ein Absturz des Prozesses durch eine präparierte Eingabe.

Imperva hat Codeausführung gegen das offizielle Linux-arm64-Image von Node.js 24.22.0 nachgewiesen, ohne Debugger und ohne verändertes Programm, sowohl über fetch() als auch über Request-Bodies in Express. Der Angriff gelang nicht bei jedem Versuch. Node.js 24.22.1 wies dieselben Eingaben ab. Ein separater, öffentlicher Proof of Concept erreichte Codeausführung laut The Hacker News nur auf einem absichtlich geschwächten Testbuild; auf einem normalen Build führte er zu einem Absturz und dem begrenzten Auslesen von Prozessspeicher.

Eine aktive Ausnutzung war bis zum 22. Oktober 2026 nicht gemeldet. Der CVSS-Vektor weist zudem Angriffsvoraussetzungen aus. Praktisch heißt das: Die Anwendung muss Brotli-Daten aus unsicherer Quelle entpacken.

Betroffene Node.js-Systeme im Inventar finden

Wer schnell patchen will, muss zuerst wissen, wo Node.js überhaupt läuft. Die Laufzeit steckt oft an Stellen, die in keinem Server-Inventar auftauchen: in Docker-Images, CI-Runnern, Serverless-Funktionen, internen Tools, Build-Servern und Appliances mit eingebetteter Laufzeit.

Wie prüfe ich die Node.js-Version?

• Auf dem Server: node –version zeigt die installierte Version. Läuft eine Anwendung mit einem eigenen Binary (etwa über nvm oder in einem Unterverzeichnis), muss diese Version geprüft werden.
• In Docker: docker run –rm <image> node –version. Ein auf eine alte Version festgelegtes Image wie node:24.22.0 bleibt verwundbar, auch wenn es neu gebaut wird. Der Tag muss auf eine gepatchte Version zeigen.
• Im Code: npm ls express body-parser zeigt, ob Express 5 oder body-parser 2.x im Einsatz sind. Eine Suche nach brotliDecompress und createBrotliDecompress im eigenen Code und in Abhängigkeiten zeigt direkte Brotli-Nutzung.
• Von außen: Express-Anwendungen verraten sich oft über den HTTP-Header X-Powered-By: Express. Fehlt der Header, heißt das nicht, dass kein Node.js läuft.

Node.js aus Linux-Paketen

Die offiziellen Node.js-Binaries und die offiziellen Docker-Images bringen ihre eigene Brotli-Kopie mit; dort schließt das Node.js-Update die Lücke. Distributionen wie Debian bauen Node.js dagegen gegen die Brotli-Bibliothek des Systems. Dort kommt die Korrektur über das Brotli-Paket der Distribution, auch für ältere Node.js-Linien wie 18.x und 20.x, die Debian noch ausliefert. Der Debian Security Tracker führt brotli (bookworm, trixie, forky, sid) und die abhängigen nodejs-Pakete am 23. Oktober 2026 noch als verwundbar, ein Fix ist dort noch nicht eingetragen. Für andere Distributionen gilt deren jeweiliges Advisory.

Node.js-Sicherheitslücke schließen: Was jetzt zu tun ist

• Auf Node.js 22.23.4, 24.22.1 oder 26.12.1 oder neuer aktualisieren, auch auf CI-Runnern und Build-Servern.
• Docker-Images auf einen gepatchten Tag umstellen und neu bauen; Anwendungen mit eingebettetem Node.js-Binary neu ausliefern.
• Bei Node.js aus Distributionspaketen das Brotli-Paket der Distribution aktualisieren, sobald es verfügbar ist.
• Bun auf Version 1.4.4 oder neuer aktualisieren.
• Node.js 25.x, 23.x, 20.x und älter aus den offiziellen Quellen: Diese Linien haben ihr End-of-Life erreicht und erhalten vom Node.js-Projekt kein Update mehr. Betroffene Anwendungen auf eine unterstützte Version migrieren.
• Nach dem Update alle Node.js-Prozesse neu starten, etwa über den Prozessmanager oder durch Neustart der Container.
• Bei gehosteten Plattformen und Dienstleistern nachfragen, ob die Laufzeitumgebung bereits aktualisiert ist.

Übergangsmaßnahmen, wenn das Update noch nicht möglich ist

Das Node.js-Advisory nennt keinen Workaround. Einzelne Angriffswege lassen sich aber bis zum Update einschränken:

• Anfragen mit Content-Encoding: br am Reverse Proxy, Load Balancer oder in der Middleware ablehnen, wenn die Anwendung keine Brotli-komprimierten Request-Bodies braucht. Das schützt nur eingehende Anfragen.
• Funktionen, die per fetch() Daten von fremden oder vom Nutzer angegebenen Servern abrufen, vorübergehend abschalten oder Antworten mit Content-Encoding: br von solchen Servern verwerfen.
• Web Application Firewalls: Einzelne Anbieter haben Regeln veröffentlicht, etwa Vercel für eingehende Anfragen auf seiner Plattform. Brotli-Antworten, die eine Anwendung selbst von anderen Servern abruft, decken solche Regeln nicht ab.

Keine dieser Maßnahmen ersetzt das Update der Laufzeitumgebung.

Woran erkenne ich einen Angriff?

Verlässliche Angriffsindikatoren gibt es bislang nicht. Die Forschenden nennen als Hinweise für eine Priorisierung:

• unerwartete Abstürze von Node.js-Prozessen beim Entpacken von Daten,
• Fehlermeldungen des Brotli-Decoders in den Protokollen.

Beides ist nach ihrer Einschätzung kein sicherer Beleg für eine Ausnutzung. Wer Anzeichen einer Kompromittierung findet, sollte davon ausgehen, dass Zugangsdaten, Tokens und Schlüssel aus dem betroffenen Prozess betroffen sein können, und sie austauschen.

Weitere Schwachstellen im selben Node.js-Update

Das Sicherheitsrelease vom 21. Oktober schließt neben Node2Shell neun weitere Lücken, drei davon ebenfalls mit „High“ bewertet:

• CVE-2026-105482: dns.resolve kürzt Hostnamen, die ein NUL-Zeichen enthalten.
• CVE-2026-105483: Umgehung der TLS-Hostnamenprüfung bei IP-Adressen in vollbreiten Ziffern.
• CVE-2026-106069: Umgehung der TLS-Hostnamenprüfung, wenn der Hostname großzügig zu einer IP-Adresse aufgelöst wird.

Dazu kommen drei Lücken mit „Medium“, darunter wiederholte Zufallswerte von crypto.randomUUID() in Startup-Snapshots und Single Executable Applications, und drei mit „Low“, darunter zwei Umgehungen des Permission Models. Außerdem aktualisiert das Release unter anderem OpenSSL, c-ares und undici.

DACH- und EU-Kontext

Das zeitnahe Einspielen von Sicherheitsupdates gehört für Einrichtungen im Anwendungsbereich von NIS-2 zu den Risikomanagementmaßnahmen nach Art. 21 NIS-2-Richtlinie. Kommt es durch eine Ausnutzung von Node2Shell zu einem erheblichen Sicherheitsvorfall, greifen die Meldepflichten nach Art. 23 NIS-2-Richtlinie, in Deutschland nach § 32 BSIG. In Österreich und der Schweiz gelten die jeweiligen nationalen Meldepflichten.

Wie LocateRisk bei exponierten Assets ansetzt

LocateRisk macht extern erreichbare Systeme und die von außen erkennbare Software sichtbar. Bei Node2Shell hilft das, öffentlich erreichbare Webanwendungen und von außen erkennbare Node.js-Installationen zu finden, auch solche, die in keiner internen Liste stehen, und die Update-Reihenfolge zu priorisieren. Einen schnellen Überblick liefert die automatisierte IT-Risikoanalyse. Mit Preemptive Intelligence meldet LocateRisk kritische Softwareversionen, sobald eine Schwachstelle bekannt wird, noch bevor die NVD sie offiziell einordnet.

LocateRisk ersetzt kein Patch-Management und trifft keine Aussage darüber, ob auf einem erkannten System eine verwundbare Node.js-Version läuft oder die Anwendung Brotli-Daten entpackt. Interne Dienste und Anwendungen, die per fetch() Daten von fremden Servern abrufen, deckt der Blick von außen nicht ab. Dafür sind das interne Inventar und der Abgleich mit dem Node.js-Advisory bzw. dem Paketstand der Distribution nötig.

Für ausgelagerte Webanwendungen oder Kundenportale kann Vendor Risk Management ergänzend helfen, Rückmeldungen der Dienstleister zum Patch-Stand nachvollziehbar zu dokumentieren.

Bin ich betroffen?

Betroffen sind alle Node.js-Versionen vor den in der Tabelle oben genannten Releases sowie die End-of-Life-Linien 25.x, 23.x, 20.x und älter. Wer wissen will, ob Node.js in der eigenen extern erreichbaren Infrastruktur überhaupt sichtbar ist, kann den CVE-Quick-Check am Ende dieses Artikels nutzen: Er zeigt exponierte Systeme und die von außen erkennbare Software.

Die konkret installierte Version lässt sich von außen nicht in jedem Fall bestimmen — ausschlaggebend ist der Abgleich mit dem Hersteller-Advisory.

Quellen und weitere Infos

• Node.js: Wednesday, October 21, 2026 Security Releases
• CVE.org: CVE-2026-111497: Out-of-Bounds Write in Google Brotli Decoder
• Google Brotli / GitHub: Release v1.2.1
• GitHub Advisory Database: GHSA-9v8h-qqgm-4m35
• Imperva: Node2Shell: From Brotli Data to Remote Code Execution
• The Hacker News: Node.js Brotli Decoder Bug Could Allow Remote Code Execution in All Supported Versions
• Vercel: Node.js security advisory: Brotli decoder RCE (CVE-2026-111497)
• Bun / GitHub: Brotli decoder is missing the CVE-2026-111497 fix (Issue #46352)
• Debian: Security Tracker CVE-2026-111497

Stand: 23.10.2026. Dieser Beitrag dient allgemeinen Informationszwecken und ist keine Rechts-, Sicherheits- oder Handlungsberatung im Einzelfall. Sicherheitslage und Patch-Verfügbarkeit können sich seit der Veröffentlichung geändert haben; maßgeblich ist stets das verlinkte Hersteller-Advisory. Trotz sorgfältiger Recherche übernehmen wir keine Gewähr für Aktualität, Richtigkeit und Vollständigkeit.

---