Node.js-Sicherheitslücke:
Was die Brotli-Lücke für Ihre Web-Anwendung bedeutet

Am 21. Oktober 2026 hat das Node.js-Projekt eine kritische Sicherheitslücke geschlossen. Sie steckt in einem Baustein, den kaum jemand kennt: dem Brotli-Decoder, der komprimierte Daten entpackt. Mit präparierten Daten kann ein Angreifer im schlimmsten Fall eigenen Code auf Ihrem Server ausführen.

Node.js läuft an mehr Stellen, als die meisten denken. Hinter vielen Web-Anwendungen, Kundenportalen und Shops steckt es, aber auch in Werkzeugen wie n8n, Strapi oder Uptime Kuma. Schützen kann Sie nur ein Node.js-Update. Ein Update der Anwendung allein reicht oft nicht.

Das Wichtigste in Kürze

• Betroffen sind die Node.js-Versionen 22, 24 und 26.
• Abgesichert sind Node.js 22.23.4, 24.22.1 und 26.12.1 sowie alle neueren Versionen.
• Node.js 20 und Node.js 25 bekommen keinen Fix mehr. Hier hilft nur der Umstieg.
• Die Lücke wird mit 9,2 von 10 Punkten bewertet. Angriffe waren am 23. Oktober noch nicht bekannt.
• Wer Docker nutzt, muss das Image neu bauen oder herunterladen und den Container neu erstellen.

Was ist die Brotli-Lücke in Node.js?

Brotli ist ein Verfahren, mit dem Websites Daten verkleinern. Node.js bringt dafür einen eigenen Entpacker mit, und genau in dem steckt der Fehler. Offiziell heißt die Lücke CVE-2026-111497.

Der Entpacker erkennt bestimmte kaputte Daten nicht als Fehler. Er hält sie für unvollständig und wartet auf mehr. Dabei schreibt er die nachfolgenden Daten immer weiter in einen Zwischenspeicher, der nur acht Byte groß ist. Was darüber hinausgeht, überschreibt fremden Speicher.

Im harmlosesten Fall stürzt Ihre Anwendung ab. Schlimmer wird es, wenn ein Angreifer Speicherinhalte ausliest oder eigenen Code ausführt. Das Node.js-Projekt stuft die Lücke als hoch ein. Die offizielle CVE-Bewertung liegt bei 9,2 von 10 Punkten und damit im kritischen Bereich.

Der Fehler steckt in der Brotli-Bibliothek von Google selbst, in den Versionen 1.0.3 bis 1.2.0. Neben Node.js können deshalb auch andere Programme betroffen sein, die diese Bibliothek mitbringen.

Wann Ihre Anwendung angreifbar ist

Gefährlich wird die Lücke nur, wenn Ihre Anwendung Brotli-Daten entpackt, die von außen kommen.

Express gehört zu den verbreitetsten Gerüsten für Node.js-Anwendungen. Ab Version 5 entpackt Express eingehende Anfragen automatisch, wenn sie als Brotli gekennzeichnet sind. Ein Angreifer muss dafür nur eine präparierte Anfrage an ein Formular oder eine Schnittstelle schicken. Bei Express 4 ist das nicht der Fall, dort entpackt die Standardeinstellung nur gzip und deflate.

Auch der umgekehrte Weg ist möglich. Holt Ihre Anwendung mit der eingebauten fetch-Funktion Daten von einer fremden Website, entpackt Node.js die Antwort automatisch. Ein Angreifer, der eine solche Quelle kontrolliert, kann darüber präparierte Daten einschleusen.

Ob Ihre Anwendung einen dieser Wege nutzt, lässt sich von außen schwer sagen. Deshalb gilt: Behandeln Sie jede Node.js-Installation als betroffen, bis sie aktualisiert ist.

Bin ich betroffen? So prüfen Sie die Node.js-Version

1. Herausfinden, wo Node.js läuft: Fragen Sie sich nicht nur, welche Ihrer Anwendungen in Node.js geschrieben sind. Denken Sie auch an Automatisierung wie n8n, an Content-Systeme wie Strapi, an Datenbank-Oberflächen wie NocoDB und an Monitoring. Auch in Headless-Browsern für Screenshots oder PDF-Erzeugung steckt oft Node.js.
2. Version nachsehen: Auf dem Server zeigt der Befehl node -v die Version. In einem Docker-Container lautet er docker exec <container> node -v. Bei einem Hoster finden Sie die Version meist in der Verwaltungsoberfläche.
3. Mit den sicheren Versionen vergleichen: Abgesichert sind Node.js 22.23.4, 24.22.1 und 26.12.1 sowie alle neueren Versionen innerhalb derselben Reihe.
4. Nicht auf die Brotli-Versionsnummer verlassen: Node.js hat den Fix eingebaut, ohne die angezeigte Brotli-Version zu ändern. Bei Node.js 24.22.1 steht sie weiterhin auf 1.2.0. Maßgeblich ist allein die Node.js-Version.
5. Bei Anbietern nachfragen: Läuft eine Anwendung bei einem Dienstleister, genügt eine kurze Mail: „Läuft unsere Anwendung auf einer Node.js-Version, die gegen CVE-2026-111497 abgesichert ist?“ Eine klare Versionsnummer in der Antwort ist ein gutes Zeichen.

Das Update: Worauf Sie bei Docker, Hostern und fertigen Tools achten

Auf einem eigenen Server installieren Sie die neue Node.js-Version und starten danach jede Anwendung neu. Bis zum Neustart läuft der alte Code im Speicher weiter.

Bei Docker reicht es nicht, ein neues Image herunterzuladen. Der Container muss neu erstellt werden, sonst läuft er weiter mit dem alten Image. Aufpassen sollten Sie bei festgenagelten Versionen. Steht in Ihrem Dockerfile etwa node:24.21, bekommen Sie das Update nie automatisch. Mit node:24 und einem Neubau, der das Basis-Image frisch lädt, kommt jede neue Sicherheitsversion beim nächsten Deployment von selbst mit.

Fertige Werkzeuge wie n8n, NocoDB oder Strapi bringen ihr eigenes Node.js mit. Hier hilft nur ein Update auf eine Version des Herstellers, die bereits die neue Node.js-Version enthält. Bei n8n enthielt am 26. Oktober die neueste Version 2.44.7 das abgesicherte Node.js. Die ältere Reihe 2.21, auf der unsere Instanzen liefen, bekam kein Update mehr. Wer dort stehen geblieben ist, muss einen größeren Versionssprung machen. Legen Sie vorher eine Sicherung der Datenbank an und prüfen Sie danach, ob Ihre Workflows wieder laufen.

Rechnen Sie bei solchen Sprüngen mit Überraschungen. Bei uns verweigerte eine neue NocoDB-Version den Start, weil sie eine alte Einstellung plötzlich nicht mehr akzeptierte. Der Fehler war in wenigen Minuten behoben, aber nur, weil wir direkt danach nachgesehen haben.

Was tun mit Node.js 20 und anderen Altversionen?

Node.js 20 bekommt seit dem 30. April 2026 keine Sicherheitsupdates mehr. Für Node.js 25 endete die Unterstützung am 1. Juni 2026. Beide Versionen bleiben dauerhaft offen.

Der Umstieg auf Node.js 24 ist in vielen Fällen kleiner als befürchtet. Läuft Ihre Anwendung ohne kompilierte Zusatzmodule, genügt oft ein neues Basis-Image und ein Testlauf. Bei unseren eigenen Diensten auf Node.js 20 lief die komplette Testsuite nach dem Wechsel ohne einen einzigen Fehler durch.

Schwieriger wird es bei fertigen Werkzeugen, deren Hersteller nicht mehr aktualisiert. Dann können Sie den Programmcode in ein neues Image mit aktueller Node.js-Version übernehmen. Das ist eine Übergangslösung. Auf Dauer brauchen Sie ein gepflegtes Werkzeug.

Was wir bei unserer eigenen Inventur gelernt haben

Nach der Meldung haben wir alle unsere Server durchsucht. Gefunden haben wir 28 laufende Node.js-Instanzen auf sechs Servern. Acht davon steckten in fertigen Werkzeugen wie n8n, NocoDB, Strapi und Uptime Kuma, die niemand auf Anhieb mit Node.js verbindet.

Eine Anwendung war schon abgesichert, bevor wir überhaupt nachgesehen hatten. Ihr Image lädt bei jedem Deployment die neueste Node.js-24-Version, und seit dem Update gab es ein Deployment. Eine andere Anwendung war auf eine ältere Version festgenagelt und blieb deshalb offen. Den Unterschied machte ein einziger Eintrag im Dockerfile.

Zehn Dienste liefen noch auf Node.js 20, ein Werkzeug sogar auf Node.js 25. Für diese Versionen gibt es keinen Fix.

Die meiste Zeit hat uns das Suchen gekostet. Waren die Stellen einmal gefunden, ging das Update meist schnell. Wer eine aktuelle Liste seiner Dienste und ihrer Versionen führt, ist bei der nächsten Lücke deutlich früher fertig. Wie das bei PHP aussah, lesen Sie im Ratgeber PHP2Shell: Was die kritische PHP-Lücke für Ihre WordPress-Seite bedeutet.

Fazit

Die Brotli-Lücke ist ernst, aber gut zu beherrschen. Ein Update auf Node.js 22.23.4, 24.22.1 oder 26.12.1 schließt sie. Die eigentliche Aufgabe ist, jede Stelle zu finden, an der Node.js läuft, auch in fertigen Werkzeugen wie n8n, und dort die Version wirklich auszutauschen.

Sie möchten wissen, wie Ihre Anwendungen dastehen? Dann gehen wir die Liste gemeinsam durch. Der Update-Check ist kostenlos und unverbindlich.