Node.js, release di sicurezza di ottobre 2026: RCE in Brotli e bypass TLS

Il 21 ottobre 2026 il progetto Node.js ha rilasciato le versioni 22.23.4, 24.22.1 e 26.12.1. Correggono dieci vulnerabilità, quattro delle quali di gravità alta. La più seria, CVE-2026-111497, è una scrittura fuori dai limiti nel decoder Brotli di Node: dati compressi malformati possono corrompere la memoria, e la società di hosting Vercel riferisce che i ricercatori l’hanno sfruttata per leggere la memoria del processo ed eseguire comandi con i privilegi del processo Node.js. Altre due falle di gravità alta permettono a un certificato TLS di superare il controllo del nome host quando non dovrebbe. Node.js 20 e 25 hanno raggiunto la fine del ciclo di vita e non ricevono alcuna correzione.

Quali versioni sono corrette

Quali sono le dieci falle

Le release aggiornano anche componenti incluse: c-ares, Undici, l’elenco delle CA attendibili (con la rimozione della CA intermedia eMudhra compromessa), OpenSSL sui rami 24 e 22 e SQLite sul ramo 22.

Chi è esposto alla falla di Brotli

Node.js non decodifica Brotli da solo. È esposto quando il suo codice, o una libreria che usa, decomprime dati Brotli controllati da altri. Succede più spesso di quanto sembri:

• fetch() integrato decodifica automaticamente le risposte con Content-Encoding: br. Un servizio che recupera URL scelti dagli utenti, webhook o API di terze parti può ricevere una risposta malevola.
• Anche axios, got e node-fetch decodificano per impostazione predefinita le risposte compresse.
• Express 5 (body-parser 2) decodifica per impostazione predefinita i corpi delle richieste Brotli, quindi un’API può ricevere i dati direttamente da un attaccante.
• Qualsiasi chiamata a zlib.brotliDecompress, zlib.createBrotliDecompress o DecompressionStream su upload o dati di terze parti.

Applichi la patch per primi dove questi casi incontrano internet: le API pubbliche che accettano corpi compressi, i servizi che recuperano URL forniti dagli utenti e tutto ciò che decomprime file caricati.

Le falle TLS contano soprattutto quando un attaccante può ottenere, da una CA di cui il suo client si fida, un certificato che contiene un nome DNS con forma di IP, e la falla DNS quando il suo codice passa input esterno a dns.resolve. Secondo il commit della correzione, le falle TLS non sono facili da sfruttare, ma lo stesso aggiornamento le chiude.

Passo 1: trovare ogni runtime Node.js

Su Linux, elenchi ogni binario node con la sua versione:

sudo find / -xdev -type f -name node -perm -u+x 2>/dev/null | while read -r n; do echo "$n: $("$n" --version 2>/dev/null)"; done

Verifichi quale runtime usano i processi in esecuzione:

for p in $(pgrep -x node); do echo "$p $(sudo readlink -f /proc/$p/exe)"; done

In Docker, controlli ogni container in esecuzione:

for c in $(docker ps --format '{{.Names}}'); do echo "$c: $(docker exec "$c" node --version 2>/dev/null)"; done

Controlli anche i gestori di versioni (nvm, fnm, Volta, asdf), i runner CI, le immagini di build, le app Electron e le funzioni serverless, dove la versione del runtime è impostata nella configurazione del progetto.

Passo 2: aggiornare

Ubuntu e Debian con i pacchetti NodeSource:

sudo apt update && sudo apt install --only-upgrade nodejs && node --version

Con nvm:

nvm install 24.22.1 && nvm alias default 24.22.1

Container: cambi l’immagine di base con una versione fissa, ad esempio node:24.22.1-alpine o node:22.23.4-bookworm-slim, ricostruisca e ripubblichi. Aggiornare l’host non cambia ciò che viene eseguito all’interno di un container.

Piattaforme serverless e di hosting: su Vercel, i progetti su 22.x e 24.x vengono aggiornati da Vercel, che ha anche aggiunto regole firewall contro l’attacco in ingresso; i progetti ancora su 20.x devono passare a 22.x o 24.x e essere ripubblicati. Su altre piattaforme, consulti l’avviso del provider e ripubblichi non appena il runtime corretto è disponibile.

I pacchetti delle distribuzioni, come il pacchetto nodejs di Ubuntu, spesso restano indietro. Se node --version non mostra 22.23.4, 24.22.1 o 26.12.1 (o una build della distribuzione che cita queste CVE), usi le release ufficiali.

Passo 3: riavviare e verificare

Un processo in esecuzione mantiene il vecchio runtime fino al riavvio. Dopo un aggiornamento dei pacchetti su Linux, questo comando elenca i processi node che usano ancora il binario sostituito:

sudo ls -l /proc/*/exe 2>/dev/null | grep -i 'node.*(deleted)'

Riavvii quei servizi (ad esempio con systemctl restart, pm2 reload all o un nuovo deployment) ed esegua di nuovo i comandi del passo 1.

Se non può aggiornare oggi

Nessuna di queste misure sostituisce l’aggiornamento, ma riducono il rischio per qualche giorno:

• Respinga i corpi di richiesta Brotli prima che raggiungano l’applicazione, ad esempio in NGINX con if ($http_content_encoding ~* br) { return 415; }, oppure in un middleware eseguito prima dei body parser.
• Disattivi la decompressione automatica per le richieste verso server non attendibili: decompress: false in axios e got, compress: false in node-fetch, oppure request() di undici, che non decomprime. Il fetch() integrato non può essere disattivato.
• Esegua il recupero di URL forniti dagli utenti in un processo separato con il minor numero di privilegi possibile.
• Prima di passare input esterno a dns.resolve, respinga i nomi che contengono un carattere NUL.

Se non è sicuro di quali dei suoi servizi decodifichino dati non attendibili, o se ha bisogno di aiuto per aggiornare un sistema di produzione senza interruzioni, i nostri team di sviluppo software sicuro e di sicurezza gestita possono aiutarla.