Node.js: HTTP/2- och HTTPS-brister gör att klienter kan krascha servrar och läsa andra användares data

Vad hände

Den 11 november 2026 publicerade Node.js-projektet säkerhetsversioner för sina tre aktiva versionsserier. De rättade versionerna är 22.23.5, 24.22.3 och 26.13.1. De åtgärdar 16 sårbarheter i Node.js självt, och sju av dem är klassade som höga. Versionerna uppdaterar också de medföljande beroendena llhttp (22.x, 24.x, 26.x), undici (24.x, 26.x) och sqlite (22.x, 24.x).

De viktigaste problemen finns i serverkoden som Node.js själv tillhandahåller för HTTP/2, HTTPS och TLS:

• HTTP/2-serverkrasch (24.x och 26.x): vilken oautentiserad klient som helst kan få Node.js-processen att stanna. Servern behöver bara standardinställningen för HTTP/2 och en hanterare som svarar innan requestkroppen har kommit fram helt. Projektet beskriver beteendet som typiskt. Attacken fungerar både över TLS och över okrypterade anslutningar.
• HTTP/2-minnesläcka (alla tre serierna): en server kan skicka delar av sitt minne till en klient, inklusive svar avsedda för andra anslutningar. Från 24.22.0 och 26.9.0 och framåt kan en klient utlösa detta på egen hand. I 22.x och äldre 24.x- och 26.x-versioner kan det ske när servern avslutar en ström mitt i ett svar, till exempel efter en timeout för inaktivitet.
• HTTPS-minnesläcka (alla tre serierna): en oautentiserad klient kan läsa minne från andra anslutningar, ”inklusive TLS-privata nycklar och andra användares förfrågningar”, enligt projektet. Detta kräver en hanterare som anropar res.flushHeaders() innan requestkroppen har tagits emot klart och senare anropar res.end() med data. För att läsa det läckta minnet behöver angriparen också en rutt som skickar tillbaka eller lagrar en requestkropp.
• HTTP/2-resursutmattning (alla tre serierna): en klient kan få vilken HTTP/2-server som helst med standardinställningar att permanent hålla på minne och filbeskrivare.
• HTTP/2-filservering (24.x och 26.x): en klient kan korrumpera serverns minne när servern levererar filer med stream.respondWithFile() eller stream.respondWithFD(). På alla tre serierna kan avbrutna nedladdningar av sådana filer dessutom krascha servern (klassad som medium).
• TLS-serverkrasch (24.x och 26.x): en klient kan krascha en TLS-server som använder hookarna SNICallback, OCSPRequest, newSession eller resumeSession, eller server.addContext().
• Förbikoppling av klientcertifikat i TLS (alla tre serierna): vissa servrar tillämpar strängare regler för klientcertifikat på vissa värdnamn. På sådana servrar kan en klient som godkänts för ett annat värdnamn byta till ett striktare sådant under TLS 1.2-omförhandling utan att uppfylla dess regler.

Rapporten anger inga attacker som utnyttjar dessa brister.

Vem som påverkas

• Servrar som kör Node.js 22.x före 22.23.5, 24.x före 24.22.3 eller 26.x före 26.13.1.
• Versionsserier som har nått slutet av supporten, inklusive 20.x och 25.x, får ingen rättning i den här utgåvan. Projektet säger att sådana versioner alltid är påverkade.
• De allvarliga problemen på serversidan spelar bara roll där en Node.js-process själv tar emot HTTP/2-, HTTPS- eller TLS-anslutningar. Exempel är de inbyggda modulerna node:http2, node:https eller node:tls, eller ramverk som använder dem för att avsluta TLS eller HTTP/2.
• Vanliga HTTP-servrar byggda med node:http påverkas inte av HTTPS-minnesläckan.
• HTTP/2-kraschen påverkar bara 24.x- och 26.x-serierna, inte 22.x.

Du är betydligt mindre utsatt om en omvänd proxy som nginx, Apache, HAProxy eller en lastbalanserare avslutar TLS och HTTP/2, och Node.js bara tar emot vanlig HTTP/1.1 från den. Du bör ändå uppdatera, eftersom utgåvan även innehåller andra rättningar och beroendeuppdateringar.

Vad du bör göra nu

1. Hitta alla Node.js-installationer. Tänk på systempaket, versionshanterare (nvm, n, Volta), Docker-avbildningar, CI-runners och hostingpaneler som levererar egen Node.js.
2. Uppdatera till den rättade versionen i din serie: 22.23.5, 24.22.3 eller 26.13.1. Om du använder distributions- eller leverantörspaket (till exempel NodeSource eller din Linux-distribution) installerar du uppdateringen så snart din paketkälla har de versionerna.
3. Flytta bort från versioner som inte längre supportas. Om du fortfarande kör 20.x, 25.x eller äldre, uppgradera till en aktiv serie. Rapporten listar ingen workaround för servrar som inte kan uppdateras.
4. Bygg om containeravbildningar med en uppdaterad Node.js-basavbildning och driftsätt dem igen. Att bara uppdatera värden ändrar inte Node.js inuti containrar.
5. Starta om alla Node.js-processer (systemd-enheter, PM2, Docker-containrar osv.) så att den nya runtimen laddas. Kontrollera sedan att dina applikationer svarar normalt.
6. Överväg att byta hemligheter om du kan ha exponerats. Rapporten säger inte om servrar som uppfyllde villkoren för HTTPS-minnesläckan bör byta TLS-nycklar eller andra hemligheter. Om en av dina Node.js-HTTPS-servrar uppfyllde villkoren och var nåbar från internet, överväg att förnya dess TLS-certifikat och nyckel.

Så kontrollerar du om du påverkas

• Kör node -v på varje server och inne i varje container (docker exec <container> node -v). Versioner under 22.23.5, 24.22.3 eller 26.13.1 i sin serie, eller någon versionsserie som har nått slutet av supporten, till exempel 20.x eller 25.x, är påverkade.
• Med PM2 visar pm2 list och pm2 show <app> vilken Node.js-binär och version varje app använder.
• Kontrollera om dina applikationer avslutar HTTP/2 eller TLS i Node.js själva: sök i koden efter http2.createSecureServer, http2.createServer, https.createServer, tls.createServer, respondWithFile, respondWithFD, SNICallback och addContext.
• Kontrollera din processhanterare och systemloggar för oväntade omstarter eller krascher i Node.js. Upprepade avbrott i en HTTP/2-server kan tyda på försök att utlösa kraschen.

Källor

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