Node.js-sikkerhetsoppdatering: får versjonen din fortsatt rettelser?

Sikkerhetsoppdateringer kom bare til de release lines som fortsatt har støtte, og trygge er 22.23.4, 24.22.1 og 26.12.1 eller nyere i samme release line; Node.js 18 og 20 har allerede nådd end of life, så denne Node.js-sikkerhetsoppdateringen gir dem ingen oppdatering nå og heller ingen senere, og hvis applikasjonen din kjører på en av dem, betyr en oppdatering å gå over til en annen line.

Onsdag 21. oktober ga Node.js-prosjektet ut sikkerhetsutgivelser for alle de tre release lines som fortsatt har støtte, og samme dag ga PHP ut akutte sikkerhetsoppdateringer for sårbarhetene som fikk navnet PHP2Shell, men det er to separate hendelser med ulik alvorlighet. Node.js-utgivelsen var varslet på forhånd, prosjektet har vurdert de alvorligste sårbarhetene som høye og ikke kritiske, og kunngjøringen nevner verken midlertidige løsninger eller angrep i virkelige miljøer, noe som ikke betyr at oppdateringen kan vente, men som flytter oppmerksomheten: denne gangen ligger den største risikoen ikke i selve utgivelsen, men i versjonene som ikke fikk den.

Hva som ble rettet i Node.js-sikkerhetsoppdateringen i oktober

I Node.js-kunngjøringen er ti sårbarheter listet: fire har prosjektet vurdert som høye, tre som middels og tre som lave, men prosjektet har ikke publisert noen CVSS-vurdering denne gangen, så denne artikkelen bruker den samme vurderingen.

Den alvorligste av dem er CVE-2026-111497, som prosjektet kaller et out-of-bounds write i Brotli-dekoderen, altså skriving utenfor grensene for det tildelte minnet, noe som gjør fjernkjøring av kode (RCE) mulig, og den er vurdert som høy. Brotli er et komprimeringsformat med en dekoder innebygd i Node.js, og i release notes er rettelsen beskrevet som en endring i dette innebygde biblioteket; kunngjøringen sier ikke hvilken vei sårbarheten kan nås, og Brotli-utviklernes beskrivelse av rettelsen sier bare at en ugyldig datastrøm nå gjenkjennes tidligere, så ingen konkrete funksjoner er nevnt her: det som trygt kan sies, er at feilen i dekoderen først og framst angår applikasjoner som dekomprimerer Brotli-data fra en kilde de ikke kan stole på.

Tre andre sårbarheter gjelder kontrollen av TLS-sertifikater, og de er ikke ett og samme tilfelle: den første, vurdert som høy, gjelder bare release line 26 og 24, der hostname verification kan omgås hvis en IP-adresse er skrevet med sifre i full bredde, for eksempel １２７.０.０.１; den andre, også høy, gjelder alle tre lines, der kontrollen kan omgås hvis et hostname kan leses løst som en IP-adresse; den tredje er middels og gjelder også alle tre lines, der en IPv4-notasjon som ikke følger standarden, lar DNS-navnet som står i sertifikatet, bekrefte en IP-adresse. I release notes er rettelsene formulert kort: IP-adresser med uvanlig notasjon avvises nå, og en regresjon i normaliseringen av IP-adresser er rettet for seg. I alle tre tilfellene handler det om øyeblikket der Node.js opptrer som klient, altså når den selv oppretter en kryptert tilkobling til en annen server, ikke om øyeblikket der den betjener sine egne besøkende.

Den fjerde sårbarheten med høy vurdering ligger i funksjonen dns.resolve, som kuttet navn som inneholder et nulltegn, og blant de middels alvorlige er en feil ved gjenbruk av HTTP-tilkoblinger, der et svar som var skrevet til tilkoblingen før forespørselen ble sendt, kunne bli behandlet som svaret på denne forespørselen, samt en feil som gjorde at hurtigbufferen for tilfeldige verdier i crypto.randomUUID() og randomInt() ble lagret i startup snapshots og i én kjørbar fil, slik at hver prosess gjentok de samme verdiene; tre sårbarheter med lav vurdering gjelder behandling av ZIP-filer og permission model i Node.js.

Feilen med hurtigbufferen for tilfeldige verdier er verdt å forstå nøyaktig, for i det vanlige tilfellet påvirker den ingenting, og den gjelder bare prosjekter som starter fra et selvlaget startup snapshot eller distribueres som én kjørbar fil (single executable application, SEA), der den betyr at hver prosess som startes fra den samme filen, fikk de samme «tilfeldige» verdiene. Hvis et slikt prosjekt laget identifikatorer eller midlertidige koder med crypto.randomUUID() eller randomInt(), kunne de gjentas mellom prosesser, så etter rettelsen lønner det seg å sjekke om noen av disse verdiene brukes et sted der de må være umulige å gjette.

Utgivelsen oppdaterer også flere innebygde avhengigheter, avhengig av line, nemlig c-ares, OpenSSL, SQLite og Undici, som den innebygde fetch bygger på, og CA store, listen over tiltrodde sertifiseringsinstanser, er også oppdatert i forbindelse med et kompromittert mellomliggende eMudhra-sertifikat, slik at TLS-tilkoblinger nå avviser kjeder som inneholder blokkerte offentlige nøkler.

Hvilke versjoner som er trygge

De rettede versjonene er tre, én for hver release line som fortsatt har støtte: 22.23.4, 24.22.1 og 26.12.1, og alt som er eldre i sin egen line, er berørt. Ikke alle de ti sårbarhetene gjelder alle lines: line 26 har alle ti, line 24 har åtte, og line 22 har sju, fordi to feil med lav vurdering finnes bare i den nyeste line og én TLS-feil ikke gjelder line 22.

Å oppdatere innenfor line er det minste mulige steget, og vanligvis også den tryggeste endringen du kan gjøre i et produksjonsmiljø, men også det kan endre oppførsel, og denne gangen finnes det et konkret eksempel: rettelsen i TLS-kontrollen avviser nå IP-adresser med uvanlig notasjon. Hvis en applikasjon tidligere brukte en slik notasjon i tilkoblinger til en annen server, kan tilkoblingen feile etter oppdateringen, og det er et rettet sikkerhetshull, ikke en ny feil, men det lønner seg å vite det før oppdateringen og ikke etterpå.

Release line er viktigere enn versjonsnummeret

Til og med Node.js 26 går hver hovedversjon gjennom én syklus: først er den den aktuelle versjonen (Current), deretter får partallsversjoner aktiv langtidsstøtte (Active LTS), så går de over i Maintenance LTS, der de bare får kritiske feilrettinger og sikkerhetsoppdateringer, og til slutt tar støtten slutt helt, mens oddetallsversjoner til og med line 25 ikke fikk langtidsstøtte. Fra Node.js 27 endres syklusen: ifølge utgivelsesplanen får hver release line langtidsstøtte, og i alle 30 månedene med støtte blir den værende i den aktive fasen, uten Maintenance LTS. Prosjektet skriver selv at produksjonsapplikasjoner bare skal bruke versjoner i Active LTS eller Maintenance LTS.

For de nåværende lines skjer de nærmeste faseskiftene på to datoer, og ifølge utgivelsesplanen gikk line 24 over i Maintenance LTS 20. oktober, dagen før sikkerhetsutgivelsen, mens line 26 får langtidsstøtte 28. oktober; line 22 har vært i Maintenance LTS siden 21. oktober 2025 og mister støtten 30. april 2027, mens line 24 mister den 30. april 2028.

Den praktiske betydningen er enkel: spørsmålet «har vi den nyeste versjonen» sier i seg selv ikke særlig mye, mens spørsmålet «hvilken release line er vi i, og til hvilken dato får den oppdateringer» er det nyttige, for det første spørsmålet skifter svar hver måned og det andre en gang hvert par år, og nettopp derfor er det andre lett å glemme.

Node.js 18 og 20: ingen sikkerhetsoppdatering

I kunngjøringen står en setning som denne gangen er viktigere enn alle de ti sårbarhetene: versjoner som har nådd end of life, er alltid berørt i en sikkerhetsutgivelse, og de får ingen oppdatering verken nå eller senere, fordi en line som har nådd end of life, ikke får noen flere utgivelser.

Ifølge utgivelsesplanen mistet line 16 støtten 11. september 2023, line 19 den 1. juni 2023, line 18 den 30. april 2025 og line 20 den 30. april 2026, og den siste datoen er den viktigste: line 20 mistet støtten for under seks måneder siden, og et prosjekt som ble startet på den, kan fortsatt kjøre uten noe synlig problem, noe som nettopp gjør situasjonen lumsk, for ingenting i hvordan den oppfører seg, viser at sikkerhetsoppdateringer ikke lenger gjelder den.

For bedrifter som ikke raskt kan gå over til en release line med støtte, nevner kunngjøringen én mulighet: kommersiell støtte for versjoner etter Maintenance LTS tilbys av partnerne i OpenJS Ecosystem Sustainability Program, og det er en betalt tjeneste og en midlertidig løsning, ikke en erstatning for den overgangen.

Slik sjekker du hvilken Node.js applikasjonen din bruker

Sjekken tar minutter, men det er ett sted der det er lett å gjøre den feil: Node.js-versjonen terminalen viser, er ikke alltid den samme som applikasjonen kjører med.

Webhotell med cPanel: versjonen som er i bruk, vises under Software → Setup Node.js App, der hver applikasjon har sin egen rad og versjonen velges fra en liste som bare inneholder de versjonene leverandøren har installert på serveren, og kommandoen node -v på et slikt webhotell kan vise en annen versjon enn denne innstillingen, så se på den aktuelle raden.

Egen server: kommandoen node -v viser den versjonen som ligger først i systemets PATH, men en prosesshåndterer, for eksempel PM2 eller en systemd-tjeneste, kan starte programmet med en helt annen kjørbar fil, og det påliteligste svaret er det prosessen selv rapporterer, nemlig verdien av process.version, for eksempel skrevet til loggen ved oppstart.

Containere: i et Docker-miljø er det container image som bestemmer versjonen, ikke vertsmaskinen, og et container image som er bygd før 21. oktober, inneholder ikke rettelsen uansett hvor mange ganger containeren er startet på nytt, så det må bygges på nytt med et oppdatert base image.

Hvis du ikke har tilgang: da stiller du spørsmålet til leverandøren eller til utvikleren som vedlikeholder det, og formuleringen som sparer en korrespondanse, er denne: «Hvilken Node.js-versjon bruker applikasjonen vår? Er den i sin egen release line minst 22.23.4, 24.22.1 eller 26.12.1? Hvis den er i en line uten støtte, for eksempel 18 eller 20, når er overgangen planlagt?»

Hva du gjør i dag

Rekkefølgen i dag er denne: først oppdaterer du Node.js til den rettede versjonen i din egen release line og starter hver prosess som bruker den, på nytt, deretter bygger du på nytt alt der runtime er innebygd, og først etter det planlegger du overgangen for prosjektene som kjører på lines uten støtte.

For det første oppdaterer du innenfor release line: til 22.23.4, 24.22.1 eller 26.12.1, alt etter hvilken line du er i, og hos en leverandør er det leverandøren som gjør det, mens jobben din er å forsikre deg om at applikasjonen bruker den oppdaterte versjonen.

For det andre starter du prosessene på nytt: en prosess som allerede kjører, fortsetter å bruke den Node.js den ble startet med, og det å bytte filen på disken påvirker den ikke, og det samme gjaldt PHP2Shell, der pakken er byttet ut mens den gamle prosessen fortsetter å kjøre med den gamle koden.

For det tredje bygger du på nytt det der runtime er innebygd: container images i Docker må bygges på nytt med et oppdatert base image, og hvis du distribuerer programmet som én kjørbar fil (single executable application, SEA), er selve Node.js innebygd i den, så det å oppdatere versjonen som er installert på systemet, påvirker den ikke, filen må bygges på nytt med den rettede versjonen, og det samme gjelder startup snapshots, som feilen med hurtigbufferen for tilfeldige verdier berører.

For det fjerde, hvis du er på line 18 eller 20, planlegger du overgangen: det er et større arbeid enn å oppdatere innenfor line, så det lønner seg å begynne nå, og rekkefølgen er beskrevet i neste avsnitt.

Slik går du fra Node.js 18 eller 20

Overgangen mellom hovedversjoner er ikke jobben til én kommando, og det lønner seg å gjøre den i rekkefølge, så først må målet velges, og i de fleste tilfellene er det line 24, som får oppdateringer til 30. april 2028; line 22 er et fornuftig valg bare hvis en viktig avhengighet ennå ikke støtter line 24, fordi støtten for line 22 tar slutt ett år tidligere.

Deretter må du finne alle stedene der prosjektet fastsetter sin Node.js-versjon, for det er nesten alltid flere: package.json-feltet engines, filene .nvmrc eller .node-version, base image i Dockerfile, konfigurasjonen for continuous integration (CI) og innstillingen i hostingpanelet, og bytter du bare noen av dem, kjører ulike versjoner i ulike miljøer, slik at feilene dukker opp der de er vanskeligst å finne.

Etterpå må prosjektet installeres på nytt i et testmiljø med den nye versjonen og testene kjøres, med særlig oppmerksomhet på pakker som inneholder kompilert kode, for de bygges for en bestemt Node.js-versjon, så etter overgangen kan de måtte bygges på nytt eller oppdateres. Node.js publiserer en endringsliste for hver hovedversjon, der endringer som kan ødelegge eksisterende kode, er markert for seg, og det lønner seg å lese den før overgangen og ikke etterpå.

Først da kommer produksjonsmiljøet, med bytte av versjon, omstart av prosessene og en sjekk av at process.version viser den nye versjonen, og den gamle versjonen kan bli værende tilgjengelig noen dager i tilfelle du må gå tilbake, men ikke lenger, for det er nettopp den versjonen som ikke får flere oppdateringer.

Hva som ikke oppdateres sammen med Node.js

Å oppdatere den retter selve runtime og bibliotekene som er innebygd i den, men ikke alt applikasjonen bruker, og det er nettopp her det oftest blir igjen hull som ingen ser.

Pakker installert for seg: hvis prosjektet bruker pakken undici fra npm i avhengighetene sine, og ikke den innebygde fetch, ligger denne pakken i prosjektets mappe node_modules, og Node.js-utgivelsen rører den ikke; det samme gjelder alle de andre avhengighetene, for det er pakkebehandleren som oppdaterer dem, og bare når noen kjører den.

CA store: som standard bruker ikke runtime operativsystemets liste over sertifiseringsinstanser, men sin egen innebygde, og dokumentasjonen sier at den er en kopi av Mozillas liste som låses ved utgivelsestidspunktet, så endringer som denne utgivelsens reaksjon på det kompromitterte mellomliggende eMudhra-sertifikatet får programmet bare sammen med oppdateringen av runtime, ikke sammen med operativsystemets oppdateringer, med mindre det er særskilt konfigurert til å bruke systemets liste.

Slik går du ikke glipp av neste utgivelse

Node.js varsler sikkerhetsutgivelser på forhånd på sikkerhetssiden sin, med planlagt utgivelsesdag, og denne gangen skjedde det nettopp slik, så denne onsdagen var ingen overraskelse for dem som følger med på siden: oppdateringen kunne planlegges på forhånd, i stedet for at man måtte finne tid samme dag.

I praksis betyr det at noen må være ansvarlig for denne oppfølgingen, og i administrert serverdrift gjør leverandøren det, mens det på en egen server eller i et prosjekt som teamet selv vedlikeholder, lønner seg å vite hvem som faktisk følger prosjektets kunngjøringer, hvem som bestemmer om oppdatering, og hvem som sjekker at alt virker etterpå; hvis svaret på disse spørsmålene er «ingen bestemt», er det nettopp der den største risikoen ligger, og ikke i en av de ti sårbarhetene.

Hvis Node.js bare er et build tool for deg

På mange Laravel- og WordPress-nettsteder kjører ikke Node.js på serveren i det hele tatt: det kjører Vite eller et lignende verktøy som lager CSS- og JavaScript-filer fra kildekoden og deretter stopper, og i et slikt tilfelle skiller situasjonen seg fra en applikasjon som selv betjener forespørsler, fordi byggeprosessen ikke svarer på forespørsler fra internett og ikke dekomprimerer data som ukjente besøkende sender til den.

At det skiller seg, betyr ikke at det er uviktig, for build tools kjører på utviklernes maskiner og i miljøet for continuous integration (CI), de laster ned pakker og oppretter tilkoblinger til andre servere, og beskrivelsene av sårbarhetene er for korte til at man trygt kan si hvilke av disse veiene som er berørt; det lønner seg å oppdatere Node.js også der, bare i riktig rekkefølge, først på serverne der den kjører i drift, deretter på utviklernes maskiner og i CI-miljøet.

Det finnes også en annen grunn, som ikke har med denne uken å gjøre: byggemiljøet blir ofte stående på den Node.js-versjonen prosjektet en gang ble startet med, og så nekter en ny versjon av et verktøy en dag rett og slett å jobbe med den, slik at overgangen til en release line med støtte da skjer i hast og på et dårlig tidspunkt, og derfor er den lettere å gjøre nå, mens den er planlagt arbeid.

Hva det betydde i serverdriften vår

Den administrerte serverdriften vår er plass på vår egen server, og hver klient velger versjon der gjennom hostingpanelet; på serveren vår kjører release line 22 og 24 i Node.js allerede med de rettede versjonene 22.23.4 og 24.22.1, og klienter som har prosjekter på disse lines, trenger ikke å gjøre noe, bortsett fra å forsikre seg om at prosessen er startet på nytt etter oppdateringen.

Den andre siden må også sies rett ut: på serveren er lines som har nådd end of life, fortsatt tilgjengelige å velge, og de har ingen oppdatering — verken på serveren vår eller på noen annen server, fordi Node.js ikke gir ut en slik oppdatering. Hvis prosjektet ditt har valgt en av dem, betyr en oppdatering å gå over til line 22 eller 24, og det gjøres best sammen med en sjekk av at alt etter overgangen virker som før.

Vår administrerte serverdrift starter fra 45 € i måneden, og runtimes som holdes oppdatert, er en del av det denne summen betaler for. Hvis applikasjonen din fortsatt kjører på Node.js 18 eller 20, tar vi en prat om overgangen, før dagen for en senere sikkerhetsutgivelse tvinger den fram.