Patch di sicurezza Node.js (ottobre 2026)
Il 21 ottobre 2026 Node.js ha pubblicato una release di sicurezza con 10 CVE per le linee 26.x, 24.x e 22.x. La più grave, CVE-2026-111497, è una scrittura fuori dai limiti nel decompressore Brotli che consente l’esecuzione remota di codice. Le versioni corrette sono v26.12.1, v24.22.1 e v22.23.4; 20.x e 25.x sono a fine vita e non ricevono patch.
Hai questa vulnerabilità? Aggiorniamo Node.js su server, immagini Docker e pipeline, verifichiamo che l’applicazione risponda come prima e pianifichiamo il cambio di linea se sei ancora su 20.x o 25.x.
$ node -vv22.20.0# 22.x è corretta in v22.23.4: vulnerabile$ docker run --rm api:prod node -vv20.19.5# L’immagine in produzione gira su 20.x: nessuna patch$ cat .nvmrc22# Il repo fissa la linea, non la patchv26.12.1 · v24.22.1 · v22.23.4Dieci CVE in una release, quattro di gravità alta
La release corregge quattro vulnerabilità alte, tre medie e tre basse. Al 21 ottobre non era stato segnalato lo sfruttamento di nessuna.
CVE-2026-111497 è una scrittura fuori dai limiti nel decompressore Brotli che consente l’esecuzione remota di codice. Non serve chiamare zlib direttamente per essere esposti: secondo Cyberkendra, Express 5 e fetch() decomprimono Brotli in automatico.
Le altre tre di gravità alta riguardano la rete. CVE-2026-106069 e CVE-2026-105483 permettono di aggirare il controllo dell’hostname nei certificati TLS, cioè la verifica che la tua applicazione stia parlando con il server giusto quando fa una richiesta HTTPS. CVE-2026-105482 fa sì che dns.resolve tronchi i nomi che contengono un carattere NUL.
La stessa release rifiuta le catene di certificati che usano le chiavi compromesse di eMudhra, l’autorità di certificazione indiana i cui otto certificati intermedi erano stati generati con chiavi deboli. Le linee 20.x e 25.x, a fine vita, non ricevono nulla di tutto questo.
Versioni di Node.js corrette
Se un servizio gira con una versione precedente a quella della sua linea, è vulnerabile. Per 20.x e 25.x non c’è versione corretta: bisogna cambiare linea.
| Linea | Corretta in | Nota |
|---|---|---|
| 26.x | v26.12.1 | |
| 24.x | v24.22.1 | |
| 22.x | v22.23.4 | |
| 25.x | Nessuna patch | Fine vita: passare a 26.x |
| 20.x | Nessuna patch | Fine vita: passare a 22.x o 24.x |
Controlla questo
- Hai API, backend o rendering lato server (Next.js, Nuxt, Astro, NestJS, Express) su Node.js.
-
node -vsul server, o dentro l’immagine Docker, restituisce una versione precedente a quella della tua linea. - Il tuo Dockerfile usa un tag come
node:22e l’immagine non è stata ricostruita: ha ancora la versione del momento della build. - Qualche servizio è ancora su 20.x o 25.x: per quelle linee non ci sarà patch.
- La tua applicazione decomprime Brotli (con
fetch(), Express 5 o un proxy proprio) o fa richieste HTTPS a terze parti.
Se sei ancora su 20.x o 25.x
Node.js non ha pubblicato mitigazioni temporanee per questa release. Su una linea non supportata, l’unica correzione è uscirne.
- 01 Le linee a fine vita non ricevono questa correzione né le prossime.
- 02 Passare da 20.x a 22.x o 24.x di solito obbliga a rivedere le dipendenze con moduli nativi e a testare l’intera build.
- 03 Durante la migrazione conviene sapere quali endpoint accettano corpi compressi e quali servizi scaricano contenuti esterni: sono i primi da spostare.
Sette passi, in questo ordine
Applichiamo la stessa procedura su ogni server: prima capire quale versione gira dove, poi correggere e infine verificare che nessuno sia entrato prima della patch.
Inventario delle versioni
Individuiamo dove gira Node.js: server, immagini Docker, funzioni serverless, runner di CI e il .nvmrc o il campo engines di ogni repository. Ogni punto può avere una versione diversa.
Mitigazione immediata
Senza mitigazione ufficiale, partiamo dai servizi più esposti: quelli che accettano corpi Brotli o scaricano contenuti di terzi vanno per primi.
Aggiornamento
Passiamo a v26.12.1, v24.22.1 o v22.23.4, ricostruiamo le immagini e fissiamo la versione in Dockerfile, .nvmrc e CI. Se sei su 20.x o 25.x, pianifichiamo il cambio di linea.
Verifica
Controlliamo la versione dentro il container in produzione, eseguiamo i test e verifichiamo che le chiamate HTTPS verso terzi continuino a validare i certificati.
Analisi degli indicatori di compromissione
Esaminiamo i log dell’applicazione e del sistema cercando crash del processo, riavvii senza spiegazione e processi o file che non dovrebbero esserci.
Rotazione dei segreti, se serve
Se ci sono segnali di accesso, ruotiamo le variabili d’ambiente sensibili: chiavi API, credenziali del database e token.
Monitoraggio dei nuovi avvisi
Annotiamo la versione di ogni servizio e la data di fine vita della sua linea, così la prossima release di sicurezza parte da quell’inventario.
Dove Node.js resta senza aggiornamento
Hai servizi su Node 20 e non sai quanto costa spostarli?
Consulenza gratuita →Domande frequenti sulla release di sicurezza di Node.js
Quali versioni di Node.js correggono CVE-2026-111497?
Uso Node 20, sono vulnerabile?
Mi riguarda se non uso Brotli?
Basta cambiare l’immagine base di Docker?
Raccontaci dove gira il tuo Node.js
Partiamo dall’inventario: quale versione usa ogni servizio, quale va aggiornato per primo e quale linea richiede una migrazione.
Raccontaci la tua sfida. Ti proponiamo la soluzione.
Senza impegno. In meno di 24 ore riceverai una proposta con ambito, tempistiche e budget. Nessuna clausola nascosta.