Node.js-Sicherheitsrelease Oktober 2026: Brotli-RCE und TLS-Umgehungen

Am 21. Oktober 2026 hat das Node.js-Projekt die Versionen 22.23.4, 24.22.1 und 26.12.1 veröffentlicht. Sie beheben zehn Schwachstellen, vier davon mit hohem Schweregrad. Die gravierendste, CVE-2026-111497, ist ein Schreibzugriff außerhalb der Puffergrenzen im Brotli-Decoder von Node: Fehlerhaft komprimierte Daten können den Speicher beschädigen, und das Hosting-Unternehmen Vercel berichtet, dass Forscher damit Prozessspeicher auslesen und Befehle mit den Rechten des Node.js-Prozesses ausführen konnten. Zwei weitere Schwachstellen mit hohem Schweregrad lassen ein TLS-Zertifikat die Hostnamenprüfung bestehen, obwohl es sie nicht bestehen dürfte. Node.js 20 und 25 haben das Ende ihres Lebenszyklus erreicht und erhalten keinen Fix.

Welche Versionen behoben sind

Um welche zehn Schwachstellen es geht

Die Releases aktualisieren außerdem mitgelieferte Komponenten: c-ares, Undici, die Liste vertrauenswürdiger CAs (die kompromittierte Zwischen-CA von eMudhra wird entfernt), OpenSSL in 24 und 22 sowie SQLite in 22.

Wer von der Brotli-Schwachstelle betroffen ist

Node.js dekodiert Brotli nicht von sich aus. Betroffen sind Sie, wenn Ihr Code oder eine von ihm genutzte Bibliothek Brotli-Daten dekomprimiert, die jemand anderes kontrolliert. Das kommt häufiger vor, als es klingt:

• Das eingebaute fetch() dekodiert Antworten mit Content-Encoding: br automatisch. Ein Dienst, der von Nutzern gewählte URLs, Webhooks oder APIs von Drittanbietern abruft, kann eine bösartige Antwort erhalten.
• axios, got und node-fetch dekodieren komprimierte Antworten standardmäßig ebenfalls.
• Express 5 (body-parser 2) dekodiert Brotli-Request-Bodys standardmäßig, sodass eine API die Daten direkt von einem Angreifer empfangen kann.
• Jeder Aufruf von zlib.brotliDecompress, zlib.createBrotliDecompress oder DecompressionStream auf Uploads oder Daten von Dritten.

Patchen Sie zuerst dort, wo diese Fälle auf das Internet treffen: öffentliche APIs, die komprimierte Bodys annehmen, Dienste, die von Nutzern angegebene URLs abrufen, und alles, was hochgeladene Dateien entpackt.

Die TLS-Schwachstellen betreffen vor allem den Fall, dass ein Angreifer von einer CA, der Ihr Client vertraut, ein Zertifikat mit einem IP-förmigen DNS-Namen erhalten kann, die DNS-Schwachstelle den Fall, dass Ihr Code externe Eingaben an dns.resolve übergibt. Laut dem Fix-Commit sind die TLS-Probleme nicht leicht auszunutzen, doch dasselbe Update schließt sie.

Schritt 1: jede Node.js-Laufzeit finden

Listen Sie unter Linux jede node-Binärdatei mit ihrer Version auf:

sudo find / -xdev -type f -name node -perm -u+x 2>/dev/null | while read -r n; do echo "$n: $("$n" --version 2>/dev/null)"; done

Prüfen Sie, welche Laufzeit die laufenden Prozesse verwenden:

for p in $(pgrep -x node); do echo "$p $(sudo readlink -f /proc/$p/exe)"; done

Prüfen Sie in Docker jeden laufenden Container:

for c in $(docker ps --format '{{.Names}}'); do echo "$c: $(docker exec "$c" node --version 2>/dev/null)"; done

Kontrollieren Sie außerdem Versionsmanager (nvm, fnm, Volta, asdf), CI-Runner, Build-Images, Electron-Apps und Serverless-Funktionen, bei denen die Laufzeitversion in der Projektkonfiguration festgelegt ist.

Schritt 2: aktualisieren

Ubuntu und Debian mit den NodeSource-Paketen:

sudo apt update && sudo apt install --only-upgrade nodejs && node --version

Mit nvm:

nvm install 24.22.1 && nvm alias default 24.22.1

Container: Stellen Sie das Basis-Image auf eine feste Version um, zum Beispiel node:24.22.1-alpine oder node:22.23.4-bookworm-slim, bauen Sie neu und deployen Sie erneut. Ein Update des Hosts ändert nichts an dem, was im Container läuft.

Serverless- und Hosting-Plattformen: Auf Vercel patcht Vercel Projekte mit 22.x und 24.x selbst und hat Firewall-Regeln gegen den eingehenden Angriff ergänzt; Projekte, die noch auf 20.x laufen, müssen auf 22.x oder 24.x wechseln und erneut deployen. Prüfen Sie bei anderen Plattformen die Mitteilung des Anbieters und deployen Sie erneut, sobald die gepatchte Laufzeit verfügbar ist.

Distributionspakete wie das eigene nodejs-Paket von Ubuntu hinken oft hinterher. Zeigt node --version nicht 22.23.4, 24.22.1 oder 26.12.1 an (oder einen Distributions-Build, der diese CVEs nennt), verwenden Sie die offiziellen Releases.

Schritt 3: neu starten und prüfen

Ein laufender Prozess behält die alte Laufzeit, bis er neu gestartet wird. Nach einem Paketupdate unter Linux listet dieser Befehl node-Prozesse auf, die noch die ersetzte Binärdatei ausführen:

sudo ls -l /proc/*/exe 2>/dev/null | grep -i 'node.*(deleted)'

Starten Sie diese Dienste neu (zum Beispiel mit systemctl restart, pm2 reload all oder einem neuen Deployment) und führen Sie die Befehle aus Schritt 1 erneut aus.

Wenn Sie heute nicht aktualisieren können

Nichts davon ersetzt das Update, aber es senkt das Risiko für einige Tage:

• Weisen Sie Brotli-Request-Bodys ab, bevor sie die Anwendung erreichen, zum Beispiel in NGINX mit if ($http_content_encoding ~* br) { return 415; } oder in einer Middleware, die vor den Body-Parsern läuft.
• Schalten Sie die automatische Dekompression für Anfragen an nicht vertrauenswürdige Server ab: decompress: false in axios und got, compress: false in node-fetch oder request() von undici, das nicht dekomprimiert. Das eingebaute fetch() lässt sich nicht abschalten.
• Führen Sie Abrufe von nutzerseitig angegebenen URLs in einem separaten Prozess mit möglichst wenigen Rechten aus.
• Weisen Sie Namen, die ein NUL-Zeichen enthalten, ab, bevor Sie externe Eingaben an dns.resolve übergeben.

Wenn Sie nicht sicher sind, welche Ihrer Dienste nicht vertrauenswürdige Daten dekodieren, oder Hilfe beim Aktualisieren eines Produktivsystems ohne Ausfallzeit brauchen, unterstützen Sie unsere Teams für sichere Software und Managed Security.