Sicherheitslücke in Node.js und Brotli (Node2Shell): So prüfen Sie Ihre Website

Stand: 1. November 2026. Das Node.js-Projekt hat am 21. Oktober Sicherheitskorrekturen veröffentlicht, darunter den Patch für die Lücke CVE-2026-111497, genannt Node2Shell. Der Fehler steckt in Brotli, einer Bibliothek zum Entpacken komprimierter Daten, die Node.js eingebaut hat. Am 27. Oktober nahm die US-Behörde CISA diese Lücke in den Katalog der in Angriffen ausgenutzten Schwachstellen auf.

Keine Panik: Die meisten Websites kleiner Firmen laufen auf WordPress oder als einfache HTML-Dateien und haben kein Node.js auf dem Server. Läuft Ihre Website, Ihr Shop oder Ihr Kundenportal jedoch auf Next.js, Nuxt oder Express, prüfen Sie es noch heute. In diesem Ratgeber zeige ich, wie Sie in wenigen Minuten feststellen, ob die Lücke Sie betrifft, welche Versionen die Korrektur enthalten und was Sie dem Hosting oder dem Dienstleister Ihrer Website schreiben sollten.

Was passiert ist

Brotli ist ein Kompressionsverfahren, ein wenig wie das Packen von Dateien in eine ZIP-Datei, von Google entwickelt und im gesamten Internet verwendet. In der Brotli-Bibliothek steckt in den Versionen 1.0.3 bis 1.2.0 ein Fehler: Speziell präparierte komprimierte Daten können beim Entpacken außerhalb des Speicherbereichs schreiben, den das Programm dafür vorgesehen hat. Die Folge kann ein Absturz der Anwendung sein, ein Abfluss von Daten aus dem Serverspeicher und im schlimmsten Fall die Ausführung fremden Codes mit den Rechten Ihrer Anwendung.

Die wichtigsten Daten:

• 21. Oktober 2026: Node.js und Google veröffentlichten Korrekturen (Brotli 1.0.10, 1.1.1 und 1.2.1).
• 23.–26. Oktober 2026: Debian (DSA-6582-1) und Ubuntu (USN-8956-1) veröffentlichten korrigierte Pakete der Bibliothek, und am 25. Oktober gab Microsoft außerplanmäßig Korrekturen für .NET heraus.
• 27. Oktober 2026: CISA nahm die Lücke in den Katalog Known Exploited Vulnerabilities auf, also der in der Praxis ausgenutzten Schwachstellen.

Zum Beginn der Angriffe gehen die Quellen auseinander. Nach Berichten vom 22. Oktober waren noch keine Angriffe bekannt. Firmen, die den Datenverkehr im Netz überwachen, beschreiben Scans und erste Versuche zwischen dem 25. und 27. Oktober, und CISA nannte keine Details. Ein Teil der beobachteten Versuche schlug fehl, aber selbst ein fehlgeschlagener Versuch kann eine Anwendung lahmlegen. Behandeln Sie dieses Update daher als dringend.

Wen die Node.js-Lücke betrifft

Die Lücke betrifft Programme, die Brotli-Daten von Fremden entpacken. In der Praxis heißt das:

• Websites, Shops und Anwendungen auf einem Server mit Node.js: Next.js, Nuxt, Express und andere. Node.js hat Brotli eingebaut, es zählt also die Version von Node.js selbst und nicht die der npm-Pakete;
• Anwendungen, die komprimierte Anfragen annehmen: Zum Beispiel entpackt Express 5 (über body-parser 2.x) standardmäßig den mit Brotli komprimierten Inhalt von Anfragen;
• Anwendungen, die Daten von fremden Servern abrufen: das eingebaute fetch(), Integrationen, das Laden von Bildern von anderen Adressen. Vercel nennt hier zum Beispiel die Bildoptimierung in selbst gehostetem Next.js;
• andere Programme mit der Brotli-Bibliothek: .NET 8, 9 und 10 (Microsoft weist darauf hin, dass das Entpacken von Brotli dort nicht standardmäßig aktiviert ist), Bun, Envoy und die systemweiten libbrotli-Pakete unter Linux.

Wen die Lücke nicht unmittelbar betrifft:

• statische Websites, also fertige HTML-Dateien, zum Beispiel aus dem Website-Baukasten oder aus Next.js, das in Dateien exportiert wurde. Node.js läuft dann nur auf dem Rechner, auf dem die Website gebaut wird, und nicht auf dem Server;
• WordPress und andere PHP-Websites, denn sie laufen nicht auf Node.js. Auf dem Server kann aber die systemweite Brotli-Bibliothek installiert sein, daher ist ein Systemupdate trotzdem nötig. Das ist Aufgabe des Hostings.

Eine Klarstellung, weil das eine häufige Frage ist: Die Brotli-Komprimierung, mit der der Server an Browser gesendete Seiten packt, ist nicht diese Lücke. Der Fehler betrifft das Entpacken von Daten von Fremden. Schalten Sie die Komprimierung nicht ab, denn die Website wird langsamer, und das Problem löst das nicht.

Welche Node.js-Versionen die Korrektur enthalten

Stand 1. November 2026 laut der Mitteilung von Node.js vom 21. Oktober und der Liste der Node.js-Releases:

Linien ohne Support sind verwundbar und erhalten keinen Patch. Node.js schreibt klar, dass Versionen nach dem Ende des Supports immer von den Lücken der folgenden Sicherheits-Releases betroffen sind. Nach dem 21. Oktober erschienen bereits weitere Releases: 24.22.2 (27. Oktober) und 26.13.0 (28. Oktober, ab dieser Version hat die Linie 26.x den LTS-Status). Sie enthalten dieselbe Korrektur, prüfen Sie vor dem Update aber trotzdem die neueste Version auf nodejs.org.

Dasselbe Release behebt noch neun weitere Fehler, unter anderem bei der Prüfung von TLS-Zertifikaten. Ein Update erledigt alle.

So prüfen Sie, ob Ihre Website gefährdet ist

Ohne IT-Fachkraft: 5 Minuten

1. Quellcode der Website. Öffnen Sie die Website im Browser, drücken Sie Strg+U (Quelltext anzeigen), dann Strg+F und geben Sie _next ein. Gibt es Treffer, ist die Website mit Next.js gebaut. Für Nuxt suchen Sie nach _nuxt. Das entscheidet noch nicht, ob auf dem Server Node.js läuft, zeigt aber, dass sich weiteres Nachfragen lohnt.
2. Header. Drücken Sie F12, wechseln Sie zum Tab Netzwerk (Network), laden Sie die Seite neu und klicken Sie auf die erste Zeile. Suchen Sie in den Antwort-Headern nach x-powered-by. Der Wert Next.js oder Express bedeutet Node.js auf dem Server. Fehlt dieser Header, beweist das nichts, denn viele Dienstleister blenden ihn aus.
3. Hosting-Panel. Steht die Website auf Vercel, sehen Sie die Node.js-Version in den Projekteinstellungen. In Hosting-Panels mit Unterstützung für Node.js-Anwendungen ist die Version meist bei der Anwendung angegeben.
4. Fragen Sie den Dienstleister. Das ist der schnellste und sicherste Weg. Eine fertige Nachricht finden Sie weiter unten.

Für Personen, die Deployments verantworten

Prüfen Sie die Version überall, wo Code läuft: auf dem Server, in jedem Container, in der Testumgebung und in der CI.

# Node.js-Version
node -v

# Node.js-Version in einem Docker-Image
docker run --rm <image> node -v

# Debian und Ubuntu: Version der systemweiten Brotli-Bibliothek
dpkg -l | grep -i brotli

Drei Fallen:

• Docker-Images, die vor dem 21.10. gebaut wurden, haben eine alte Version, solange Sie sie nicht aus einem neuen Basis-Image neu bauen.
• Node.js aus Systempaketen kann die systemweite Bibliothek libbrotli nutzen. Vergleichen Sie deren Version mit dem Tracker von Debian oder der Mitteilung Ubuntu USN-8956-1.
• Ein laufender Prozess nutzt die alte Version, bis Sie ihn neu starten.

Was Sie heute tun sollten

1. Klären Sie, ob Sie Node.js auf dem Server haben (vorheriger Abschnitt). Wenn nicht, gehen Sie zu Punkt 6.
2. Legen Sie ein Backup an von Code, Datenbank und Konfiguration. Wie Sie es ordentlich machen, beschreibe ich im Ratgeber über das Website-Backup und die 3-2-1-Regel.
3. Aktualisieren Sie Node.js auf eine Version aus der Tabelle innerhalb derselben Linie. Ein solches Update erfordert meist keine Änderungen am Code.
4. Starten Sie die Anwendung neu oder deployen Sie sie neu, und bauen Sie die Docker-Images neu. Auf Vercel genügt bei Projekten mit 22.x und 24.x ein erneutes Deployment.
5. Bei Node.js 20.x oder einer anderen Linie ohne Support warten Sie nicht auf einen Patch, denn es wird keinen geben. Wechseln Sie auf 22.x, 24.x oder 26.x: zuerst an einer Testkopie, dann auf der Website, in den nächsten Tagen.
6. Fragen Sie Ihr Hosting nach dem Update der systemweiten Brotli-Pakete, auch wenn Sie WordPress haben.

Muss das Update einige Tage warten, raten Sicherheitsfirmen (u. a. Aikido und ELLIO), eingehende mit Brotli komprimierte Anfragen (Header Content-Encoding: br) vorübergehend abzulehnen, und zwar auf einem Proxy-Server, in der Firewall oder in der Anwendung selbst. Das ist nur eine kurzfristige Absicherung: Sie schützt nicht vor Daten, die von fremden Servern abgerufen werden, und ersetzt kein Update. Vercel hat am 21. Oktober für alle Projekte Firewall-Regeln gegen diese Lücke aktiviert, betont aber selbst, dass sie das Node.js-Update nicht ersetzen.

Bitten Sie nach dem Update darum, die Logs seit dem 21. Oktober durchzusehen: ob die Anwendung ungewöhnlich oft neu gestartet wurde und ob unbekannte Dateien, Prozesse oder Konten aufgetaucht sind. Weckt etwas Zweifel, melden Sie den Vorfall bei CERT Polska (dem polnischen Computer-Notfallteam).

Was Sie dem Hosting oder dem Dienstleister auftragen sollten

Wer Node.js aktualisiert, hängt davon ab, wo die Website läuft:

Fertige Nachricht zum Kopieren:

Guten Tag, am 21. Oktober hat Node.js Sicherheitskorrekturen veröffentlicht, darunter den Patch für die Lücke CVE-2026-111497 (Node2Shell, Brotli). Bitte teilen Sie mir mit:

1. Läuft unsere Website oder Anwendung auf einem Server mit Node.js, und wenn ja, in welcher Version?
2. Wurde Node.js auf die Version 22.23.4, 24.22.1, 26.12.1 oder neuer aktualisiert, und wurde die Anwendung neu gestartet?
3. Wurden auf dem Server die systemweiten Brotli-Pakete aktualisiert?
4. Ist in den Logs seit dem 21. Oktober etwas Auffälliges zu sehen? Vielen Dank und bitte um Antwort innerhalb von 2 Werktagen.

Antwortet der Dienstleister nicht oder kümmert sich bei der Website niemand um Updates, ist das ein Zeichen, dass man das ordnen muss. Ich kann die Betreuung der Website übernehmen, und wenn Sie wünschen, dass sie auf einem Server läuft, den ich selbst betreue, sorge ich auch für Domain und Hosting (ab 390 PLN/Jahr netto, Server in Polen oder der EU).

Versionen ohne Support: eine Lehre für die Zukunft

Node.js 20.x hat keinen Patch erhalten, weil sein Support bereits ausgelaufen ist. Das ist derselbe Mechanismus wie bei PHP: Über das Ende des Supports für PHP 8.2, das auf den 31. Dezember 2026 fällt, habe ich kürzlich geschrieben. Eine Version ohne Support läuft normal bis zu dem Tag, an dem eine Lücke auftaucht. Dann wartet statt eines einfachen Updates ein Umzug auf eine neuere Version unter Zeitdruck auf Sie.

Prüfen Sie deshalb einmal im Quartal drei Dinge:

• auf welcher Version von Node.js oder PHP die Website läuft und bis wann diese Version Support hat,
• wer laut Vertrag für Updates zuständig ist und wie schnell auf dringende Lücken reagiert wird,
• ob sich das Backup wirklich wiederherstellen lässt.

In den nächsten Tagen schreibe ich in der Serie „Lücken und Schwachstellen“ unter anderem über die Oktober-Korrekturen in Next.js und React und darüber, wer für Updates verantwortlich ist: das Hosting, der Dienstleister oder die Firmenleitung.

Zusammenfassung

Node2Shell ist eine ernste Lücke, aber für die meisten Firmen ist die Behebung einfach: Update von Node.js auf die Version 22.23.4, 24.22.1, 26.12.1 oder neuer und Neustart der Anwendung. Am meisten Arbeit haben Websites auf Node.js 20.x und anderen Linien ohne Support, denn dort muss auf eine neuere Linie umgestiegen werden. Wissen Sie nicht, worauf Ihre Website läuft, senden Sie Ihrem Dienstleister noch heute die Nachricht aus diesem Ratgeber.

Kümmert sich niemand um die Updates Ihrer Website, schreiben Sie mir. Im Rahmen der technischen Betreuung überwache ich die Website, mache Backups und spiele Sicherheitsupdates ein. Zur Wahl stehen drei Pakete: Wache ab 149 PLN/Monat netto (dringende Updates in 2 Tagen), Standard ab 349 PLN/Monat netto (Reaktion in 1 Werktag) und Pro ab 749 PLN/Monat netto (Reaktion in 4 Stunden). Ein Sicherheitsaudit (ab 990 PLN netto) zeigt, was sonst noch verbessert werden muss. Ich antworte innerhalb von 24 Stunden, und wer zum ersten Mal mit mir arbeitet, erhält 20 % Rabatt auf den ersten Auftrag.