Das Node.js-Projekt hat am 11. November 2026 Sicherheitsupdates für alle drei aktiven Versionszweige veröffentlicht: 22.x, 24.x und 26.x. Sechzehn Schwachstellen wurden geschlossen, neun davon mit hohem Schweregrad, die meisten im HTTP/2-Modul und in der TLS-Schicht. Für jeden Server, der nicht authentifizierten Clients ausgesetzt ist, wird ein umgehendes Update auf 22.23.5, 24.22.3 oder 26.13.1 empfohlen.
Sechzehn Korrekturen, ein ungewöhnlich großes Paket
Das Release verteilt sich auf drei Schweregrade: neun hoch, sechs mittel, eine niedrig. Mehrere ermöglichen Denial-of-Service- oder Speicherlecks aus der Ferne, ganz ohne vorherige Authentifizierung. Zwei davon sind Varianten oder unvollständige Korrekturen bereits früher behobener Fehler, ein Hinweis darauf, wie schwer bestimmte Fehlerklassen in der HTTP/2-Implementierung der Laufzeitumgebung dauerhaft zu schließen sind, kaum einen Monat nachdem Node.js 26 unter dem Namen Lithium in den Long-Term-Support gewechselt ist.
HTTP/2 und TLS als Schwerpunkte
Sieben der sechzehn Korrekturen betreffen direkt das HTTP/2-Modul: Use-after-free beim Abbau eines Streams, ein Ein-Byte-Pufferüberlauf in session.altsvc(), oder Sitzungen, die nach einem Protokollfehler ohne korrekte Bereinigung in CLOSE_WAIT hängen bleiben. Auf TLS-Seite kann ein reentranter Aufruf von llhttp_execute(), ausgelöst durch einen Null-Byte-Schreibvorgang, zu Use-after-free führen und Inhalte laufender Anfragen offenlegen. Eine weitere Lücke erlaubt es einem Client, während einer TLS-1.2-Neuverhandlung den Servernamen zu ändern und so hostbezogene Client-Zertifikatsrichtlinien zu umgehen.
| CVE | Schweregrad | Komponente | Betroffene Zweige |
|---|---|---|---|
| CVE-2026-123864 | Hoch | HTTPS / llhttp | 22.x, 24.x, 26.x |
| CVE-2026-123866 | Hoch | HTTP/2 | 22.x, 24.x, 26.x |
| CVE-2026-123872 | Hoch | TLS | 22.x, 24.x, 26.x |
| CVE-2026-126051 | Hoch | TLS | 24.x, 26.x |
| CVE-2026-123871 | Mittel | Proxy | 22.x, 24.x, 26.x |
| CVE-2026-106071 | Niedrig | Permission Model | 22.x, 24.x, 26.x |
Das Permission Model ließ zu weit gefasste Platzhalter durch
CVE-2026-106071 betrifft Anwendungen, die mit dem experimentellen Permission Model gestartet werden. Eine scheinbar restriktive Regel kann in Wirklichkeit deutlich mehr erlauben als beabsichtigt:
# Sollte nur Dateien /etc/passwd. erfassen,
# erlaubt aber auch das Lesen von /etc/passwd selbst
node --permission --allow-fs-read=/etc/passwd.* app.js
Die Korrektur verschärft die Interpretation von Platzhaltermustern für --allow-fs-read und --allow-fs-write. Teams, die sich bei der Prozessisolation auf dieses Modell verlassen, sollten ihre bestehenden Regeln nach dem Update erneut prüfen.
Neun der sechzehn behobenen Schwachstellen tragen den höchsten Schweregrad, den Node.js außerhalb einer kritischen Lücke vergibt, ein ungewöhnlich hoher Anteil für ein einzelnes Sicherheitsupdate.
Das Update nach tatsächlicher Angriffsfläche priorisieren
Nicht jede Korrektur wiegt je nach eingesetzter Architektur gleich schwer. Die HTTP/2-Probleme betreffen vor allem Server, die dieses Protokoll von nicht vertrauenswürdigen Clients akzeptieren. Die Lücken rund um respondWithFile() betreffen nur Anwendungen, die Dateien auf diesem Weg ausliefern. Das zlib-Problem tritt nur auf, wenn deflate.params() mitten im Datenstrom aufgerufen wird. Das Node.js-Team empfiehlt, je nach genutztem Zweig vorrangig auf 22.23.5, 24.22.3 oder 26.13.1 zu aktualisieren und anschließend die Abhängigkeiten llhttp und undici zu prüfen, die in diesem Paket ebenfalls aktualisiert wurden.
Was bleibt festzuhalten
Sechzehn Schwachstellen in den Node.js-Zweigen 22.x, 24.x und 26.x wurden behoben, neun davon mit hohem Schweregrad und konzentriert auf HTTP/2 und TLS. Das Update auf 22.23.5, 24.22.3 oder 26.13.1 sollte für jeden Dienst mit Kontakt zu nicht authentifizierten Clients Priorität haben, und Teams, die das Permission Model nutzen, sollten ihre Dateifilterregeln erneut prüfen.
Die Zahl der HTTP/2-bezogenen Lücken in diesem Paket ist kein Zufall: Mehrere sind Varianten bereits gemeldeter Fehler, was einiges über die Komplexität dieser Implementierung aussagt. Auf meiner eigenen Infrastruktur setze ich Node.js lieber nicht direkt dem Internet aus, sondern stelle einen Reverse-Proxy davor, der HTTP/2 terminiert und intern nur HTTP/1.1 weiterreicht, eine Schicht Einfachheit, die die Angriffsfläche mechanisch verkleinert, solange diese aufeinanderfolgenden Patches das Modul noch nicht wirklich stabilisiert haben. — Simon Janvier
Zum Weiterlesen: die vollständige Aufschlüsselung aller sechzehn Schwachstellen ist im offiziellen Sicherheitsblog von Node.js veröffentlicht.
