Node2Shell (CVE-2026-111497): Node.js jetzt patchen

Der 21. Oktober 2026 war für IT-Teams ein Doppelschlag. Während alle noch mit PHP2Shell beschäftigt waren, hat am selben Tag auch das Node.js-Projekt ein Sicherheitsupdate veröffentlicht: zehn Lücken, vier davon als «High» eingestuft. Die gefährlichste, CVE-2026-111497, steckt im Brotli-Decoder und kann bis zur Ausführung von fremdem Code führen. Das Red Team von Imperva hat ihr den Namen Node2Shell gegeben.

Node.js steckt hinter unzähligen Webshops, Kundenportalen, APIs, internen Tools, Build-Servern und Desktop-Apps. Oft weiss niemand mehr genau, wo überall eine Node-Version mitläuft. Genau das macht dieses Update tückisch.

Dieser Artikel erklärt, was die vier wichtigsten Lücken bedeuten, wie Sie herausfinden, ob Sie betroffen sind, und wie Sie Schritt für Schritt patchen.

Was ist Node2Shell?

Brotli ist ein Kompressionsverfahren, das Browser und Server nutzen, um Daten kleiner zu übertragen. Node.js bringt einen eigenen Brotli-Decoder mit. Bei einem bestimmten fehlerhaften Datenstrom hält dieser Decoder den Fehler fälschlicherweise für «es fehlen noch Daten» und schreibt weiter in einen internen Puffer von nur acht Bytes. Was danach im Speicher landet, bestimmt im schlimmsten Fall der Angreifer.

Die Folgen reichen vom Absturz über das Auslesen von Speicher bis zur Codeausführung mit den Rechten des Node.js-Prozesses. Google bewertet die Lücke als zuständige CNA mit CVSS 9.2 (kritisch), das Node.js-Projekt selbst mit «High».

Betroffen ist jede Anwendung, die Brotli-Daten aus einer fremden Quelle entpackt. Das passiert öfter, als man denkt:

• Das eingebaute fetch() fragt HTTPS-Server standardmässig nach Brotli-komprimierten Antworten. Ruft Ihre Anwendung fremde oder manipulierbare Server ab, kann eine präparierte Antwort genügen.
• Express und body-parser: Laut Imperva sind Express 5.0 bis 5.3 bzw. body-parser 2.0 bis 2.3 mit den Parsern json() und raw() ein Angriffsweg, weil sie komprimierte Anfragen entpacken.
• Eigener Code mit zlib.createBrotliDecompress() oder zlib.brotliDecompress().

Ein nackter Node.js-HTTP-Server entpackt eingehende Anfragen dagegen nicht von selbst.

Die drei anderen Lücken mit «High»

Node2Shell ist die lauteste, aber nicht die einzige Lücke. Drei weitere betreffen das Vertrauen in Verbindungen, also die Frage: Rede ich wirklich mit dem Server, mit dem ich reden will?

Bei den beiden TLS-Lücken drohen Identitätstäuschung und abgefangene Daten, bei der DNS-Lücke landet der Verkehr womöglich bei einem ganz anderen Server. Relevant ist das vor allem für Anwendungen, die Verbindungen zu Adressen aufbauen, die von aussen kommen, etwa Webhooks, Link-Vorschauen oder Integrationen mit frei konfigurierbarer Ziel-URL.

Dazu kommen sechs Lücken mit «Medium» oder «Low», unter anderem beim Keep-alive-HTTP-Agent, bei randomUUID() in Startup-Snapshots und beim Permission Model. Gleichzeitig wurden mitgelieferte Bibliotheken aktualisiert: c-ares, die CA-Zertifikate (kompromittierte eMudhra-Zwischenzertifizierungsstelle), OpenSSL, SQLite und Undici. Ein Grund mehr, nicht nur einzelne Lücken abzuwägen, sondern das ganze Update einzuspielen.

Zeitlicher Ablauf

Der Abstand zwischen «Proof of Concept» und «echte Angriffe» war bei PHP2Shell nur wenige Stunden. Darauf zu hoffen, dass es diesmal länger dauert, ist kein Plan.

Bin ich betroffen?

Anleitung: So patchen Sie Node.js

Sicher sind 22.23.4, 24.22.1 und 26.12.1 oder neuer. Wer noch auf Node.js 20, 23 oder 25 läuft, bekommt keinen Fix und sollte auf 24 (aktuelle LTS) wechseln.

1. Version prüfen

Auf jedem Server, in jedem Container und auf jedem Build-Server:

node -v
# in einem laufenden Container
docker exec <container> node -v

2. Node.js aktualisieren

Je nachdem, wie Node.js installiert ist:

# nvm
nvm install 24.22.1 && nvm alias default 24.22.1

# fnm
fnm install 24.22.1 && fnm default 24.22.1

# Volta
volta install node@24.22.1

# macOS mit Homebrew
brew update && brew upgrade node

# Debian/Ubuntu mit NodeSource-Paketquelle
sudo apt update && sudo apt install --only-upgrade nodejs

Danach node -v erneut prüfen und die Anwendung neu starten. Ein laufender Prozess nutzt sonst weiter die alte Version. Prüfen Sie bei Paketen aus der Linux-Distribution, ob der Fix schon angekommen ist: Einige Distributionen hatten wenige Tage nach der Veröffentlichung noch keine korrigierten Pakete.

3. Docker-Images neu bauen

Ein Image ist eingefroren: Es enthält die Node-Version vom Tag, an dem es gebaut wurde. Darum im Dockerfile eine korrigierte Version festlegen und ohne Cache neu bauen:

FROM node:24.22.1-alpine

docker build --pull --no-cache -t meine-app .

Danach neu ausrollen und mit docker exec die Version im laufenden Container kontrollieren. Basis-Images von Drittanbietern ebenfalls prüfen.

4. Build-Server und CI

In GitHub Actions holt actions/setup-node nicht automatisch die neueste Version, wenn eine ältere im Cache liegt. Entweder eine feste Version eintragen oder check-latest setzen:

- uses: actions/setup-node@v6
  with:
    node-version: '24'
    check-latest: true

Bei verwalteten Serverless-Laufzeiten (z. B. AWS Lambda) spielt der Anbieter Updates in der Regel selbst ein. Die tatsächliche Version steht im Log oder in der Dokumentation des Anbieters. Eigene Container-Images für Serverless müssen Sie selbst neu bauen.

5. Abhängigkeiten prüfen

npm ls express body-parser
npm install body-parser@latest

body-parser 2.4.0 bzw. 1.20.9 schliesst zusätzlich eine eigene Denial-of-Service-Lücke auf demselben Weg (CVE-2026-111181). Das ersetzt das Node.js-Update aber nicht.

6. Nicht vergessen

Electron-Apps, CLI-Tools und Desktop-Anwendungen bringen oft eine eigene Node-Laufzeit mit. Hier hilft nur das Update des jeweiligen Herstellers.

Übergangsmassnahmen, bis der Patch drin ist

Node.js nennt keine offiziellen Workarounds. Diese Massnahmen verkleinern die Angriffsfläche, ersetzen das Update aber nicht:

1. Braucht ein Dienst keine komprimierten Anfragen, bei body-parser inflate: false setzen. Das schützt nur eingehende Anfragen, nicht Antworten, die Ihre Anwendung per fetch() abruft.
2. Komprimierte Anfragen aus nicht vertrauenswürdigen Quellen am Proxy oder in der Web Application Firewall begrenzen. Vercel weist darauf hin, dass WAF-Regeln abgerufene Antworten nicht abdecken.
3. Hostnamen und Ziel-URLs, die von aussen kommen, streng prüfen: keine NUL-Zeichen, keine Fullwidth-Ziffern, keine IP-Adressen mit führender Null, Hex- oder Kurzschreibweise.
4. Interne Dienste über Hostnamen statt über IP-Adressen ansprechen, wenn TLS im Spiel ist.

Diese Nachricht können Sie Ihrer Agentur schicken

Wenn ein Dienstleister Ihre Anwendung betreibt, kopieren Sie diesen Text in eine E-Mail:

Betreff: Node.js-Sicherheitsupdate vom 21. Oktober 2026

Hallo

Läuft in unseren Anwendungen, Docker-Images oder Build-Prozessen Node.js? Falls ja: Ist das Sicherheitsupdate vom 21. Oktober 2026 (u. a. CVE-2026-111497, «Node2Shell») bereits eingespielt? Nötig ist mindestens Node.js 22.23.4, 24.22.1 oder 26.12.1. Node.js 20, 23 und 25 erhalten keinen Fix mehr.

Vielen Dank für eine kurze Bestätigung.

Ist Saldio betroffen?

Nein. Die Website saldio.ch besteht aus fertigen, statischen Dateien, die über ein CDN ausgeliefert werden. Es gibt keinen Node.js-Server, der Anfragen entgegennimmt. Node.js läuft bei uns nur beim Erstellen der Website auf dem Build-Server, verarbeitet dort keine fremden Daten und holt bei jedem Build die neueste Version. Die Saldio-App selbst läuft nicht auf Node.js.

Sie müssen nichts tun. Ihre Buchhaltung läuft weiter wie gewohnt. Unabhängig von Node2Shell gilt bei Saldio:

• Hosting in der Schweiz, Ihre Daten bleiben im Land.
• Anmeldung mit MFA und Passkey über AWS Cognito, die Tokens liegen serverseitig.
• Jede Änderung im Audit-Log, Aufbewahrung gemäss GeBüV.

Welche Funktionen rund um Sicherheit und Plattform dazugehören, zeigt die Übersicht der Funktionen.

Fazit

Node2Shell ist ernst, aber gut lösbar: Inventar machen, Node.js auf 22.23.4, 24.22.1 oder 26.12.1 bringen, Images neu bauen, fertig. Das Schwierigste ist meist nicht das Update selbst, sondern alle Stellen zu finden, an denen Node.js mitläuft. Teilen Sie diesen Artikel mit allen, die Anwendungen betreuen. Vielleicht ist genau ein vergessenes Docker-Image der Unterschied.

Und wenn Sie bei der Gelegenheit auch Ihre Buchhaltung auf eine Lösung ohne Patch-Stress umstellen wollen: Saldio 7 Tage gratis testen, ohne Zahlungsmittel, danach ab CHF 15 pro Monat gemäss Preisen. Bis 31.01.2027 gibt es mit dem Jahresend-Spezial einmalig 50 % auf das erste Jahr.

Passen Sie auf sich auf.

Häufige Fragen

Was ist Node2Shell?

Node2Shell ist der Name, den das Red Team von Imperva der Lücke CVE-2026-111497 gegeben hat. Ein Fehler im Brotli-Decoder von Node.js erlaubt einen Schreibzugriff ausserhalb eines Puffers und kann bis zur Codeausführung führen. Google bewertet sie mit CVSS 9.2.

Welche Node.js-Versionen schliessen die Lücken?

Node.js 22.23.4, 24.22.1 und 26.12.1 sowie neuere Versionen. Node.js 20, 23 und 25 sind ausser Wartung und erhalten keinen Fix, ein Wechsel auf 24 (LTS) ist nötig.

Reicht ein npm update?

Nein. Die Lücken stecken in der Node.js-Laufzeit selbst. Sie müssen Node.js auf Servern, in Docker-Images und auf Build-Servern aktualisieren und die Anwendungen neu starten oder neu ausrollen.

Wird Node2Shell bereits ausgenutzt?

Bis zum 23. Oktober 2026 meldeten weder Node.js noch nationale CERTs Angriffe. Proof-of-Concept-Code ist aber öffentlich, deshalb sollten Sie nicht warten.

Ist Saldio betroffen?

Nein. Die Website saldio.ch besteht aus statischen Dateien ohne Node.js-Server, und die Saldio-App läuft nicht auf Node.js. Saldio-Kunden müssen nichts tun.