Node.js: difetti in HTTP/2 e HTTPS permettono ai client di mandare in crash i server e leggere i dati di altri utenti

Cosa è successo

L'11 novembre 2026 il progetto Node.js ha pubblicato rilasci di sicurezza per le tre linee di versione supportate. Le versioni corrette sono 22.23.5, 24.22.3 e 26.13.1. Correggono 16 vulnerabilità in Node.js stesso, sette delle quali classificate come gravi. I rilasci aggiornano anche le dipendenze incluse llhttp (22.x, 24.x, 26.x), undici (24.x, 26.x) e sqlite (22.x, 24.x).

I problemi più importanti riguardano il codice server che Node.js fornisce per HTTP/2, HTTPS e TLS:

• Crash del server HTTP/2 (24.x e 26.x): qualsiasi client non autenticato può far terminare il processo Node.js. Il server richiede solo la configurazione HTTP/2 predefinita e un handler che risponde prima che il corpo della richiesta sia arrivato completamente. Il progetto definisce questo comportamento tipico. L'attacco funziona sia su TLS sia su connessioni in chiaro.
• Divulgazione di memoria HTTP/2 (tutte e tre le linee): un server può inviare a un client porzioni della propria memoria, incluse risposte destinate ad altre connessioni. Dalle versioni 24.22.0 e 26.9.0 in poi, un client può attivarla autonomamente. Nelle build 22.x e nelle 24.x e 26.x precedenti, può accadere quando il server chiude uno stream a metà di una risposta, ad esempio dopo un timeout di inattività.
• Divulgazione di memoria HTTPS (tutte e tre le linee): un client non autenticato può leggere la memoria di altre connessioni, «incluse le chiavi private TLS e le richieste di altri utenti», secondo il progetto. Ciò richiede un handler che chiama res.flushHeaders() prima che il corpo della richiesta sia terminato e che successivamente chiama res.end() con dei dati. Per leggere la memoria trapelata, l'attaccante ha bisogno anche di una rotta che restituisce o memorizza un corpo di richiesta.
• Esaurimento delle risorse HTTP/2 (tutte e tre le linee): un client può far sì che qualsiasi server HTTP/2 predefinito trattenga in modo permanente memoria e descrittori di file.
• Invio di file HTTP/2 (24.x e 26.x): un client può corrompere la memoria del server quando questo invia file tramite stream.respondWithFile() o stream.respondWithFD(). Su tutte e tre le linee, l'annullamento di questi download può anche far andare in crash il server (classificato come medio).
• Crash del server TLS (24.x e 26.x): un client può far andare in crash un server TLS che usa gli hook SNICallback, OCSPRequest, newSession o resumeSession, oppure server.addContext().
• Aggiramento del certificato client TLS (tutte e tre le linee): alcuni server applicano regole più restrittive sui certificati client per determinati hostname. Su tali server, un client approvato per un altro hostname può passare a uno più restrittivo durante la rinegoziazione TLS 1.2 senza soddisfarne le regole.

Il bollettino non segnala attacchi che sfruttino questi difetti.

Chi è interessato

• I server che eseguono Node.js 22.x prima della 22.23.5, 24.x prima della 24.22.3 o 26.x prima della 26.13.1.
• Le linee fuori supporto, incluse 20.x e 25.x, non ricevono correzioni in questo rilascio. Il progetto afferma che tali versioni sono sempre vulnerabili.
• I problemi gravi lato server riguardano solo i casi in cui un processo Node.js accetta direttamente connessioni HTTP/2, HTTPS o TLS. Esempi sono i moduli integrati node:http2, node:https o node:tls, oppure framework che li usano per terminare TLS o HTTP/2.
• I server HTTP semplici costruiti con node:http non sono interessati dalla divulgazione di memoria HTTPS.
• Il crash HTTP/2 riguarda solo le linee 24.x e 26.x, non la 22.x.

L'esposizione è molto minore se un reverse proxy come nginx, Apache, HAProxy o un load balancer termina TLS e HTTP/2, e Node.js riceve da esso solo HTTP/1.1 in chiaro. Vi consigliamo comunque di aggiornare, perché il rilascio contiene anche altre correzioni e aggiornamenti delle dipendenze.

Cosa fare ora

1. Individui tutte le installazioni di Node.js. Non dimentichi i pacchetti di sistema, i gestori di versioni (nvm, n, Volta), le immagini Docker, i runner CI e i pannelli di hosting che installano una propria versione di Node.js.
2. Aggiorni alla versione corretta della propria linea: 22.23.5, 24.22.3 o 26.13.1. Se usa pacchetti di distribuzione o di fornitori (ad esempio NodeSource o la distribuzione Linux), installi l'aggiornamento non appena la fonte dei pacchetti rende disponibili queste versioni.
3. Passi da versioni fuori supporto. Se utilizza ancora 20.x, 25.x o versioni precedenti, passi a una linea supportata. Il bollettino non indica alcuna soluzione alternativa per i server che non possono essere aggiornati.
4. Ricostruisca le immagini dei container con un'immagine base di Node.js aggiornata e le ridistribuisca. Aggiornare solo l'host non modifica il Node.js presente nei container.
5. Riavvii tutti i processi Node.js (unità systemd, PM2, container Docker, ecc.) in modo che venga caricato il nuovo runtime. Verifichi poi che le applicazioni rispondano normalmente.
6. Valuti la rotazione dei segreti in caso di esposizione. Il bollettino non specifica se i server che soddisfano le condizioni per la divulgazione di memoria HTTPS debbano sostituire le chiavi TLS o altri segreti. Se un server HTTPS Node.js della sua organizzazione rispettava tali condizioni ed era raggiungibile da internet, valuti di rinnovare il certificato TLS e la relativa chiave.

Come verificare se è interessato

• Esegua node -v su ogni server e all'interno di ciascun container (docker exec <container> node -v). Le versioni inferiori a 22.23.5, 24.22.3 o 26.13.1 nella propria linea, oppure qualsiasi linea fuori supporto come 20.x o 25.x, sono vulnerabili.
• Con PM2, pm2 list e pm2 show <app> mostrano quale binario e quale versione di Node.js usa ciascuna applicazione.
• Verifichi se le sue applicazioni terminano HTTP/2 o TLS direttamente in Node.js: cerchi nel codice http2.createSecureServer, http2.createServer, https.createServer, tls.createServer, respondWithFile, respondWithFD, SNICallback e addContext.
• Controlli il process manager e i log di sistema per individuare riavvii o crash imprevisti di Node.js. Interruzioni ripetute di un server HTTP/2 possono indicare tentativi di provocare il crash.

Fonti

• https://thehackernews.com/2026/11/nodejs-fixes-16-flaws-including-http2.html