Node.js schließt elf Sicherheitslücken, drei davon hoch bewertet

Das Node.js-Projekt hat am 29. Juli 2026 koordinierte Sicherheitsupdates veröffentlicht. Die neuen Versionen 26.5.1, 24.18.1 und 22.23.2 beheben elf Schwachstellen, drei davon mit der Einstufung hoch. Betroffen sind alle aktiven Release-Linien, also 26.x, 24.x und 22.x.

Die drei hoch bewerteten Lücken

Zwei der schwerwiegenden Befunde stecken in der HTTP/2-Verarbeitung. Im ersten Fall können zurückgehaltene Header-Blöcke die Begrenzung durch maxSessionMemory umgehen und den Speicher eines Servers aus der Ferne erschöpfen (CVE-2026-56846, betrifft 24.x und 22.x). Im zweiten Fall lässt sich eine Sendefunktion erneut aufrufen, während die Empfangsfunktion noch läuft. Das Ergebnis ist ein Zugriff auf bereits freigegebenen Speicher, ein sogenannter heap-use-after-free (CVE-2026-56848).

Der dritte Befund betrifft das Permission-Model, also die Funktion, mit der sich einem Node-Prozess über --permission gezielt Rechte am Dateisystem zuweisen lassen. Die Pfadprüfung arbeitet mit einem Präfixbaum, und genau dort war sie zu großzügig: Wer Zugriff auf einen Pfad erhält, konnte über die Präfixgrenzen hinaus auch auf andere Verzeichnisse zugreifen (CVE-2026-58043).

Diese Schwachstelle betrifft alle Nutzer der aktiven Release-Linien 26.x, 24.x und 22.x.

Diese Formulierung wiederholt sich in der Mitteilung bei fast jedem Punkt. Eine Einschränkung auf bestimmte Konfigurationen gibt es also in den meisten Fällen nicht.

Fünf mittlere und drei niedrige Befunde

Bei den mittel eingestuften Lücken fällt der HTTPS-Agent zweimal auf. Einmal können sich beim Wiederverwenden von Verbindungen mTLS-Client-Identitäten über verschiedene PFX-Zertifikate hinweg vermischen (CVE-2026-56850). Zum anderen kann die Wiederverwendung einer TLS-Sitzung die Prüfung des Hostnamens überspringen (CVE-2026-58040). Bemerkenswert daran: Das Projekt beschreibt diesen Punkt ausdrücklich als unvollständigen Fix einer früheren Schwachstelle.

Dazu kommen drei Fälle, in denen sich Prozesse zum Absturz bringen lassen: dns.resolveAny() bricht ab, wenn eine DNS-Antwort mehr als 256 A-Records enthält (CVE-2026-58042), und die synchronen node:zlib-Funktionen stürzen bei einer gefälschten Längenangabe eines TypedArray ab (CVE-2026-58045). Beides lässt sich wiederholt auslösen und damit als Denial of Service nutzen. In node:sqlite kann ein veralteter Iterator ein zwischengespeichertes Statement erneut ausführen, auch nachdem es zurückgesetzt wurde (CVE-2026-58041, nur 26.x und 24.x).

Die drei niedrig bewerteten Punkte betreffen wieder das Permission-Model, das Schreibzugriffe über Trace-Events und über process.report außerhalb der erlaubten Pfade zuließ, sowie den HTTP-Parser: Abgeschnittene Header können bei Node-basierten Weiterleitungs-Proxys Request Smuggling ermöglichen (CVE-2026-58044).

Zwei Verschiebungen vor der Freigabe

Der Termin verschob sich zweimal. Ursprünglich war die Veröffentlichung für den 27. Juli geplant, dann nannte das Projekt zusätzlichen Testbedarf und verschob auf den 28. Juli. Am 28. Juli folgte die zweite Verschiebung, diesmal wegen Problemen mit der Infrastruktur. Freigegeben wurde schließlich am 29. Juli.

Für Betreiber ist das mehr als eine Randnotiz: Zwischen der Vorankündigung, die den Schweregrad hoch bereits nannte, und den fertigen Paketen lagen mehrere Tage, in denen bekannt war, dass es etwas Gewichtiges gibt, aber noch kein Patch existierte.

Auch die Abhängigkeiten wurden gehoben

Mit den Updates aktualisiert Node.js zwei Bibliotheken, die tief im Netzwerkstack sitzen: den HTTP-Client undici auf 8.9.0, 7.29.0 beziehungsweise 6.28.0 je nach Linie und den HTTP-Parser llhttp auf 9.4.3. Angaben dazu, ob eine der Lücken bereits ausgenutzt wurde, macht die Mitteilung nicht. Workarounds für einzelne Punkte nennt sie ebenfalls nicht, der Weg ist also das Update.

Was das für Ihr Unternehmen heißt

• Version prüfen, nicht schätzen. Betroffen sind alle aktiven Linien. Ein node -v auf dem ServerHostingDer Speicherplatz auf einem Server, auf dem Ihre Website läuft.Im Glossar ansehen →, im Container-Image und in der Build-Umgebung klärt in Sekunden, ob Handlungsbedarf besteht.
• An die unauffälligen Stellen denken. Node steckt nicht nur im Web-Backend, sondern auch in Build-Ketten, Bildverarbeitung, Cronjobs und zunehmend in KI-Werkzeugen und MCP-Servern. Diese Installationen werden bei Updates häufig übersehen.
• HTTP/2 einordnen. Wer HTTP/2 an einem vorgeschalteten Webserver terminiert und intern per HTTP/1.1 weiterleitet, ist bei zwei der drei hohen Befunde weniger exponiert. Das ist eine Entschärfung, kein Ersatz für das Update.
• Container neu bauen. Ein Update auf dem Host hilft nicht, wenn das Image weiterhin eine alte Node-Version mitbringt. Basis-Images gehören mit in den Patch-Vorgang.
• Wartungsfenster einplanen. Node-Updates innerhalb derselben Hauptversion sind unkritisch, brauchen aber einen Neustart des Dienstes. Wer keinen festen Zeitraum dafür hat, verschiebt solche Aufgaben erfahrungsgemäß so lange, bis sie dringend werden.