Vulnerabilità Node.js novembre 2026: le 16 falle e come aggiornare

Le vulnerabilità Node.js corrette l'11 novembre 2026: cosa rischi con HTTP/2 e TLS, chi le ha trovate con Claude e come aggiornare con nvm, Docker e CI.

Published

Data futura

Reading Time

19 min

L'11 novembre 2026 il progetto Node.js ha pubblicato le release di sicurezza 22.23.5, 24.22.3 e 26.13.1, che correggono 16 vulnerabilità Node.js: 7 di gravità alta, 6 media e 3 bassa. Quasi tutte stanno in due moduli che ogni server web usa, HTTP/2 e TLS, cioè la cifratura che sta dietro HTTPS.

Cinque segnalazioni hanno una firma particolare: il blog ufficiale ringrazia Chris Rohlf "in collaborazione con Claude e Anthropic Research". La notizia per chi sviluppa, però, è una sola: se il tuo server gira su una versione precedente, va aggiornato e riavviato.

In questa guida vediamo cosa correggono le release, come funziona la falla più grave, chi ha trovato i bug e come, come controllare la versione che gira davvero e come aggiornare Node con nvm, Docker e la CI.

Cosa correggono le release di sicurezza di Node.js dell'11 novembre 2026

Le release di sicurezza dell'11 novembre 2026 correggono 16 vulnerabilità in tutte e tre le linee di Node.js ancora supportate: 22, 24 e 26. Le 7 di gravità alta riguardano HTTP/2 e TLS e, in quasi tutti i casi, si possono attivare da remoto senza autenticazione.

Le linee colpite variano da falla a falla: alcune esistono solo in 24 e 26, altre anche in 22. Per questo il consiglio del progetto vale per tutti: passare all'ultima versione della propria linea. Ecco le sette di gravità alta:

Le 7 vulnerabilità Node.js di gravità alta corrette l'11 novembre 2026
CVE	Modulo	Cosa permette	Linee
CVE-2026-123863	HTTP/2	Un client senza login fa terminare il server	24, 26
CVE-2026-123864	HTTPS	Leggere memoria di altre connessioni	22, 24, 26
CVE-2026-123865	HTTP/2	Sessioni mai ripulite: memoria e file aperti che restano occupati	22, 24, 26
CVE-2026-123866	HTTP/2	Inviare al client memoria di risposta già liberata	22, 24, 26
CVE-2026-126051	TLS	Far terminare un server TLS durante l'handshake	24, 26
CVE-2026-123872	TLS 1.2	Cambiare host durante la rinegoziazione e aggirare il certificato client	22, 24, 26
CVE-2026-123874	HTTP/2	Corrompere la memoria del server con respondWithFile()	24, 26

Insieme alle correzioni sono state aggiornate alcune dipendenze: llhttp 9.4.4, il parser HTTP di Node, in tutte le linee; undici, il client HTTP dietro fetch(), in 24 e 26; sqlite in 22 e 24.

16 o 17?

Il blog di sicurezza elenca 16 CVE, le note di rilascio ne riportano 17 (c'è in più CVE-2026-123873, di gravità bassa, sul Permission Model). In questo articolo usiamo il conteggio del blog, lo stesso delle testate di sicurezza.

La falla più grave: leggere la memoria di altre connessioni HTTPS

CVE-2026-123864 permette a un client senza autenticazione di leggere memoria che appartiene ad altre connessioni, comprese le chiavi private TLS e le richieste di altri utenti. Colpisce i server HTTPS di Node 22, 24 e 26; il server HTTP in chiaro, node:http, non è colpito.

Come funziona sotto il cofano

L'heap è la memoria in cui il processo Node tiene i dati delle richieste. Il problema nasce da una rientranza: una funzione viene richiamata mentre è ancora in esecuzione.

Quando il codice JavaScript, durante la lettura del body di una richiesta, provoca una scrittura TLS da zero byte, Node decifra subito il pacchetto TLS successivo. Così il parser HTTP, llhttp_execute(), riparte mentre è ancora a metà del body. Il risultato è un use-after-free, l'uso di memoria già liberata, con una lettura fuori dai limiti dell'heap: il server copia quella memoria nel body della richiesta.

Non serve codice esotico: bastano due chiamate comuni nello stesso handler e una rotta che rimandi indietro o salvi il body.

Come riconoscere un handler esposto

Secondo l'avviso, servono un handler che chiama res.flushHeaders() prima che il body sia finito e che poi chiude con res.end() passando dei dati. Ecco lo schema, un semplice server "echo":

JavaScript

// server.mjs
import https from 'node:https';
import { readFileSync } from 'node:fs';

const opzioni = {
  key: readFileSync('key.pem'),
  cert: readFileSync('cert.pem'),
};

https
  .createServer(opzioni, (req, res) => {
    res.flushHeaders(); // ⚠️ header inviati prima della fine del body
    const parti = [];
    req.on('data', (chunk) => parti.push(chunk));
    req.on('end', () => {
      res.end(Buffer.concat(parti)); // ⚠️ end() con dati: rimanda il body
    });
  })
  .listen(8443);

JavaScript

// server.mjs
import https from 'node:https';
import { readFileSync } from 'node:fs';

const opzioni = {
  key: readFileSync('key.pem'),
  cert: readFileSync('cert.pem'),
};

https
  .createServer(opzioni, (req, res) => {
    res.flushHeaders(); // ⚠️ header inviati prima della fine del body
    const parti = [];
    req.on('data', (chunk) => parti.push(chunk));
    req.on('end', () => {
      res.end(Buffer.concat(parti)); // ⚠️ end() con dati: rimanda il body
    });
  })
  .listen(8443);

flushHeaders() manda subito gli header, invece di aspettare il primo pezzo di risposta: è utile, per esempio, quando la risposta è lenta ad arrivare. Il codice è corretto e legittimo: la falla è in Node, non qui. Ma se nel tuo progetto c'è uno schema simile su HTTPS, l'aggiornamento non può aspettare.

Le chiavi TLS vanno cambiate?

L'avviso non lo dice. Se un server con questo schema era esposto su Internet, valuta con chi gestisce la sicurezza se ruotare chiavi e segreti dopo l'aggiornamento.

HTTP/2: quattro falle gravi per far cadere o svuotare un server

Quattro delle sette vulnerabilità gravi sono nel modulo node:http2. Si attivano da remoto senza autenticazione e, in diversi casi, bastano le impostazioni di default.

CVE-2026-123863: un handler che risponde prima della fine del body, caso tipico, basta a far fallire un controllo interno e terminare il processo
CVE-2026-123865: un errore di protocollo durante la chiusura lascia la sessione appesa, con memoria e socket mai liberati
CVE-2026-123866: se uno stream viene chiuso mentre una scrittura aspetta, il server può inviare memoria già liberata
CVE-2026-123874: con respondWithFile() o respondWithFD() un client può far usare al server un oggetto già liberato

respondWithFile() è il metodo di node:http2 che manda un file come risposta. Anche la falla di gravità media CVE-2026-123875 lo riguarda: annullare qualche download basta a far cadere il server.

Due di queste falle, 123863 e 123865, sono correzioni incomplete di problemi già corretti: CVE-2024-27983 e CVE-2026-48937. È un pattern frequente nei bug di memoria: una correzione copre il caso segnalato, ma non tutte le strade che portano allo stesso stato.

TLS e certificati client: quando l'autenticazione non basta

Quattro falle riguardano TLS. Tre toccano il mTLS (mutual TLS), lo schema in cui anche il client presenta un certificato per farsi riconoscere: sono rilevanti per chi usa regole diverse per host diversi sullo stesso server. La quarta fa cadere il server durante l'handshake.

CVE-2026-123872 (alta): con TLS 1.2 un client autorizzato per un host può rinegoziare la connessione con un altro nome e portarsi dietro l'autenticazione
CVE-2026-123867 (media): un contesto per host con la sola CA dei client, senza certificato del server, ricade sulla CA di default
CVE-2026-123877 (media): https.Agent riusa una sessione TLS tra una richiesta senza ca e una con ca: []
CVE-2026-126051 (alta): con hook come SNICallback, un client può far terminare il server durante l'handshake

Tra le medie c'è anche CVE-2026-123871: in quattro messaggi di errore ERR_PROXY_INVALID_CONFIG l'URL del proxy finiva nei log con utente e password.

Chi le ha trovate: Chris Rohlf, Claude e Anthropic Research

Cinque delle 16 segnalazioni portano la stessa frase nel blog di Node.js: "Thank you, to Chris Rohlf in collaboration with Claude and Anthropic Research for reporting this vulnerability". Tre sono di gravità alta (123863, 123864, 123874), una media (123875) e una bassa (123862, in zlib).

È un dato da leggere con precisione. Nei crediti ufficiali il segnalatore è una persona, che ha lavorato con il modello di Anthropic. Le correzioni le ha scritte Matteo Collina, membro del Technical Steering Committee di Node.js, e le release le ha preparate il team del progetto. L'AI ha aiutato a trovare i bug; verificarli, correggerli e rilasciarli resta un lavoro umano.

Le altre 11 segnalazioni arrivano da ricercatori diversi: Tim Perry (pimterry) ne firma tre, mentre Trail of Bits, indicata nei crediti con OpenAI, firma una falla del Permission Model.

Come arriva una vulnerabilità in una release

Il percorso è descritto nella politica di sicurezza di Node.js (SECURITY.md):

Segnalazione privata: via HackerOne, con risposta di solito entro 5 giorni
Verifica: il problema si controlla su tutte le versioni supportate
Correzione riservata: le patch restano fuori dal repository pubblico fino all'annuncio
Embargo e CVE: si sceglie una data, di solito 72 ore dopo l'assegnazione del CVE
Pubblicazione: release, avviso nella mailing list e sul blog

Come controllare la versione di Node.js che gira davvero

Per sapere se sei esposto devi controllare la versione di Node che esegue il server, non solo quella del tuo computer. Le versioni corrette sono 26.13.1, 24.22.3 e 22.23.5, o successive nella stessa linea.

Il controllo base è un comando:

Terminal

# terminale
node -v
# v22.23.4 → da aggiornare

Terminal

# terminale
node -v
# v22.23.4 → da aggiornare

Il punto critico è che la versione locale spesso non coincide con quella di produzione. Controlla anche:

Immagini Docker: il tag nel Dockerfile, per esempio node:26 o node:24-alpine
CI: la versione impostata nella pipeline
Hosting: la versione scelta nel pannello o nel file di configurazione
.nvmrc: il file che fissa la versione del progetto

Uno script che blocca la CI su una versione vecchia

Per non affidarti alla memoria, puoi far fallire la CI quando la versione è precedente alle correzioni. Questo script usa process.versions.node:

JavaScript

// scripts/check-node.mjs
// Versioni minime con le correzioni dell'11 novembre 2026
const MINIME = { 22: '22.23.5', 24: '24.22.3', 26: '26.13.1' };

const corrente = process.versions.node; // es. "22.23.4"
const [major] = corrente.split('.').map(Number);
const minima = MINIME[major];

if (!minima) {
  console.error(`Node ${corrente}: linea senza supporto, aggiorna a 26`);
  process.exit(1);
}

const confronta = (a, b) => {
  const x = a.split('.').map(Number);
  const y = b.split('.').map(Number);
  for (let i = 0; i < 3; i++) if (x[i] !== y[i]) return x[i] - y[i];
  return 0;
};

if (confronta(corrente, minima) < 0) {
  console.error(`Node ${corrente}: aggiorna almeno a ${minima}`);
  process.exit(1);
}
console.log(`Node ${corrente}: ok`);

JavaScript

// scripts/check-node.mjs
// Versioni minime con le correzioni dell'11 novembre 2026
const MINIME = { 22: '22.23.5', 24: '24.22.3', 26: '26.13.1' };

const corrente = process.versions.node; // es. "22.23.4"
const [major] = corrente.split('.').map(Number);
const minima = MINIME[major];

if (!minima) {
  console.error(`Node ${corrente}: linea senza supporto, aggiorna a 26`);
  process.exit(1);
}

const confronta = (a, b) => {
  const x = a.split('.').map(Number);
  const y = b.split('.').map(Number);
  for (let i = 0; i < 3; i++) if (x[i] !== y[i]) return x[i] - y[i];
  return 0;
};

if (confronta(corrente, minima) < 0) {
  console.error(`Node ${corrente}: aggiorna almeno a ${minima}`);
  process.exit(1);
}
console.log(`Node ${corrente}: ok`);

Con Node 22.23.4 lo script stampa "aggiorna almeno a 22.23.5" ed esce con codice 1, quindi la pipeline si ferma. Con Node 20 o 25 segnala la linea senza supporto. Alla prossima release di sicurezza basta aggiornare l'oggetto MINIME.

Come aggiornare Node.js con nvm, Docker e CI

Aggiornare Node.js vuol dire installare l'ultima versione della propria linea, aggiornare tutti i posti in cui la versione è scritta e riavviare i processi. Finché un processo resta acceso, continua a usare il vecchio runtime.

Con nvm

Con nvm, il gestore di versioni di Node più diffuso, installi la versione e la rendi quella di default per le nuove shell:

Terminal

# terminale
nvm install 26.13.1
nvm alias default 26.13.1
node -v   # v26.13.1

Terminal

# terminale
nvm install 26.13.1
nvm alias default 26.13.1
node -v   # v26.13.1

Se il progetto ha un file .nvmrc, aggiornalo con la nuova versione: nvm use e nvm install lo leggono quando non passi una versione.

Con Docker

Le immagini ufficiali hanno già i tag con le versioni corrette, per esempio node:26.13.1-alpine, node:24.22.3-alpine e node:22.23.5-alpine. Puoi verificare la versione di un'immagine così:

Terminal

# terminale
docker pull node:26.13.1-alpine
docker run --rm node:26.13.1-alpine node -v

Terminal

# terminale
docker pull node:26.13.1-alpine
docker run --rm node:26.13.1-alpine node -v

Se il Dockerfile usa un tag generico come node:26, ricostruire l'immagine scarica l'ultima 26. Con un tag preciso il cambio è esplicito e si vede nelle revisioni del codice.

Con package.json

Il campo engines dichiara le versioni di Node con cui funziona il progetto:

JSON

{
  "engines": {
    "node": ">=26.13.1 <27"
  }
}

JSON

{
  "engines": {
    "node": ">=26.13.1 <27"
  }
}

Attenzione: secondo la documentazione di npm, senza l'opzione engine-strict il campo produce solo avvisi. Per bloccare davvero una versione vecchia servono lo script di controllo o la versione fissata in CI.

Node 20 e 25: cosa fare su una linea a fine supporto

Se usi Node 20 o Node 25 non riceverai nessuna correzione. Node 20 è arrivato a fine supporto il 30 aprile 2026, Node 25 il 1° giugno 2026. L'avviso è esplicito: le versioni a fine supporto sono sempre colpite quando esce una release di sicurezza.

Stato delle linee di Node.js a novembre 2026
Linea	Stato	Versione corretta
Node 26	LTS attiva	26.13.1
Node 24	LTS in manutenzione	24.22.3
Node 22	LTS in manutenzione, fino ad aprile 2027	22.23.5
Node 20 e 25	Fine supporto	Nessuna: cambia linea

Per chi parte da Node 20 la scelta più lunga è Node 26, supportata fino ad aprile 2029. Il passaggio di più versioni major va provato: le breaking change di ogni major sono nelle note di rilascio.

Domande frequenti sulle vulnerabilità Node.js di novembre 2026

Uso solo HTTP/1.1 senza TLS: devo aggiornare?

Sì. La falla più grave colpisce HTTPS e molte altre HTTP/2, ma nella stessa release ci sono correzioni per zlib, per i messaggi di errore del proxy e per il Permission Model. Inoltre ogni release di sicurezza successiva parte da qui: restare indietro rende più difficile aggiornare dopo.

Basta aggiornare le dipendenze con npm update?

No. Le falle sono nel runtime di Node, non nei pacchetti di npm. npm update non cambia la versione di Node: serve installare la nuova versione e riavviare i processi.

Le falle sono già sfruttate da attaccanti?

L'avviso ufficiale non parla di attacchi in corso. Non dice nemmeno il contrario: per questo vale la regola di sempre, aggiornare appena possibile, a partire dai server esposti su Internet.

Quali bug ha trovato Claude?

Cinque, segnalati da Chris Rohlf con Claude e Anthropic Research: CVE-2026-123863, 123864 e 123874 di gravità alta, 123875 media e 123862 bassa. Quattro sono in HTTP/2 e HTTPS, uno in zlib.

Conclusione

Le vulnerabilità Node.js corrette l'11 novembre 2026 sono numerose e alcune gravi, ma la risposta è semplice e non ha alternative: aggiornare la propria linea e riavviare. Il fatto che cinque segnalazioni arrivino da un lavoro con un modello di AI dice molto su come sta cambiando la ricerca di bug; il resto del percorso, correzione e rilascio, è rimasto quello di sempre.

Aggiorna: 26.13.1, 24.22.3 o 22.23.5, o successive
Riavvia: la correzione vale solo per i processi avviati dopo
Controlla ovunque: computer, Docker, CI, hosting e .nvmrc
Blocca le versioni vecchie: uno script in CI costa dieci righe
Esci dalle linee a fine supporto: Node 20 e 25 non ricevono più patch

Se Node è nuovo per te, parti da cos'è Node.js e come funziona. Per vedere un server Node.js in azione c'è la guida per creare una chat in tempo reale con Node.js, mentre il caso di X e lo streaming SSR con React mostra quanto lavoro fa un server Node in produzione.

Su che versione di Node gira il tuo progetto in produzione, e quanto ci metti ad aggiornarla? Condividi la tua esperienza nei commenti!

Fonti

Node.js — November 11, 2026 Security Releases: l'avviso ufficiale con tutte le CVE, le linee colpite e i crediti
Node.js 26.13.1 (LTS): note di rilascio con le correzioni e le dipendenze aggiornate
Node.js 24.22.3 (LTS) e Node.js 22.23.5 (LTS): note di rilascio delle altre due linee
Node.js Release schedule: stato e date di fine supporto di ogni linea
Politica di sicurezza di Node.js: come si segnala una vulnerabilità e come funziona l'embargo
nvm: installazione e uso del gestore di versioni