Node.js: HTTP/2- og HTTPS-feil lar klienter krasje servere og lese andre brukeres data

Hva skjedde

Den 11. november 2026 publiserte Node.js-prosjektet sikkerhetsutgivelser for de tre aktive utgivelseslinjene. De rettede versjonene er 22.23.5, 24.22.3 og 26.13.1. De retter 16 sårbarheter i Node.js selv, og sju av dem er vurdert som høye. Utgivelsene oppdaterer også de medfølgende avhengighetene llhttp (22.x, 24.x, 26.x), undici (24.x, 26.x) og sqlite (22.x, 24.x).

De viktigste problemene ligger i serverkoden som Node.js selv tilbyr for HTTP/2, HTTPS og TLS:

• HTTP/2-serverkrasj (24.x og 26.x): en uautentisert klient kan få Node.js-prosessen til å stoppe. Serveren trenger bare standard HTTP/2-oppsett og en behandler som svarer før forespørselens innhold er mottatt fullt ut. Prosjektet kaller denne oppførselen typisk. Angrepet fungerer både over TLS og over ukryptert forbindelse.
• HTTP/2-minnelekkasje (alle tre linjene): en server kan sende deler av minnet sitt til en klient, inkludert svar beregnet for andre forbindelser. Fra og med 24.22.0 og 26.9.0 kan en klient utløse dette på egen hånd. I 22.x og eldre 24.x- og 26.x-versjoner kan det skje når serveren avslutter en strøm midt i et svar, for eksempel etter en tidsavbrudd for inaktivitet.
• HTTPS-minnelekkasje (alle tre linjene): ifølge prosjektet kan en uautentisert klient lese minne fra andre forbindelser, «inkludert TLS-private nøkler og andre brukeres forespørsler». Dette krever en behandler som kaller res.flushHeaders() før forespørselens innhold er avsluttet, og senere kaller res.end() med data. For å lese det lekkede minnet trenger angriperen i tillegg en rute som sender tilbake eller lagrer et forespørselsinnhold.
• HTTP/2-ressursutmattelse (alle tre linjene): en klient kan få en standard HTTP/2-server til å holde på minne og filbeskrivere permanent.
• HTTP/2-filservering (24.x og 26.x): en klient kan ødelegge serverminne når serveren leverer filer med stream.respondWithFile() eller stream.respondWithFD(). På alle tre linjene kan avbrudd av slike nedlastinger også krasje serveren (vurdert som middels).
• TLS-serverkrasj (24.x og 26.x): en klient kan krasje en TLS-server som bruker SNICallback, OCSPRequest, newSession eller resumeSession, eller server.addContext().
• Omgåelse av klientsertifikat i TLS (alle tre linjene): noen servere bruker strengere regler for klientsertifikater på enkelte vertsnavn. På slike servere kan en klient som er godkjent for et annet vertsnavn bytte til et strengere vertsnavn under TLS 1.2-renegosiering, uten å oppfylle reglene for det.

Rapporten melder om ingen angrep som utnytter disse feilene.

Hvem er berørt

• Servere som kjører Node.js 22.x før 22.23.5, 24.x før 24.22.3 eller 26.x før 26.13.1.
• Utgåtte linjer, inkludert 20.x og 25.x, får ingen rettelse i denne utgivelsen. Prosjektet sier at slike versjoner alltid er berørt.
• De alvorlige serverproblemene gjelder bare der en Node.js-prosess selv tar imot HTTP/2-, HTTPS- eller TLS-forbindelser. Eksempler er de innebygde modulene node:http2, node:https eller node:tls, eller rammeverk som bruker dem til å avslutte TLS eller HTTP/2.
• Vanlige HTTP-servere bygget med node:http er ikke berørt av HTTPS-minnelekkasjen.
• HTTP/2-krasjen gjelder bare linjene 24.x og 26.x, ikke 22.x.

Du er mye mindre utsatt hvis en reverse proxy som nginx, Apache, HAProxy eller en lastbalanserer avslutter TLS og HTTP/2, og Node.js bare mottar vanlig HTTP/1.1 fra den. Du bør likevel oppdatere, fordi utgivelsen også inneholder andre rettelser og avhengighetsoppdateringer.

Hva du bør gjøre nå

1. Finn alle Node.js-installasjoner. Husk systempakker, versjonsbehandlere (nvm, n, Volta), Docker-images, CI-kjørere og hostingpanel som leveres med egen Node.js.
2. Oppdater til den rettede versjonen i din linje: 22.23.5, 24.22.3 eller 26.13.1. Hvis du bruker pakker fra distribusjon eller leverandør (for eksempel NodeSource eller Linux-distribusjonen din), installer oppdateringen så snart pakkekilden har disse versjonene.
3. Gå bort fra utgåtte versjoner. Hvis du fortsatt kjører 20.x, 25.x eller eldre, oppgrader til en linje som fortsatt får støtte. Rapporten lister ingen omgåelse for servere som ikke kan oppdateres.
4. Bygg containerimages på nytt med et oppdatert Node.js-basisimage, og rull dem ut igjen. Oppdatering av verten alene endrer ikke Node.js inne i containerne.
5. Start alle Node.js-prosesser på nytt (systemd-enheter, PM2, Docker-containere osv.) slik at den nye runtime-versjonen lastes. Kontroller deretter at applikasjonene dine svarer normalt.
6. Vurder å rotere hemmeligheter hvis du var eksponert. Rapporten sier ikke om servere som oppfylte vilkårene for HTTPS-minnelekkasjen bør bytte TLS-nøkler eller andre hemmeligheter. Hvis en av dine Node.js-HTTPS-servere oppfylte disse vilkårene og var tilgjengelig fra internett, bør du vurdere å fornye TLS-sertifikatet og nøkkelen.

Slik sjekker du om du er berørt

• Kjør node -v på hver server, og inne i hver container (docker exec <container> node -v). Versjoner under 22.23.5, 24.22.3 eller 26.13.1 i sin linje, eller en utgått linje som 20.x eller 25.x, er berørt.
• Med PM2 viser pm2 list og pm2 show <app> hvilken Node.js-binær og versjon hver app bruker.
• Sjekk om applikasjonene dine avslutter HTTP/2 eller TLS i Node.js selv: søk i koden etter http2.createSecureServer, http2.createServer, https.createServer, tls.createServer, respondWithFile, respondWithFD, SNICallback og addContext.
• Sjekk prosesshåndtereren og systemloggene for uventede omstarter eller krasj i Node.js. Gjentatte avbrudd i en HTTP/2-server kan tyde på forsøk på å utløse krasjen.

Kilder

• https://thehackernews.com/2026/11/nodejs-fixes-16-flaws-including-http2.html