10 CVEs in Node.js, eine RCE-Sicherheitslücke in Brotli und was zu tun ist, wenn Ihre Version das Ende des Lebenszyklus erreicht hat

Die Kurzfassung

Zur Langfassung springen ↓

Was geschah: Am 21. Oktober 2026 veröffentlichte Node.js eine Woche nach einer Vorwarnung Sicherheitsupdates für seine drei unterstützten Versionsreihen 22.x, 24.x und 26.x. Zehn CVEs, von denen vier als „High“ eingestuft wurden. Zu diesem Abschnitt springen →

Was die schlimmste Schwachstelle bewirkt: CVE-2026-111497 ist ein Schreibzugriff außerhalb des zulässigen Bereichs im Brotli-Decoder, der in Node.js enthalten ist, und laut Sicherheitshinweis ermöglicht dies die Ausführung von Code aus der Ferne. Jeder Prozess auf einem nicht gepatchten System, der Brotli-Daten entpackt, die ein Angreifer kontrolliert, ist gefährdet – und Ihr Code muss Brotli dafür nicht einmal direkt aufrufen. Zu diesem Abschnitt springen →

Wie schlimm es wirklich ist: Der erste öffentliche Proof-of-Concept führte nur bei einer absichtlich geschwächten Version zur Codeausführung, wodurch die Situation weniger dringlich erschien, als es der Wortlaut der Sicherheitsempfehlung vermuten ließ. Daraufhin veröffentlichte das Red Team von Imperva Node2Shell, wobei die Codeausführung auf dem offiziellen Node.js-Image 24.22.0 über fetch() sowie die Analyse von Express-5-Anfragen. Bis zum 22. Oktober wurden keine Fälle von Missbrauch in freier Wildbahn gemeldet. Zu diesem Abschnitt springen →

Wer ist betroffen: Alle Versionen der Reihen 22.x, 24.x oder 26.x, die älter sind als die korrigierte Version der jeweiligen Reihe, sowie die Reihen, deren Lebenszyklus beendet ist und für die Node.js keine Patches mehr bereitstellt. Die weiter unten stehende CVE-Tabelle zeigt, welche CVEs welche Reihe betreffen. Der Sicherheitshinweis wiederholt die bereits bekannte Warnung, dass Versionen, deren Lebenszyklus beendet ist, immer betroffen sind, und dass Node.js 20, 18, 16, 14 und 12 keine Updates vom Upstream erhalten. Zu diesem Abschnitt springen →

Der aktuelle Stand: Upstream-Korrekturen für die Versionen 22, 24 und 26 sind bereits verfügbar. Die WAF von Vercel blockiert den eingehenden Angriffspfad für Projekte auf ihrer Plattform, deckt jedoch keine Antworten ab, die Ihr Code von anderen Quellen abruft. ELS-Builds für betroffene, nicht mehr unterstützte Produktlinien werden voraussichtlich in den nächsten 24 bis 48 Stunden bereitgestellt.

Was heute zu tun ist: Führen Sie die Patches für die unterstützten Produktlinien durch, verschieben Sie die Produktlinien, deren Lebenszyklus endet, auf einen festen ELS-Build, sobald der für Ihre Produktlinie verfügbar ist, und starten Sie alles neu, da ein laufender Prozess den alten Decoder im Speicher belässt. So sehen Sie, was gerade läuft:

ps -eo pid,lstart,args | grep -E '[n]ode( |$)'

Zu diesem Abschnitt springen →

Die meisten Sicherheitsmaßnahmen für Node.js finden eine Ebene höher statt. Dependabot eröffnet einen Pull-Request, npm audit Es kehrt Stille ein, und niemand verschwendet auch nur eine Sekunde damit, über das Binärsystem nachzudenken, auf dem alles läuft. Die Laufzeitumgebung hat jedoch ihre eigenen CVEs, und am 21. Oktober stellte sich heraus, dass die schlimmste davon eine Speicherbeschädigung in einem Decoder war, den Ihre App möglicherweise direkt aus dem Internet bezieht.

Am 22., 24. oder 26. ist der Fix langweilig. Die Patch-Version erhöhen, die Flotte aktualisieren, weitermachen.

Es wird deutlich weniger langweilig, wenn ein Teil der Infrastruktur noch auf Node.js 18 oder 20 läuft, weil ein natives Add-on auf neueren Versionen nicht kompiliert werden kann oder weil sich die Migration des Frameworks immer wieder um ein Quartal verzögert. Diese Zeilen enthalten einen Brotli-Decoder, der aus der Zeit vor der Fehlerbehebung stammt, und sie erhalten keinen der Patches. Der Großteil dieses Beitrags befasst sich mit dieser Lücke.

Das Projekt gab wie üblich eine Woche im Voraus eine Vorwarnung heraus. Am 14. Oktober veröffentlichte Antoine du Hamel eine Vorwarnung in der oss-security-Mailingliste, in der er mitteilte, dass die neuen Versionen 22, 24 und 26 am oder kurz nach dem 21. Oktober erscheinen würden, wobei der höchste Schweregrad mit „High“ eingestuft wurde. Es wurden weder Komponentennamen noch CVE-Nummern genannt, was für Node.js üblich ist. Die Veröffentlichungen erfolgten termingerecht.

Die Überschrift lautet „CVE-2026-111497“. In der Sicherheitsmitteilung werden Khai Tran und Sylvie Mayer von OpenAI Codex Security als Melder sowie Matteo Collina und Antoine du Hamel als Entwickler des Patches genannt. In einigen frühen Berichten hieß es, Collina habe die Schwachstelle entdeckt, doch laut Sicherheitshinweis war er an der Behebung beteiligt. Der Patch selbst ist eine Auswahl aus dem Upstream-Brotli-Commit 0ed4268a, der die sehr zurückhaltende Meldung „Ungültigen Stream früher erkennen und melden“ enthält.

Der Zeitpunkt dieses Commits ist merkwürdig. Laut „The Hacker News“ wurde die Änderung erstmals im Februar 2026 in den Quellcode von Brotli aufgenommen, tauchte jedoch erst am 21. Oktober in einer Sicherheitsversion auf, als Brotli 1.2.1, 1.1.1 und 1.0.10 veröffentlicht wurden. Ein Fix für einen Fehler in der Speichersicherheit lag also monatelang in einem öffentlichen Repository, und die Entdeckung wird einem KI-Sicherheitstool zugeschrieben. Man darf davon ausgehen, dass diese Kombination noch viel häufiger vorkommen wird und dass die Zeitspanne zwischen einem unangekündigten Upstream-Commit und einem funktionierenden Exploit immer weiter schrumpfen wird.

Die anderen drei Probleme mit hohem Schweregrad betreffen alle die Verarbeitung von Namen. CVE-2026-106069 ermöglicht es einem TLS-Zertifikat, die Hostnamen-Überprüfung zu bestehen, wenn der Host nur ungenau zu einer IP-Adresse aufgelöst wird. CVE-2026-105483 ist eine separate Umgehungsmöglichkeit, die funktioniert, wenn die IP-Adresse in Ziffern mit voller Breite geschrieben wird. Diese betrifft nur die Versionen 24.x und 26.x, und The Hacker News weist darauf hin, dass der Commit, der den Fehler behebt, diesen als „Low-Severity“ und schwer auszunutzen beschreibt, obwohl der Sicherheitshinweis ihn als „High“ einstuft. CVE-2026-105482 betrifft dns.resolve(), wo ein Name, der ein NUL-Byte enthielt, möglicherweise abgeschnitten wurde, sodass der von Ihrem Code validierte Name und der tatsächlich abgefragte Name nicht übereinstimmten. Die gepatchten Versionen lehnen NUL-Bytes in der Resolver-Eingabe von vornherein ab.

Die Punkte „Medium“ und „Low“ sind zwar weniger schwerwiegend, aber dennoch nicht zu vernachlässigen. Für alle, die CLIs oder Tools als einzelne ausführbare Anwendungen bereitstellen, ist insbesondere CVE-2026-106074 erwähnenswert. Die Entropie-Caches hinter crypto.randomUUID() und crypto.randomInt() wurden in Start-Snapshots und SEAs gespeichert, sodass jeder Prozess, der aus derselben Binärdatei gestartet wurde, dieselben „zufälligen“ Werte erzeugte. Alles, was diese UUIDs als Tokens oder Nonces verwendet, sollte genauer unter die Lupe genommen werden.

Die neuen Versionen aktualisieren außerdem c-ares, undici und die mitgelieferten CA-Zertifikate in allen drei Produktreihen, OpenSSL in den Versionen 22.x und 24.x sowie SQLite in der Version 22.x. Die Änderung an den Zertifikaten ist der heimliche Star. Node.js verwendet die Root-Liste von Mozilla, führt jedoch standardmäßig keine Sperrprüfung durch, sodass Zertifikatsketten, die auf den acht eMudhra-Zwischenzertifikaten basieren, die diesen Monat als kompromittiert gemeldet wurden, bis zu dieser Version weiterhin als gültig erkannt wurden. Die gepatchten Builds enthalten eine fest integrierte Sperrliste dieser Schlüssel – es handelt sich um dieselben Hashes, die Go in seinem eigenen Fix bereitgestellt hat. Dabei sind zwei Einschränkungen zu beachten: TLS-Sitzungen, die vor dem Upgrade wieder aufgenommen wurden, werden erst nach Ablauf der Zeitüberschreitung erneut überprüft, und Produktlinien, deren Lebenszyklus beendet ist, erhalten die Sperre überhaupt nicht.

Node.js dekodiert Brotli nicht von sich aus. Ein Prozess in Ihrer Anwendung muss dies anfordern, und viele Prozesse tun dies, ohne dass Sie es bemerken.

Der ausgehende Datenverkehr ist das Wichtigste. Die integrierte fetch() dekomprimiert Antworten, die Content-Encoding: br automatisch, und es gibt keine Option für den Aufrufer, dies zu deaktivieren. Aktuelle Versionen von axios, node-fetch und got verhalten sich standardmäßig genauso. Somit ist jeder Dienst, der URLs abfragt, über die er keine Kontrolle hat, davon betroffen – ein Webhook-Absender, ein Link-Vorschau-Worker, ein Scraper oder ein KI-Agent, der Webseiten in eine Eingabeaufforderung lädt. Vercels Mitteilung fügt einen weiteren Punkt hinzu, den man leicht übersehen könnte. Bei selbst gehostetem Next.js werden Brotli-Antworten bei der Bildoptimierung nicht blockiert. Die Lösung besteht daher darin, Node.js zu aktualisieren, ohne die Next.js-Konfiguration zu ändern.

Inbound ist der zweite Weg. Die Body-Parser von Express 5 dekomprimieren über Body-Parser 2.x standardmäßig Brotli-Anfrage-Body-Daten, sodass eine API, die express.json() entpackt einen Brotli-Body, den es nie angefordert hat. Der Body-Parser 1.x von Express 4 unterstützt keine Brotli-Bodies und lehnt diese mit einem 415 ab. Ein bloßer http Der Server dekodiert Anfrageinhalte nicht allein durch deren Empfang. Dann gibt es noch den direkten Weg, bei dem der Code aufruft zlib.brotliDecompress() oder createBrotliDecompress() bei Uploads, Archiven oder zwischengespeicherten Artefakten.

Eine schnelle Methode, um die Dringlichkeit einzuschätzen: Alles, was auf Express 5 mit dem Internet verbunden ist oder beliebige URLs abruft, sollte noch heute gepatcht werden. Ein Express-4-Dienst, der ausschließlich mit eigenen Backends kommuniziert, ohne benutzerdefinierte Middleware zur Dekomprimierung und ohne direkte zlib Brotli greift auf externe Daten zurück und kann daher in der Liste etwas weiter unten stehen. Das Update ist diese Woche dennoch erforderlich, da die anderen neun CVEs unabhängig davon sind, welche Express-Version Sie verwenden. Der Sicherheitshinweis enthält keine Abhilfemaßnahme. Einstellung inflate: false zu Body-Parsern, zum Deaktivieren der Dekomprimierung in Axios oder Got oder zum Zurückweisen von Content-Encoding: br Über den Proxy lässt sich das Risiko zwar für einige Stunden begrenzen, aber fetch() hat keinen Ausschalter, und keine dieser Maßnahmen stellt eine Lösung dar.

Die Entwicklung rund um diese Sicherheitslücke verlief rasant. Am 22. Oktober erschien ein öffentlicher Proof-of-Concept, der laut „The Hacker News“ lediglich bei einer absichtlich geschwächten Testversion zur Codeausführung führte. Bei einer Standardversion berichtete der Autor von einem Absturz und einem begrenzten Speicherzugriff. Es wäre ein Leichtes gewesen, dies zur Kenntnis zu nehmen und das Ticket auf den nächsten Sprint zu verschieben.

Am selben Tag veröffentlichte das Red Team von Imperva Node2Shell. In neuen Containern, auf denen das offizielle Node.js 24.22.0 Linux arm64-Image lief – ohne Debugger und ohne instrumentierte Binärdatei –, führten Brotli-Daten, die als abgerufene Antwort oder als Request-Body übermittelt wurden, dazu, dass die Anwendung den mit diesen Daten gelieferten Code ausführte. Sie konnten dies reproduzieren durch fetch() sowie in den Versionen 5.0.0 bis 5.3.0 von Express mit der raw() und json() Parser. Die gleichen Eingaben wurden von 24.22.1 zurückgewiesen. Es waren mehrere Versuche in ihrer Konfiguration nötig, und sie haben nur arm64 getestet, es ist also kein Kinderspiel – aber es ist weit entfernt von „funktioniert nur im Labor“.

Falls Triage diesen Fall auf Grundlage des ersten Proof-of-Concept zurückgestellt hat, sollte er wieder aufgenommen werden. Imperva weist zudem darauf hin, dass unerwartete Prozessabbrüche während der Dekomprimierung dabei helfen können, die Untersuchung zu priorisieren, obwohl weder Abstürze noch Dekodierfehler für sich genommen ein verlässliches Anzeichen für eine Ausnutzung darstellen. Bis zum 22. Oktober wurden keine Ausnutzungen in freier Wildbahn gemeldet, und CVE-2026-111497 ist nicht im Katalog der bekannten ausgenutzten Schwachstellen der CISA aufgeführt.

Die Linien stromaufwärts berühren sich nicht

Sicherheitshinweise zu Node.js enthalten eine allgemeine Warnung, und auch dieser Hinweis greift sie wieder auf. Versionen, deren Lebenszyklus abgelaufen ist, sind immer betroffen, wenn ein Sicherheitsupdate veröffentlicht wird. Das ist eine Grundsatzaussage und kein Testergebnis für einzelne CVEs. Sicher ist, dass der Brotli-Fix erst am 21. Oktober in Node.js integriert wurde, sodass keine Upstream-Version, deren Lebenszyklus abgelaufen ist, diesen enthält. Node.js 20 erreicht das Ende des Lebenszyklus am 30. April 2026, 18 am 30. April 2025, 16 am 11. September 2023, 14 am 30. April 2023 und 12 am 30. April 2022. Für keine dieser Versionen wird es eine entsprechende Version geben. Auch Vercel hat sich diesbezüglich unmissverständlich geäußert. Projekte auf seiner Plattform, die noch auf Node.js 20 festgelegt sind, müssen auf 22 oder 24 umsteigen und neu bereitgestellt werden, da für 20 kein Fix bereitgestellt wird.

Wie weit reicht der Brotli-Fehler zurück? Brotli ist bereits seit den Versionen 10.x und 11.x in Node.js enthalten, und das Brotli-Projekt hat diesen Fix bis zurück in den 1.0-Zweig integriert. Das ist ein deutlicher Hinweis darauf, dass die anfällige Decoder-Logik schon lange besteht und nicht erst im vergangenen Frühjahr eingeführt wurde. Node.js 16 und ältere Versionen verfügen nicht über eine globale fetch(), aber Axios und Got liefern immer noch Brotli-Antworten an denselben zlib-Decoder, und direkt zlib Anrufe funktionieren auf jeder Leitung gleich.

Die Installationen, die Probleme verursachen, sind selten diejenigen, die man gemeinhin als Node.js-Server betrachtet. Ein Build-Container, der auf Node 16 festgelegt ist, weil ein Add-on zur Bildverarbeitung unter Node 18 nicht mehr kompiliert werden konnte. Ein internes Admin-Tool, das jemand im Jahr 2022 als einzelne Binärdatei bereitgestellt hat. Eine Hersteller-Appliance mit Node 14 unter ihrer Webkonsole. Stellen Sie sich ein Zahlungsteam mit 40 Diensten auf Node 18 vor, die dort aufgrund einer einzigen Abhängigkeit feststecken, deren Betreuer das Unternehmen verlassen hat, und das eine RCE-Sicherheitswarnung liest, der kein Patch beigefügt ist. Niemand wird bis Freitag 40 Dienste migrieren.

Genau diese Lücke schließt ELS for Runtimes. TuxCare stellt Sicherheitspatches für Node.js-Versionen bereit, deren Lebenszyklus abgelaufen ist. Sobald also die neue Version der Produktreihe veröffentlicht wird, erhält ein auf Version 18 festgelegter Dienst die Patches des Monats als Paket-Update – statt einer Notfallmigration. Die Migration muss dennoch erfolgen, und die End-of-Life-Termine für Node.js ändern sich nicht. Mit ELS erfolgt dies nach einem Zeitplan, den Ihr Team festlegt – und nicht nach einem, den eine Sicherheitsempfehlung für Sie vorgibt.

In der Dokumentation zu „ELS for Runtimes“ sind Node.js-Versionen 12 bis 26 nach Betriebssystem aufgeführt; weitere Versionen und Architekturen sind auf Anfrage erhältlich. Einen tieferen Einblick in die Nutzung nach Ablauf der Lebensdauer (End of Life, EOL) bietet dieser Leitfaden zum erweiterten Support für Node.js nach EOL.

In der Dokumentation ist derzeit Folgendes unter „Aktiver Support“ aufgeführt:

Builds sind für x86_64 auf allen unterstützten Betriebssystemen sowie für aarch64 (arm64) unter Debian 12, Debian 13 und Alpine 3.23 und höher verfügbar. Die arm64-Builds sind diese Woche besonders wichtig, da die Demo zur Codeausführung von Imperva auf arm64 lief.

Distributionspakete funktionieren etwas anders. Einige Builds, darunter Debian- und Ubuntu-Pakete sowie Homebrew, verweisen auf eine gemeinsam genutzte Brotli-Bibliothek anstelle der in Node.js enthaltenen Version. In diesem Fall sollten Sie die Sicherheitsupdates für die Brotli-Bibliothek verfolgen, die Ihr Paketmanager bereitstellt. Die Überprüfung erfolgt mit einer einzigen Zeile:

ldd "$(command -v node)" | grep -i brotli

Ein „libbrotli“-Eintrag in der Ausgabe bedeutet, dass die Binärdatei eine gemeinsam genutzte Brotli-Bibliothek einbindet. Wenn kein Eintrag vorhanden ist, deutet dies auf eine mitgelieferte oder statisch eingebundene Kopie hin – so werden offizielle Builds von nodejs.org ausgeliefert. Da sich dies jedoch allein anhand des Befehls nicht eindeutig feststellen lässt, sollten Sie Ihre Paketinformationen oder Build-Konfiguration überprüfen, falls dies von Bedeutung ist. ldd ist nur unter Linux verfügbar. Unter macOS, wo Homebrew läuft, otool -L "$(command -v node)" | grep -i brotli erfüllt denselben Zweck.

Holen Sie sich ELS für Runtimes noch heute →

Beginnen Sie mit der Bestandsaufnahme, denn die Liste ist immer länger als erwartet. Versionsmanager wie nvm und Volta speichern Binärdateien in den Home-Verzeichnissen, Distributionspakete hingegen in /usr/bin, und ELS wird unter /opt/alt/ mit einem Aktivierungsskript pro Version. Diese beiden Bash-Schleifen geben jede node in Ihrem aktuellen PATH enthalten ist, dann wird jeder ELS-Build unter /opt/alt/, mit der jeweiligen Version, die jedes einzelne angibt:

type -ap node | while read -r n; do echo "$n $("$n" -v)"; done
for e in /opt/alt/alt-nodejs*/enable; do [ -f "$e" ] && ( . "$e" && echo "$e $(node -v)" ); done

Damit haben Sie eine erste Bestandsliste, die jedoch nicht mit dem übereinstimmt, was die einzelnen Dienste tatsächlich ausführen. systemd-Einheiten, PM2-Konfigurationen, CI-Runner und Container-Basisimages können jeweils auf unterschiedliche Binärdateien verweisen; überprüfen Sie daher auch diese. Auf RPM-basierten Systemen werden die ELS-Builds mit folgendem Befehl aktualisiert: yum update 'alt-nodejs*', und die Anleitungen zu DEB und APK befinden sich auf derselben Dokumentationsseite.

Verlassen Sie sich nicht auf die Versionsangaben für den Brotli-Fix in den Upstream-Builds. Node.js hat den Patch gezielt übernommen, ohne die Brotli-Version zu erhöhen, daher process.versions.brotli Sieht vorher und nachher identisch aus. Mit dieser Version wurde eine neue zlib-Konstante eingeführt, über die gepatchte Upstream-Binärdateien verfügen, ungepatchte hingegen nicht:

node -p "'BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH' in require('zlib').constants"

true bedeutet, dass der feste Decoder vorhanden ist. Diese Überprüfung ist nur für offizielle Upstream-Builds zuverlässig; bei Distribution- oder ELS-Builds sollten Sie sich daher an die Hinweise des Anbieters halten. Das projektinterne npx is-my-node-vulnerable ist auch für Upstream-Installationen praktisch, arbeitet jedoch anhand von Versionsnummern, sodass ein zurückportierter Build möglicherweise als anfällig erscheint, obwohl er es gar nicht ist.

Starten Sie anschließend das System neu – dies ist der Schritt, der übersprungen wird. Ein laufender Node.js-Prozess behält den alten Decoder bei, bis er beendet wird, und ein Container behält ihn bei, bis er aus einem Image neu bereitgestellt wird, das auf einer gepatchten Basis neu erstellt wurde. SEAs und Start-Snapshots müssen mit der gepatchten Laufzeitumgebung neu erstellt werden, und im Fall von CVE-2026-106074 stellt diese Neuerstellung die Behebung des Problems dar. Führen Sie den Befehl erneut aus: ps Befehl aus dem Anfang dieses Beitrags und überprüfen Sie jeden Node.js-Prozess, der nach der Aktualisierung gestartet wurde. Einzelne ausführbare Anwendungen und umbenannte Binärdateien werden in dieser Auflistung nicht angezeigt; überprüfen Sie diese daher anhand des Dienstnamens.

Schließen Sie das Ticket schließlich nicht aufgrund eines Versionsvergleichs durch einen Scanner. Ein zurückportierter Build kann weiterhin seine ursprüngliche Upstream-Version angeben. Sofern Ihre Tools dies unterstützen, speisen Sie die maschinenlesbaren Sicherheitsdaten von TuxCare für Node.js ein, die auch CSAF-Sicherheitshinweise umfassen, und führen Sie Aufzeichnungen über das installierte Paket, den betreffenden Sicherheitshinweis und den Prozess, der den Datenverkehr tatsächlich bedient. Genau das wird ein Auditor von Ihnen verlangen.

Warum sich ein Laufzeitfehler anders auswirkt

Auch eine Laufzeitumgebung ist eine Abhängigkeit, und sobald niemand mehr Sicherheitspatches dafür bereitstellt, bleibt jede neue Kernschwachstelle so lange unbehoben, wie diese Laufzeitumgebung im Produktivbetrieb verbleibt. Teams, die niemals eine zwei Jahre alte Lodash-Version einsetzen würden, führen ihren Code ohne Bedenken auf einer Node.js-Version aus, für die seit 2025 keine Sicherheitspatches mehr bereitgestellt werden.

Diese Woche hat auch gezeigt, wie wenig Zeit für die Planung bleibt. Sieben Tage von der Vorwarnung bis zur Veröffentlichung, ein öffentlicher Proof-of-Concept am nächsten Tag, ein funktionierender Exploit gegen das Standard-Image noch am selben Tag und Korrekturen, die genau drei Release-Versionen umfassen. „Im nächsten Quartal aktualisieren“ ist ein absolut guter Plan für das nächste Quartal. Für diese Woche ist es jedoch überhaupt kein Plan.

Führen Sie also jetzt die Patches für die unterstützten Zeilen durch und starten Sie die entsprechenden Dienste neu. Was die Node.js-Zeilen betrifft, die der Upstream-Entwickler zurückgelassen hat, sollten Sie diese auf einen korrigierten ELS-Build umstellen, sobald der für Ihre Zeile verfügbar ist. Schränken Sie in der Zwischenzeit den Zugriff auf nicht vertrauenswürdige Brotli-Daten ein und legen Sie anschließend einen Zeitplan für die Migration fest.

Holen Sie sich ELS für Runtimes noch heute →

Wie sich diese Ereignisse abspielten

Quellen

Zu den Quellen für diesen Beitrag gehören die Sicherheitsmitteilung von Node.js vom 21. Oktober 2026, die Versionshinweise zu den Versionen 22.23.4 und 24.22.1, die Vorwarnung auf oss-security, der Node.js-Veröffentlichungsplan, der Commit zur Behebung des Google/Brotli-Fehlers, der Pull-Request zur eMudhra-Blockliste, das Sicherheitsbulletin von Vercel, die Node2Shell-Studie von Imperva, die Berichterstattung von The Hacker News, den CISA-KEV-Katalog, „is-my-node-vulnerable“ sowie die ELS-for-Runtimes-Dokumentation von TuxCare für Node.js und maschinenlesbare Sicherheitsdaten.