Publisert 12. november 2026. Node.js-prosjektet ga ut sikkerhetsoppdateringer 11. november for versjonsseriene 22.x, 24.x og 26.x. Oppdateringene retter flere feil i HTTP/2, TLS og HTTPS, blant annet sårbarheter som kan la uautentiserte klienter krasje enkelte servere eller lese data fra prosessminnet.
Hovedrisikoen er ikke at alle Node.js-applikasjoner automatisk kan angripes. Flere feil krever bestemte server-API-er eller callback-oppsett. Men dette er vanlige byggesteiner i tjenester som står på internett, og noen av sårbarhetene gjelder standard oppførsel i HTTP/2-servere. Finn alle runtime-miljøer som er i drift, oppdater dem og start prosessene på nytt.
Dette retter novemberoppdateringen
Node.js sitt sikkerhetsvarsel oppgir sju feil med høy alvorlighetsgrad, seks middels og tre lave. Oppdateringen dekker de tre støttede versjonsseriene. Flere av de alvorlige feilene handler om levetid og opprydding: En strøm, svarbuffer eller TLS-callback kan leve lenger enn ressursen den forventer å bruke.
En særlig alvorlig HTTPS-feil, CVE-2026-123864, skyldes en nullengdes TLS-skriving som kan starte HTTP-parseren på nytt mens den allerede behandler en forespørselskropp. I et bestemt applikasjonsoppsett kan dette føre til use-after-free og lesing utenfor minneområdet. Node.js opplyser at minne fra andre tilkoblinger – inkludert TLS-nøkler eller andre brukeres forespørsler – kan kopieres inn i en forespørselskropp. Feilen gjelder HTTPS, ikke klartekst-API-et `node:http`, og krever en handler som blant annet kaller `flushHeaders()` før forespørselskroppen er lest ferdig og senere skriver et ikke-tomt svar.
HTTP/2 får flere rettelser. Én feil kan avslutte en server når en uautentisert klient utløser en assert under avslutning av økten. En annen kan etterlate økter, minne og filbeskrivelser hengende etter en protokollfeil under nedstenging. En separat feil ved avslutning av strømmer kan sende frigjort svarminne til en motpart mens en skriving venter. En use-after-free ved filservering berører apper som bruker `respondWithFile()` eller `respondWithFD()` under bestemte avbrudd.
TLS-rettelsene er viktige for oppsett med mer avanserte regler. Oppdateringen lukker et problem ved TLS 1.2-renegotiering, der et klientsertifikat godkjent for ett vertsnavn kunne følge med til et annet navn med strengere krav. Andre rettelser dekker eksternt utløste TLS-serverkrasj og håndtering av sertifikatregler.
Hvilke versjoner bør installeres?
De tilsvarende sikkerhetsversjonene er Node.js 22.23.5, 24.22.3 og 26.13.1. Node.js-prosjektets sikkerhetsvarsel og versjonsnotater bør være fasiten for nøyaktig hvilke rettelser som ligger i hver serie; ikke alle feil gjelder alle tre. Utgivelsene oppdaterer også innebygde komponenter, blant annet llhttp, mens andre avhengigheter varierer mellom grenene.
Oppdater til nyeste rettede utgave i serien applikasjonen støtter. Sjekk containere, virtuelle maskiner, byggagenter, serverless-miljøer dere drifter og utviklermiljøer som håndterer produksjonsnøkler. En oppdatering av vertens pakke endrer ikke nødvendigvis et containerimage eller en separat pakket runtime.
Start Node.js-tjenester og arbeidere på nytt etter installasjonen. En prosess som allerede kjører, fortsetter med runtime-versjonen den lastet ved oppstart. Bygg og rull ut containerimages på nytt hvis de låser en eldre Node.js-versjon, og kontroller versjonen inne i arbeidslasten – ikke bare på verten eller i CI.
Slik vurderer team om de er berørt
Begynn med en oversikt over Node.js-versjoner og hvilke nettverkstjenester de kjører. Prioriter offentlige HTTP/2- og HTTPS-endepunkter, apper som serverer filer gjennom de berørte HTTP/2-API-ene, og TLS-servere som bruker SNI-, OCSP- eller sesjons-callbacks eller har ulike klientsertifikatregler per vertsnavn.
Se deretter etter forespørselsbehandlere som sender headere før de har lest hele forespørselskroppen, og som senere returnerer data, samt ruter som gjengir eller lagrer innsendte kropper. Dette hjelper med å avgjøre om minnelekkasjescenarioet er relevant. Det erstatter ikke oppdateringen: samme utgivelse inneholder flere uavhengige feil med andre forutsetninger.
Hvis tjenesten går gjennom en omvendt proxy, bekreft hvilken protokoll- og TLS-håndtering Node.js-prosessen faktisk gjør. En proxy kan avslutte TLS eller HTTP/2 på utsiden, men backend kan fortsatt nås via en annen rute eller et internt nettverk. Kontroller den reelle arkitekturen i stedet for å anta at inngangspunktet fjerner risikoen.
Hvis dere ikke kan oppdatere alt med én gang
Oppdateringene er den varige løsningen. Hvis utrullingen må skje trinnvis, begrens eksponeringen til berørte lyttere, bruk kompenserende kontroller i proxy eller nettverk der det passer, og følg med på uventede prosessavslutninger eller ressursvekst. Slike tiltak fjerner ikke nødvendigvis alle berørte kodebaner, særlig når applikasjonen selv kaller de aktuelle API-ene.
Gjør oppgraderingen til en prioritert vedlikeholdsoppgave, test den i den vanlige integrasjonssuiten og rull den raskt ut i produksjon. Ta også med mindre synlige systemer som planlagte jobber og interne API-er: De kan inneholde nøkler eller sensitive data selv om de ikke er åpne for internett.
En påminnelse om oppdatering av runtime
Denne utgivelsen viser at risiko ofte avhenger av kombinasjonen av runtime-versjon og applikasjonsoppførsel. En feil kan være irrelevant for en tjeneste som aldri bruker et bestemt API, men kritisk for en annen med en matchende handler eller protokollkonfigurasjon. En oversikt over avhengigheter gjør forskjellen synlig; påstander som «vi bruker ikke HTTP/2» eller «TLS avsluttes i lastbalansereren» bør bekreftes mot produksjonsløpet.
For utviklingsteam er rekkefølgen enkel: Finn alle Node.js-installasjoner i drift, oppdater til 22.23.5, 24.22.3 eller 26.13.1 etter behov, start arbeidslastene på nytt, bygg låste images på nytt og bekreft versjonen i produksjon. Undersøk deretter HTTP/2-, forespørselskropp- og TLS-oppsettene i sikkerhetsvarselet. Slik tetter dere kjente hull og får bedre oversikt over hvilke tjenester som bør følges tettest.
