Node.js-tietoturvapäivitys: saako versiosi yhä tietoturvakorjauksia?

Tietoturvakorjauksia saivat vain ne release linet, joilla on vielä tuki, ja turvallisia ovat versiot 22.23.4, 24.22.1 ja 26.12.1 tai saman release lineen uudemmat. Node.js 18 ja 20 ovat jo ohittaneet elinkaaren päättymisen (EOL), joten tässä Node.js-tietoturvapäivityksessä niille ei ole tietoturvakorjausta eikä sellaista tule: jos sovelluksesi toimii jommallakummalla niistä, päivittäminen tarkoittaa siirtymistä toiseen release lineeseen.

Keskiviikkona 21. lokakuuta Node.js-projekti julkaisi tietoturvajulkaisut kaikille kolmelle tuetulle release linelle, ja samana päivänä PHP julkaisi hätäkorjaukset haavoittuvuuksiin, jotka saivat nimen PHP2Shell, mutta kyse on kahdesta erillisestä tapahtumasta, joiden vakavuus on erilainen. Node.js-julkaisu oli ilmoitettu etukäteen, projektin vakavimmat haavoittuvuudet on arvioitu korkeiksi eikä kriittisiksi, eikä ilmoituksessa mainita sen enempää väliaikaisia ratkaisuja kuin hyökkäyksiä oikeassa käytössä. Päivittämistä tämä ei salli lykätä, mutta se siirtää huomion: tällä kertaa suurin riski ei ole itse julkaisussa vaan versioissa, jotka eivät sitä saaneet.

Mitä lokakuun Node.js-tietoturvapäivityksessä korjattiin

Node.js:n ilmoituksessa luetellaan kymmenen haavoittuvuutta: neljä projekti on arvioinut korkeiksi, kolme keskitasoisiksi ja kolme mataliksi, mutta CVSS-arvioita projekti ei tällä kertaa ole julkaissut, joten tässä artikkelissa käytetään sen omaa arviota.

Vakavin niistä on CVE-2026-111497. Projekti nimeää sen Brotli-dekooderin out-of-bounds writeksi, kirjoitukseksi varatun muistin rajojen ulkopuolelle, joka sallii koodin suorittamisen etänä (RCE), ja arvioi sen korkeaksi. Brotli on pakkausmuoto, jonka dekooderi on sisäänrakennettu Node.js:ään, ja julkaisutiedoissa korjaus kuvataan muutokseksi tässä sisäänrakennetussa kirjastossa. Sitä reittiä, jota pitkin haavoittuvuus on saavutettavissa, ilmoituksessa ei kerrota, ja myös Brotli-kehittäjien korjauksen kuvaus puhuu vain siitä, että virheellinen tietovirta tunnistetaan nyt aiemmin. Siksi tässä ei mainita yksittäisiä funktioita: varmasti voi sanoa vain sen, että dekooderin virhe koskee eniten sovelluksia, jotka purkavat Brotli-dataa lähteestä, johon ne eivät voi luottaa.

Kolme muuta haavoittuvuutta koskee TLS-varmenteen tarkistusta, eivätkä ne ole yksi ja sama tapaus. Ensimmäinen, korkeaksi arvioitu, koskee vain 26. ja 24. release lineitä: hostname verificationin voi kiertää, jos IP-osoite on kirjoitettu täyslevein numeroin, esimerkiksi １２７.０.０.１. Toinen, sekin korkea, koskee kaikkia kolmea release linettä: tarkistuksen voi kiertää, jos hostnamen voi tulkita löyhästi IP-osoitteeksi. Kolmas on keskitason ja koskee sekin kaikkia kolmea release linettä: epästandardi IPv4-merkintä antaa sertifikaattiin merkityn DNS-nimen todistaa IP-osoitteen. Julkaisutiedoissa korjaukset on muotoiltu lyhyesti: epätyypillisesti kirjoitetut IP-osoitteet hylätään nyt, ja erikseen on korjattu IP-osoitteiden normalisoinnin regressio. Kaikissa kolmessa tapauksessa kyse on hetkestä, jolloin Node.js toimii asiakkaana, siis kun se itse muodostaa salatun yhteyden toiseen palvelimeen, eikä hetkestä, jolloin se palvelee omia kävijöitään.

Neljäs korkean arvion haavoittuvuus on funktiossa dns.resolve, joka katkaisi nimet, joissa on nollamerkki. Keskitason joukossa on HTTP-yhteyksien uudelleenkäytön virhe, jossa vastaus, joka oli kirjoitettu yhteyteen ennen pyynnön lähettämistä, saatettiin käsitellä tämän pyynnön vastauksena, ja virhe, jonka vuoksi crypto.randomUUID()- ja randomInt()-kutsujen satunnaislukuvälimuisti tallentui startup snapshoteihin ja yhteen suoritettavaan tiedostoon, niin että jokainen prosessi toisti samat arvot; kolme matalan arvion haavoittuvuutta koskee ZIP-tiedostojen käsittelyä ja Node.js:n käyttöoikeusmallia.

Satunnaislukuvälimuistin virhe kannattaa ymmärtää tarkemmin, koska tavallisessa tapauksessa se ei vaikuta mihinkään: se koskee vain projekteja, jotka käynnistyvät itse tehdystä startup snapshotista tai joita levitetään single executable applicationina (SEA), ja siellä se tarkoittaa, että jokainen samasta tiedostosta käynnistetty prosessi sai samat ”satunnaiset” arvot. Jos tällaisessa projektissa tunnisteita tai väliaikaisia koodeja tehtiin crypto.randomUUID():lla tai randomInt():lla, ne saattoivat toistua prosessien välillä, joten korjauksen jälkeen kannattaa tarkistaa, ettei jotakin näistä arvoista käytetä siellä, missä sen on oltava arvaamaton.

Julkaisu päivittää myös useita sisäänrakennettuja riippuvuuksia, release linestä riippuen c-aresin, OpenSSL:n, SQLite:n ja Undici:n, jonka varaan sisäänrakennettu fetch rakentuu. Samalla on päivitetty luotettujen varmentajien CA store kompromettoituneen eMudhra-välivarmenteen vuoksi, ja TLS-yhteydet hylkäävät nyt ketjut, joissa on estettyjä julkisia avaimia.

Mitkä versiot ovat turvallisia

Korjatut versiot ovat kolme, yksi kullekin tuetulle release linelle: 22.23.4, 24.22.1 ja 26.12.1. Kaikki, mikä omalla release linellään on vanhempaa, on altis. Kaikki kymmenen haavoittuvuutta eivät koske kaikkia release lineitä: 26. release linellä on kaikki kymmenen, 24. linellä kahdeksan ja 22. linellä seitsemän, koska kaksi matalan arvion virhettä on vain uusimmalla release linellä ja yksi TLS-virhe ei koske 22. release linettä.

Päivittäminen release lineen sisällä on pienin mahdollinen askel, ja yleensä se on myös turvallisin muutos, jonka tuotantoympäristössä voi tehdä. Sekin voi kuitenkin muuttaa käyttäytymistä, ja tällä kertaa on konkreettinen esimerkki: TLS-tarkistuksen korjaus hylkää nyt epätyypillisesti kirjoitetut IP-osoitteet. Jos jokin sovellus käytti aikoinaan tällaista merkintää yhteyksissä toiseen palvelimeen, yhteys voi päivityksen jälkeen epäonnistua. Kyseessä on korjattu tietoturva-aukko, ei uusi virhe, mutta se kannattaa tietää ennen päivittämistä eikä vasta sen jälkeen.

Release line on tärkeämpi kuin versionumero

Node.js 26:een asti jokainen pääversio kulkee saman kierron: ensin se on nykyinen versio (Current), sitten parilliset versiot saavat aktiivisen pitkäaikaisen tuen (Active LTS), sen jälkeen ne siirtyvät Maintenance LTS -vaiheeseen, jossa ne saavat vain kriittiset virhekorjaukset ja tietoturvakorjaukset, ja lopuksi tuki päättyy kokonaan, kun taas parittomat versiot 25. release lineeseen asti eivät saaneet pitkäaikaista tukea. Node.js 27:stä alkaen kierto muuttuu: julkaisuaikataulun mukaan pitkäaikaisen tuen saa jokainen release line, ja se pysyy kaikki 30 tukikuukautta aktiivisessa vaiheessa, ilman Maintenance LTS -vaihetta. Projekti itse kirjoittaa, että tuotantosovellusten tulee käyttää vain aktiivisen vaiheen tai Maintenance LTS -vaiheen pitkäaikaisen tuen versioita.

Nykyisten release lineiden lähimmät vaiheenvaihdot osuvat kahteen päivään: Node.js:n julkaisuaikataulun mukaan 24. release line siirtyi Maintenance LTS -vaiheeseen 20. lokakuuta, päivää ennen tietoturvajulkaisua, ja 26. line saa pitkäaikaisen tuen 28. lokakuuta. 22. release line on ollut Maintenance LTS -vaiheessa 21. lokakuuta 2025 alkaen ja menettää tuen 30. huhtikuuta 2027, kun taas 24. line menettää tuen 30. huhtikuuta 2028.

Käytännön merkitys on yksinkertainen: kysymys ”onko meillä uusin versio” ei itsessään kerro paljoa, mutta hyödyllinen on kysymys ”millä release linellä olemme ja mihin päivään asti se saa korjauksia”. Ensimmäisen vastaus vaihtuu joka kuukausi, toisen parin vuoden välein, ja juuri siksi toinen on helppo unohtaa.

Node.js 18 ja 20: tietoturvakorjausta ei tule

Node.js:n ilmoituksessa on lause, joka on tällä kertaa tärkeämpi kuin kaikki kymmenen haavoittuvuutta: versiot, joiden elinkaari on päättynyt, ovat tietoturvajulkaisussa aina alttiita, eikä niille julkaista tietoturvakorjausta sen enempää nyt kuin myöhemminkään, koska release line, jonka elinkaari on päättynyt, ei enää saa yhtään julkaisua.

Julkaisuaikataulun mukaan 16. release line menetti tuen 11. syyskuuta 2023, 19. line 1. kesäkuuta 2023, 18. line 30. huhtikuuta 2025 ja 20. line 30. huhtikuuta 2026. Viimeinen päivä on tärkein: 20. menetti tuen vajaa kuusi kuukautta sitten, ja projekti, joka käynnistettiin sillä, voi yhä toimia ilman mitään näkyvää ongelmaa. Juuri se tekee tilanteesta salakavalan, koska mikään sen toiminnassa ei kerro, että tietoturvakorjaukset eivät sille enää kuulu.

Yrityksille, jotka eivät voi siirtyä nopeasti tuettuun release lineeseen, Node.js:n ilmoitus mainitsee yhden mahdollisuuden: kaupallista tukea Maintenance LTS -vaiheen jälkeisille versioille tarjoavat OpenJS Ecosystem Sustainability Program -kumppanit; se on maksullinen palvelu, ja se on väliaikainen ratkaisu, ei siirron korvike.

Miten tarkistat, mitä Node.js-versiota sovelluksesi käyttää

Tarkistus vie minuutteja, mutta on yksi kohta, jossa sen tekee helposti väärin: Node.js-versio, jonka pääte näyttää, ei aina ole sama, jolla sovellus toimii.

cPanel-webhotelli. Käytetyn version näyttää kohta Software → Setup Node.js App, jossa jokaisella sovelluksella on oma rivi ja version valitsee listasta, ja listalla ovat vain ne versiot, jotka palveluntarjoaja on asentanut palvelimelle. Komento node -v tällaisessa webhotellissa voi näyttää eri version kuin tämä asetus, joten katso juuri kyseistä riviä.

Oma palvelin. Komento node -v näyttää version, joka on ensimmäisenä järjestelmän polulla, mutta prosessinhallinta, esimerkiksi PM2 tai systemd-palvelu, voi käynnistää ohjelman aivan eri suoritettavalla tiedostolla. Luotettavin vastaus on se, jonka prosessi itse ilmoittaa itsestään: process.version-arvo, esimerkiksi kirjattuna lokiin käynnistyksen hetkellä.

Kontit. Docker-ympäristössä version määrää container image, ei isäntäkone, ja container image, joka on rakennettu ennen 21. lokakuuta, ei sisällä korjausta, vaikka kontin käynnistäisi uudelleen kuinka monta kertaa, joten container image on rakennettava uudelleen päivitetyllä base imagella.

Jos pääsyä ei ole: kysymys kuuluu palveluntarjoajalle tai kehittäjälle, joka sovellusta ylläpitää. Muotoilu, joka säästää kirjeenvaihdolta: ”Mitä Node.js-versiota sovelluksemme käyttää? Onko se omalla release linellään vähintään 22.23.4, 24.22.1 tai 26.12.1? Jos se on release linellä, jonka elinkaari on päättynyt, esimerkiksi 18. tai 20., milloin siirto on suunniteltu?”

Mitä tehdä tänään

Tämän päivän järjestys on tämä: ensin päivittää Node.js korjattuun versioon omalla release linellään ja käynnistää uudelleen jokainen prosessi, joka sitä käyttää, sitten rakentaa uudelleen kaikki se, johon runtime on upotettu, ja vasta sen jälkeen suunnitella siirto niille projekteille, jotka toimivat release lineillä, joiden elinkaari on päättynyt.

Ensiksi, päivitä release lineen sisällä: versioon 22.23.4, 24.22.1 tai 26.12.1 sen mukaan, millä release linellä olet; webhotellissa sen tekee palveluntarjoaja, ja sinun tehtäväsi on varmistaa, että sovellus käyttää päivitettyä versiota.

Toiseksi, käynnistä prosessit uudelleen: prosessi, joka on jo käynnissä, jatkaa sen Node.js:n käyttöä, jolla se käynnistettiin, eikä tiedoston vaihtaminen levyllä vaikuta siihen; sama päti myös tapaukseen PHP2Shell: paketti on vaihdettu, mutta vanha prosessi jatkaa vanhalla koodilla.

Kolmanneksi, rakenna uudelleen se, johon runtime on upotettu: container imaget on rakennettava uudelleen päivitetyllä base imagella. Jos levität ohjelman single executable applicationina (SEA), siihen on upotettu itse Node.js, joten järjestelmään asennetun version päivittäminen ei vaikuta siihen, ja tiedosto on rakennettava uudelleen korjatulla versiolla, ja sama koskee startup snapshoteja, joihin satunnaislukuvälimuistin virhe vaikuttaa.

Neljänneksi, jos olet 18. tai 20. release linellä, suunnittele siirto: se on suurempi työ kuin päivittäminen release lineen sisällä, joten se kannattaa aloittaa nyt, ja järjestys on kuvattu seuraavassa jaksossa.

Miten siirtyä Node.js 18:sta tai 20:stä

Siirto pääversioiden välillä ei ole yhden komennon työ, ja se kannattaa tehdä järjestyksessä: ensin on valittava kohde, ja useimmissa tapauksissa se on 24. release line, joka saa korjauksia 30. huhtikuuta 2028 asti; 22. release line on järkevä valinta vain, jos jokin tärkeä riippuvuus ei vielä tue 24. release linettä, koska 22. release lineen tuki päättyy vuotta aiemmin.

Sitten on löydettävä kaikki kohdat, joissa projekti määrittää oman Node.js-versionsa, koska niitä on lähes aina useita: package.json-tiedoston kenttä engines, tiedostot .nvmrc tai .node-version, Dockerfilen base image, continuous integration (CI) -ympäristön asetukset ja webhotellin paneelin asetus. Jos niistä vaihtaa vain osan, eri ympäristöissä toimii eri versio, ja virheet ilmestyvät sinne, missä niitä on vaikein löytää.

Sen jälkeen projekti on asennettava testiympäristöön uudelleen uudella versiolla ja testit on ajettava. Erityinen huomio kuuluu paketeille, joissa on käännettyä koodia: ne rakennetaan tietylle Node.js-versiolle, joten siirron jälkeen ne on ehkä rakennettava uudelleen tai päivitettävä. Node.js julkaisee jokaiselle pääversiolle muutosluettelon, jossa on erikseen merkitty muutokset, jotka voivat rikkoa olemassa olevan koodin, ja se kannattaa lukea ennen siirtoa, ei sen jälkeen.

Vasta sitten tulee tuotantoympäristö: version vaihto, prosessien käynnistäminen uudelleen ja tarkistus, että process.version näyttää uuden version. Vanha versio voi jäädä saataville muutamaksi päiväksi paluuta varten, mutta ei pidemmäksi aikaa, koska juuri se on versio, jolle tietoturvakorjausta ei enää tule.

Mikä ei päivity Node.js:n mukana

Node.js:n päivittäminen korjaa itse runtimen ja siihen sisäänrakennetut kirjastot, mutta ei kaikkea, mitä sovellus käyttää, ja juuri tähän jää useimmin aukkoja, joita kukaan ei näe.

Erikseen asennetut paketit: jos projekti käyttää riippuvuuksissaan npm:n undici-pakettia eikä sisäänrakennettua fetch-funktiota, tämä paketti on projektin node_modules-kansiossa, eikä Node.js-julkaisu koske siihen, ja sama koskee kaikkia muitakin riippuvuuksia: ne päivittää paketinhallinta, ja vain silloin, kun joku ajaa sen.

Luotettujen varmentajien CA store: oletuksena Node.js ei käytä käyttöjärjestelmän varmentajalistaa vaan omaa sisäänrakennettuaan, ja dokumentaatiossa sanotaan, että se on Mozillan listan kopio, joka kiinnitetään julkaisuhetkellä. Niinpä sellaiset muutokset kuin tämän julkaisun reaktio kompromettoituneeseen eMudhra-välivarmenteeseen tulevat ohjelmalle vain runtimen päivityksen mukana, eivät käyttöjärjestelmän päivitysten mukana, ellei ohjelmaa ole erikseen asetettu käyttämään järjestelmän listaa.

Miten seuraavaa julkaisua ei ohiteta

Node.js ilmoittaa tietoturvajulkaisut etukäteen tietoturvasivullaan ja kertoo suunnitellun julkaisupäivän, ja tällä kertaa kävi juuri niin. Tämä keskiviikko ei siis ollut yllätys niille, jotka seuraavat tätä sivua: päivittämisen saattoi ajoittaa jo etukäteen sen sijaan, että aikaa etsittäisiin samana päivänä.

Käytännössä se tarkoittaa, että jonkun on oltava vastuussa tästä seurannasta: hallitussa hostingissa sen tekee palveluntarjoaja, mutta omalla palvelimellasi tai projektissa, jota oma tiimisi ylläpitää, kannattaa tietää, kuka tarkalleen seuraa projektin ilmoituksia, kuka päättää päivittämisestä ja kuka tarkistaa, että sen jälkeen kaikki toimii. Jos näihin kysymyksiin vastaus on ”ei kukaan erityisesti”, juuri siinä on suurin riski, ei jossakin kymmenestä haavoittuvuudesta.

Jos Node.js on sinulla vain build toolina

Monella Laravel- ja WordPress-verkkosivustolla Node.js ei toimi palvelimella lainkaan: se pyörittää Viteä tai vastaavaa työkalua, joka valmistaa lähdekoodista CSS- ja JavaScript-tiedostot ja pysähtyy sitten. Tällaisessa tapauksessa tilanne eroaa sovelluksesta, joka itse palvelee pyyntöjä, koska build-prosessi ei vastaa internetistä tuleviin pyyntöihin eikä pura dataa, jota tuntemattomat kävijät sille lähettävät.

Ero ei tarkoita, ettei asialla olisi väliä: build toolit toimivat kehittäjien koneilla ja continuous integration (CI) -ympäristössä, lataavat paketteja ja muodostavat yhteyksiä toisiin palvelimiin, ja haavoittuvuuksien kuvaukset ovat liian lyhyitä, jotta voisi varmasti sanoa, mitkä näistä reiteistä ovat alttiita. Node.js kannattaa päivittää myös siellä, vain oikeassa järjestyksessä: ensin palvelimet, joilla Node.js toimii verkossa, sitten kehittäjien koneet ja CI-ympäristö.

On myös toinen syy, joka ei liity tähän viikkoon: build-ympäristö jää usein sille Node.js-versiolle, jolla projekti aikoinaan käynnistettiin, ja sitten jonakin päivänä työkalun uusi versio yksinkertaisesti kieltäytyy toimimasta sillä. Siirto tuettuun release lineeseen tapahtuu silloin kiireessä ja väärällä hetkellä, joten se on helpompi tehdä nyt, kun se on suunniteltua työtä.

Mitä tämä merkitsi hallitussa hostingissamme

Hallittu hostingimme on paikka omalla palvelimellamme, ja jokainen asiakas valitsee siellä version hosting-paneelista. Palvelimellamme Node.js:n 22. ja 24. release line toimii jo korjatuilla versioilla 22.23.4 ja 24.22.1. Asiakkaille, joiden projektit käyttävät näitä release lineitä, ei ole muuta tehtävää kuin varmistaa, että prosessi on käynnistetty uudelleen päivityksen jälkeen.

Rehellisesti on sanottava myös toinen puoli: palvelimella valittavissa ovat yhä myös release linet, joiden elinkaari on päättynyt, eikä niille ole tietoturvakorjausta — ei meidän eikä kenenkään muun palvelimella, koska Node.js ei sellaista korjausta julkaise. Jos projektillesi on valittu jokin niistä, päivittäminen tarkoittaa siirtoa 22. tai 24. release lineeseen, ja se on parasta tehdä yhdessä sen tarkistuksen kanssa, että siirron jälkeen kaikki toimii niin kuin ennen.

Meidän hallittu hostingimme alkaa 45 €:sta kuukaudessa, ja ylläpidetyt runtimet ovat osa sitä, mistä tässä summassa maksetaan. Jos sovelluksesi toimii yhä Node.js 18:lla tai 20:llä, käydään siirto läpi, ennen kuin sen pakottaa jonkin seuraavan tietoturvajulkaisun päivä.