Node.js-säkerhetsuppdatering: får din version fortfarande säkerhetsuppdateringar?

Bara de release lines som fortfarande har stöd fick säkerhetsuppdateringar, och säkra är versionerna 22.23.4, 24.22.1 och 26.12.1 eller nyare på samma release line. Node.js 18 och 20 har redan nått end of life, så i den här Node.js-säkerhetsuppdateringen finns ingen säkerhetsuppdatering för dem och det kommer inte heller att finnas någon: Om din applikation körs på någon av dem betyder en uppdatering att du går över till en annan release line.

Onsdagen den 21 oktober släppte Node.js-projektet säkerhetsreleaser för alla tre release lines som har stöd, och samma dag släppte PHP akuta säkerhetsuppdateringar för sårbarheter som fick namnet PHP2Shell, men det är två åtskilda händelser med olika allvar. Node.js-säkerhetsreleasen hade aviserats i förväg, projektets allvarligaste sårbarheter är bedömda som höga och inte kritiska, och meddelandet nämner varken tillfälliga lösningar eller angrepp i verkligheten. Det gör inte att uppdateringen kan skjutas upp, men det flyttar uppmärksamheten: Den här gången sitter den största risken inte i själva säkerhetsreleasen, utan i de versioner som inte fick den.

Vad oktobers Node.js-säkerhetsuppdatering åtgärdade

I Node.js-meddelandet räknas tio sårbarheter upp: Fyra har projektet bedömt som höga, tre som medel och tre som låga, men projektet har den här gången inte publicerat några CVSS-klassningar, så den här artikeln använder samma bedömning.

Den allvarligaste av dem är CVE-2026-111497. Projektet kallar den en out-of-bounds write i Brotli-avkodaren, en skrivning utanför det tilldelade minnets gränser, som gör fjärrkörning av kod (RCE) möjlig, och bedömer den som hög. Brotli är ett komprimeringsformat vars avkodare är inbyggd i Node.js, och i release notes beskrivs säkerhetsuppdateringen som en ändring i det inbyggda biblioteket. Meddelandet säger inte längs vilken väg sårbarheten kan nås, och Brotli-utvecklarnas beskrivning av ändringen talar bara om att en ogiltig dataström nu upptäcks tidigare. Därför nämns inga bestämda funktioner här: Det enda som går att säga med säkerhet är att felet i avkodaren berör mest de applikationer som dekomprimerar Brotli-data från en källa de inte kan lita på.

Tre andra sårbarheter berör kontrollen av TLS-certifikat, och de är inte ett och samma fall. Den första, med hög bedömning, berör bara release line 26 och 24: Hostname verification kan kringgås om IP-adressen är skriven med siffror i full bredd, till exempel １２７.０.０.１. Den andra, också hög, berör alla tre release lines: Kontrollen kan kringgås om hostname kan läsas löst som en IP-adress. Den tredje är medel och berör också alla tre release lines: En icke-standardiserad IPv4-notation låter ett DNS-namn som anges i certifikatet intyga en IP-adress. I release notes formuleras ändringarna kort: IP-adresser skrivna i en ovanlig form avvisas nu, och en regression i normaliseringen av IP-adresser är rättad för sig. I alla tre fallen handlar det om ögonblicket då Node.js arbetar som klient, det vill säga då det själv öppnar en krypterad anslutning till en annan server, inte om ögonblicket då det betjänar sina egna besökare.

Den fjärde sårbarheten med hög bedömning sitter i funktionen dns.resolve, som kortade av namn som innehåller ett nulltecken. Bland dem som bedömts som medel finns ett fel i återanvändningen av HTTP-anslutningar, där ett svar som skrevs på anslutningen innan förfrågan skickades kunde behandlas som svaret på den förfrågan, och ett fel som gjorde att cachen för slumpvärden i crypto.randomUUID() och randomInt() sparades i startup snapshots och i en enda körbar fil, så att varje process upprepade samma värden. Tre sårbarheter med låg bedömning berör hanteringen av ZIP-filer och Node.js permission model.

Felet med cachen för slumpvärden är värt att förstå mer exakt, eftersom det i det vanliga fallet inte påverkar någonting. Det gäller bara projekt som startar från en startup snapshot de själva har byggt, eller som distribueras som en enda körbar fil (single executable application, SEA), och där betyder det att varje process som startades från samma fil fick samma ”slumpmässiga” värden. Om ett sådant projekt byggde identifierare eller tillfälliga koder med crypto.randomUUID() eller randomInt() kunde de upprepas mellan processer, så efter säkerhetsuppdateringen är det värt att kontrollera om något av de värdena används där det måste vara omöjligt att gissa.

Säkerhetsreleasen uppdaterar också flera inbyggda beroenden, beroende på release line, c-ares, OpenSSL, SQLite och Undici, som den inbyggda funktionen fetch vilar på. CA store, listan över betrodda certifikatutfärdare, är också uppdaterad med anledning av ett komprometterat eMudhra-mellancertifikat, och TLS-anslutningar avvisar nu kedjor som innehåller blockerade publika nycklar.

Vilka versioner som är säkra

De rättade versionerna är tre, en för varje release line som har stöd: 22.23.4, 24.22.1 och 26.12.1. Allt som är äldre på sin egen line är berört. Inte alla tio sårbarheter berör alla tre: Line 26 har alla tio, line 24 har åtta och line 22 har sju, eftersom två fel med låg bedömning bara finns på den nyaste line och ett TLS-fel inte berör line 22.

Att uppdatera inom release line är det minsta steg som går att ta, och vanligtvis också den säkraste ändring som går att göra i produktionsmiljö. Även det steget kan ändra beteendet, och den här gången finns ett konkret exempel: Säkerhetsuppdateringen av TLS-kontrollen avvisar nu IP-adresser skrivna i en ovanlig form. Om en applikation en gång använde en sådan form i anslutningar till en annan server kan anslutningen misslyckas efter uppdateringen. Det är ett åtgärdat säkerhetshål, inte ett nytt fel, men det är värt att veta före uppdateringen och inte efter den.

Release line är viktigare än versionsnumret

Fram till och med Node.js 26 går varje huvudversion genom en och samma cykel: Först är den den aktuella versionen (Current), sedan får versioner med jämnt nummer aktiv långtidssupport (Active LTS), därefter går de över i fasen Maintenance LTS, där de bara får kritiska felrättningar och säkerhetsuppdateringar, och till sist tar stödet slut helt, medan versioner med udda nummer till och med line 25 inte fick någon långtidssupport. Från Node.js 27 ändras cykeln: Enligt releaseschemat får varje release line långtidssupport, och under alla 30 månader som stödet varar stannar den i den aktiva fasen, utan någon Maintenance LTS-fas. Projektet skriver själv att produktionsapplikationer bara ska använda versioner med långtidssupport i fasen Active LTS eller Maintenance LTS.

För de release lines som används nu faller de närmaste fasbytena på två datum. Enligt Node.js-releaseschemat gick release line 24 över i fasen Maintenance LTS den 20 oktober, dagen före säkerhetsreleasen, och line 26 får långtidssupport den 28 oktober. Line 22 har varit i fasen Maintenance LTS sedan den 21 oktober 2025 och når end of life den 30 april 2027, medan line 24 når end of life den 30 april 2028.

Den praktiska innebörden är enkel: Frågan ”har vi den senaste versionen” säger i sig inte särskilt mycket, men frågan ”vilken release line ligger vi på, och fram till vilket datum får den säkerhetsuppdateringar” är den som är till nytta. Den första frågan byter svar varje månad, den andra en gång med ett par års mellanrum, och just därför är den andra lätt att glömma.

Node.js 18 och 20: det blir ingen säkerhetsuppdatering

I Node.js-meddelandet finns en mening som den här gången är viktigare än alla tio sårbarheter: Versioner som har nått end of life är alltid berörda när en säkerhetsrelease sker, och ingen säkerhetsuppdatering släpps för dem, varken nu eller senare, eftersom en release line som har nått end of life inte längre får någon release alls.

Enligt releaseschemat nådde release line 16 end of life den 11 september 2023, line 19 den 1 juni 2023, line 18 den 30 april 2025 och line 20 den 30 april 2026. Det sista datumet är det viktigaste: Line 20 nådde end of life för knappt sex månader sedan, och ett projekt som startades på den kan fortfarande fungera utan något synligt problem. Just det gör läget förrädiskt, eftersom ingenting i hur det arbetar visar att säkerhetsuppdateringar inte längre hör till det.

För företag som inte snabbt kan gå över till en release line som har stöd nämner Node.js-meddelandet en möjlighet: Kommersiellt stöd för versioner efter fasen Maintenance LTS erbjuds av partnerna i OpenJS Ecosystem Sustainability Program. Det är en betaltjänst, och det är en tillfällig lösning, inte en ersättning för övergången.

Hur du kontrollerar vilken Node.js din applikation använder

Kontrollen tar minuter, men det finns ett ställe där det är lätt att göra fel: Den Node.js-version som terminalen visar är inte alltid densamma som applikationen arbetar med.

Webbhotell med cPanel: Den version som används visas i avsnittet Software → Setup Node.js App, där varje applikation har en egen rad och versionen väljs ur en lista. Listan innehåller bara de versioner som hostingleverantören har installerat på servern, och kommandot node -v på ett sådant webbhotell kan visa en annan version än den här inställningen, så titta på just den raden.

En egen server: Kommandot node -v visar den version som kommer först i systemsökvägen, men en processhanterare, till exempel PM2 eller en systemd-tjänst, kan starta programmet med en helt annan körbar fil. Det svar som går att lita på är det som processen själv rapporterar om sig: värdet av process.version, till exempel skrivet i loggen vid starten.

Containrar: I en Docker-miljö bestäms versionen av containeravbildningen, inte av värddatorn. En containeravbildning som byggdes före den 21 oktober innehåller inte säkerhetsuppdateringen, oavsett hur många gånger containern har startats om, så containeravbildningen måste byggas om från en uppdaterad basavbildning.

Om du inte har åtkomst: Då går frågan till hostingleverantören eller till utvecklaren som sköter applikationen. En formulering som sparar en brevväxling: ”Vilken Node.js-version använder vår applikation? Är den, på sin egen release line, minst 22.23.4, 24.22.1 eller 26.12.1? Om den ligger på en line som har nått end of life, till exempel 18 eller 20, när är övergången planerad?”

Vad du gör i dag

Dagens ordning är den här: Uppdatera först Node.js till den rättade versionen på den egna release line och starta om varje process som använder den, bygg sedan om allt där runtime är inbyggd, och planera först därefter övergången för de projekt som körs på release lines som har nått end of life.

För det första, uppdatera inom release line: till 22.23.4, 24.22.1 eller 26.12.1 beroende på vilken line du ligger på. På ett webbhotell gör leverantören det, och ditt arbete är att försäkra dig om att applikationen använder den uppdaterade versionen.

För det andra, starta om processerna: En process som redan körs fortsätter att använda den Node.js som den startades med, och att byta filen på disken påverkar den inte. Samma sak gällde PHP2Shell: Paketet är bytt, men den gamla processen fortsätter att arbeta med den gamla koden.

För det tredje, bygg om det där runtime är inbyggd: Docker-containeravbildningar måste byggas om från en uppdaterad basavbildning. Om du distribuerar programmet som en enda körbar fil (single executable application, SEA) är själva Node.js inbyggt i den, så en uppdatering av versionen som är installerad i systemet påverkar den inte, och filen måste byggas på nytt med den rättade versionen; samma sak gäller startup snapshots, som berörs av felet i cachen för slumpvärden.

För det fjärde, om du ligger på release line 18 eller 20, planera övergången: Det är ett större arbete än en uppdatering inom samma line, så det är värt att börja nu, och ordningen beskrivs i nästa avsnitt.

Hur du går över från Node.js 18 eller 20

En övergång mellan huvudversioner är inte ett arbete för ett enda kommando, och den är värd att göra i ordning. Först ska målet väljas, och i de flesta fall är det release line 24, som får säkerhetsuppdateringar fram till den 30 april 2028. Release line 22 är ett rimligt val bara om något viktigt beroende ännu inte stöder line 24, eftersom stödet för line 22 tar slut ett år tidigare.

Sedan ska alla ställen hittas där projektet anger sin egen Node.js-version, eftersom de nästan alltid är flera: package.json-fältet engines, filerna .nvmrc eller .node-version, basavbildningen i Dockerfile, konfigurationen av miljön för continuous integration (CI) och inställningen i hostingpanelen. Om bara en del av dem byts kör olika miljöer olika versioner, och felen dyker upp där de är svårast att hitta.

Därefter ska projektet installeras på nytt i en testmiljö med den nya versionen, och testerna ska köras. Särskild uppmärksamhet hör till paket som innehåller kompilerad kod: De byggs för en bestämd Node.js-version, så efter övergången kan de behöva byggas om eller uppdateras. För varje huvudversion publicerar Node.js en ändringslista, där ändringar som kan få befintlig kod att gå sönder är markerade för sig, och den är värd att läsa före övergången och inte efter den.

Först därefter kommer produktionsmiljön: versionsbytet, omstarten av processerna och en kontroll av att process.version visar den nya versionen. Den gamla versionen kan ligga kvar några dagar om du behöver gå tillbaka, men inte längre, eftersom just den är versionen som inte längre får någon säkerhetsuppdatering.

Vad som inte uppdateras tillsammans med Node.js

En uppdatering av Node.js reparerar själva runtime och de bibliotek som är inbyggda i den, men inte allt som applikationen använder, och just här blir det oftast kvar hål som ingen ser.

Paket som installerats för sig: Om projektet i sina beroenden använder paketet undici från npm, och inte den inbyggda fetch, ligger det paketet i projektets katalog node_modules, och en Node.js-säkerhetsrelease rör det inte. Samma sak gäller alla övriga beroenden: Pakethanteraren uppdaterar dem, och bara när någon kör den.

CA store, listan över betrodda certifikatutfärdare: Som standard använder Node.js inte operativsystemets lista över certifikatutfärdare, utan sin egen inbyggda, och i dokumentationen sägs att det är en kopia av Mozillas lista som låses vid releasetillfället. Ändringar som den här säkerhetsreleasens reaktion på det komprometterade eMudhra-mellancertifikatet når alltså programmet bara tillsammans med uppdateringen av runtime, inte tillsammans med operativsystemets uppdateringar, såvida det inte är särskilt konfigurerat att använda systemets lista.

Hur du inte missar nästa säkerhetsrelease

Node.js aviserar säkerhetsreleaser i förväg på sin säkerhetssida och anger den planerade säkerhetsreleasedagen, och den här gången gick det till precis så. Den här onsdagen var alltså ingen överraskning för den som bevakar den sidan: Uppdateringen kunde planeras i förväg, i stället för att en tid fick letas fram samma dag.

I praktiken betyder det att någon måste ansvara för den bevakningen: I managed hosting gör leverantören det, men på en egen server eller i ett projekt som det egna teamet sköter är det värt att veta vem som följer projektets meddelanden, vem som beslutar om uppdateringen och vem som kontrollerar att allt fungerar efter den. Om svaret på de frågorna är ”ingen särskild” sitter den största risken just där, och inte i någon av de tio sårbarheterna.

Om Node.js bara är ett build tool för dig

På många Laravel- och WordPress-webbplatser körs Node.js inte alls på servern: Det driver Vite eller ett liknande verktyg som av källkoden tar fram CSS- och JavaScript-filer och sedan stannar. I det fallet skiljer sig läget från en applikation som själv betjänar förfrågningar, eftersom byggprocessen inte svarar på förfrågningar från internet och inte dekomprimerar data som okända besökare skickar till den.

Att det skiljer sig betyder inte att det saknar betydelse: Build tools arbetar på utvecklarnas datorer och i miljön för continuous integration (CI), laddar ner paket och öppnar anslutningar till andra servrar, och beskrivningarna av sårbarheterna är för korta för att det ska gå att säga säkert vilka av de vägarna som är berörda. Node.js är värt att uppdatera också där, bara i rätt ordning: först de servrar där Node.js körs online, sedan utvecklarnas datorer och CI-miljön.

Det finns också ett andra skäl, som inte har med den här veckan att göra. Byggmiljön blir ofta kvar på den Node.js-version som projektet en gång startades med, och så vägrar en dag en ny version av ett verktyg helt enkelt att arbeta med den. Övergången till en release line som har stöd sker då i hast och vid ett olämpligt tillfälle, så den är lättare att göra nu, medan den fortfarande är ett planerat arbete.

Vad det betydde i vår hosting

Vår managed hosting är plats på vår egen server, och varje kund där väljer version genom hostingpanelen. På vår server körs Node.js release line 22 och 24 redan med de rättade versionerna 22.23.4 och 24.22.1. För kunder vars projekt använder de här release lines finns inget att göra, utom att försäkra sig om att processen har startats om efter uppdateringen.

Den andra sidan ska också sägas rent ut: På servern går det fortfarande att välja release lines som har nått end of life, och för dem finns ingen säkerhetsuppdatering, inte på vår server och inte på någon annans, eftersom Node.js inte släpper någon sådan. Om någon av dem är vald för ditt projekt betyder en uppdatering en övergång till release line 22 eller 24, och den görs bäst tillsammans med en kontroll av att allt efter övergången fungerar som tidigare.

Vår managed hosting börjar från 45 € i månaden, och underhållna runtimes är en del av det den summan betalar för. Om din applikation fortfarande körs på Node.js 18 eller 20, låt oss prata om övergången, innan dagen för någon kommande säkerhetsrelease tvingar fram den.