Lücke in Node.js: was Sie jetzt erledigen

Am 21. Oktober veröffentlichte das Node.js-Projekt ein Sicherheitsupdate für zehn Lücken. Die schwerste, CVE-2026-111497, steckt in dem Teil, der mit Brotli komprimierte Daten entpackt. Mit speziell präparierten Daten kann ein Angreifer dort außerhalb des vorgesehenen Speichers schreiben. Das kann ein Programm abstürzen lassen, Speicherinhalte preisgeben oder im schlimmsten Fall Code des Angreifers ausführen. Die Lücke steckt in allen unterstützten Versionen von Node.js und in allen älteren. Die Versionen 22.23.4, 24.22.1 und 26.12.1 beheben sie.

Warum das weiter reicht, als es scheint

Node.js läuft unter vielen Webanwendungen, APIs, Kundenportalen und internen Werkzeugen, und auch unter vielen Entwicklungs- und KI-Werkzeugen. Sie müssen Brotli nicht selbst verwenden, um betroffen zu sein. Brotli ist ein gängiges Verfahren, um Webverkehr zu verkleinern, und die eingebaute fetch-Funktion von Node.js entpackt solche Antworten automatisch. Ruft Ihre Anwendung etwas von einer Adresse ab, die ein anderer kontrolliert, kann das schon genügen.

Hinzu kommt, dass Node.js auf einem Server oft nicht automatisch aktualisiert wird. Wer es einmal aus einer eigenen Paketquelle oder per Installationsskript eingerichtet hat, bleibt auf dieser Version, bis jemand sie bewusst aktualisiert. Die automatischen Sicherheitsupdates des Betriebssystems erfassen es meist nicht.

Was Sie jetzt erledigen

1. Finden Sie heraus, was bei Ihnen auf Node.js läuft: Ihre Website oder Web-App, ein Kundenportal, Verbindungen zwischen Systemen und die Server, auf denen Entwickler oder KI-Agenten arbeiten. Unsicher? Fragen Sie Ihren Webentwickler oder IT-Partner.
2. Aktualisieren Sie auf 22.23.4, 24.22.1 oder 26.12.1, je nach verwendeter Version. Nutzen Sie eine Version, die nicht mehr unterstützt wird, kommt keine Korrektur: Wechseln Sie dann auf eine unterstützte Version.
3. Prüfen Sie danach, welche Version wirklich läuft. Ein aktualisiertes Paket bewirkt nichts, solange der alte Prozess noch läuft; erst nach einem Neustart läuft die neue Version.
4. Prüfen Sie, ob seit Anfang Oktober Node.js-Prozesse unerwartet abgestürzt sind. Ein fehlgeschlagener Angriff hinterlässt oft einen Absturz. Finden Sie einen, ziehen Sie jemanden mit Fachkenntnis hinzu.
5. Halten Sie fest, was Sie wann getan haben. Fällt Ihre Organisation unter NIS2 oder fragt ein Kunde nach einem Nachweis Ihrer Sicherheit, haben Sie ihn sofort zur Hand.

Und Stilops selbst

Stilops läuft auf Node.js, und unsere Agenten rufen für ihre Arbeit Webseiten ab. Wir waren also betroffen. Am Tag, an dem wir die Lücke sahen, haben wir dafür gesorgt, dass jede Auslieferung Node.js zuerst auf die korrigierte Version bringt und dass die Maschinen, auf denen Agenten arbeiten, mit dieser Version neu aufgebaut werden. Auch unsere Testumgebung holt sich ab jetzt immer die neueste Version.

Danach haben wir nach Spuren von Missbrauch gesucht. Wir fanden keine unerwarteten Abstürze von Stilops seit dem 8. Oktober, so weit unsere Protokolle zurückreichen, und keine zurückgebliebenen Absturzdateien. Keine Spuren sind kein Beweis, dass nichts passiert ist, aber es ist das, was sich messen lässt. Wir behalten es im Blick.