Node.js corregge 16 CVE: crash HTTP/2 e un bug HTTPS che espone le chiavi TLS

L'11 novembre il progetto Node.js ha pubblicato le release di sicurezza per tutte e tre le linee supportate: 22.23.5 (Jod), 24.22.3 (Krypton) e 26.13.1 (Lithium). Il pacchetto copre 16 CVE: sette di gravità High, sei Medium e tre Low. Nel frattempo sono state aggiornate anche le dipendenze incluse llhttp, undici e sqlite.

I problemi seri riguardano il codice server di Node per HTTP/2, HTTPS e TLS. Un bug permette a un client senza credenziali di abbattere un server HTTP/2 con configurazione di default. Un altro consente a un client di leggere memoria appartenente ad altre connessioni, comprese le chiavi private TLS. Il progetto non segnala attacchi noti e la CISA non ne ha inserito nessuno nella propria lista KEV. L'avviso non indica nemmeno alcun workaround: o si aggiorna, o si resta esposti.

I bug da leggere per primi

CVE-2026-123863 (CVSS 8.2, High) è un'assertion raggiungibile nella chiusura di una sessione HTTP/2. Il trigger è piuttosto banale: un server http2 standard il cui handler invia una risposta prima che il client abbia finito di inviare il body della richiesta. Un client remoto può usarlo per abbattere l'intero processo, sia su TLS sia in chiaro. È una variante di CVE-2024-27983 sfuggita alla correzione precedente. Colpite: la 24.x dalla 24.22.0 in poi e la 26.x dalla 26.9.0 in poi.

CVE-2026-123864 è quella che mi ha fatto posare il caffè. È un bug di rientranza nel livello HTTPS di Node, e un attaccante che non fa mai login può usarlo per leggere dati dalle connessioni altrui: le loro richieste, ma anche la chiave privata TLS del vostro server. Riguarda 22.x, 24.x e 26.x. L'attaccante ha bisogno di un handler con una forma precisa: res.flushHeaders() chiamato prima che il body della richiesta sia terminato, poi res.end() con un chunk non vuoto più avanti. In più, qualche route deve restituire o salvare un body di richiesta, perché è così che i byte trapelati tornano all'attaccante. Il semplice node:http senza TLS non è interessato.

CVE-2026-123866 è un use-after-free nella chiusura degli stream HTTP/2. Può inviare al peer memoria già liberata, o dati di risposta di un'altra connessione. Tutte e tre le linee sono colpite.

CVE-2026-123872 è più silenziosa, ma insidiosa se usate mTLS. Durante la rinegoziazione TLS 1.2 un client può cambiare il servername e trasferire un'autenticazione con certificato client già esistente su un host con regole più severe per i certificati client. Se un unico processo Node serve più hostname con requisiti diversi, leggetela due volte.

Poi c'è CVE-2026-126051, un crash del server TLS innescabile da remoto. Riguarda i server 24.x e 26.x che usano SNICallback, OCSPRequest, newSession, resumeSession o server.addContext().

Le linee a fine vita non ricevono nulla. Se usate ancora la 20.x o la 25.x, questa release non risolve niente per voi.

Chi ha scoperto tutto questo? Chris Rohlf, in collaborazione con Claude e Anthropic Research, ha segnalato 123863, 123864 e diversi altri problemi della release, e Matteo Collina ha scritto la maggior parte delle correzioni. Secondo me la caccia ai bug assistita dall'AI significa che vedremo più lotti enormi di CVE come questo, non meno. Organizzate di conseguenza il vostro processo di patching.

Chi è davvero esposto

Il gruppo a rischio è quello dei team che terminano HTTP/2 o HTTPS direttamente in Node. È un gruppo più piccolo di «tutti quelli che usano Node», ma più grande di quanto si pensi.

Quando sviluppiamo app cloud-native per clienti enterprise, Node di solito sta dietro a un load balancer o reverse proxy che gestisce il TLS e parla HTTP/1.1 in chiaro con l'app. In quel caso il bug sulla fuga di chiavi non vi tocca, perché node:http in chiaro è fuori ambito. Ma nel nostro lavoro con Docker incontriamo di continuo anche l'altro tipo di servizio: un'API di amministrazione, un ricevitore di webhook, un piccolo strumento interno in cui qualcuno ha chiamato direttamente https.createServer o http2.createSecureServer perché era più rapido che configurare un proxy. Nessuno si ricorda di questi servizi al momento degli aggiornamenti.

Notate anche che 123863 funziona su HTTP/2 in chiaro. Se i vostri servizi si parlano in h2c dentro un cluster, il fatto che il TLS sia gestito a monte non vi proteggerà dal crash.

Anche i team mobile dovrebbero prestare attenzione. Nei nostri progetti nativi iOS e Android il backend è spesso un'API Node, e abbiamo visto team attivare HTTP/2 direttamente in Node per il traffico delle app per ridurre la latenza. Se quel processo può essere abbattuto da remoto, i vostri utenti vedono spinner e richieste fallite mentre il crash reporting non mostra nulla di strano lato dispositivo. Un incidente confuso da analizzare alle 2 di notte.

Sul fronte sicurezza, i bug di divulgazione della memoria mi preoccupano più dei crash. Un crash compare nel monitoraggio in pochi minuti. Una fuga di dati non fa suonare nessun allarme. Nei nostri incarichi di pentesting per studi di gaming, i problemi peggiori raramente erano quelli rumorosi, ma le letture silenziose per cui nessuno aveva una riga di log. E dal nostro lavoro anti-DDoS con clienti del settore travel: quando configuriamo Cloudflare o Akamai davanti a un origin, la prima cosa che verifichiamo è se l'origin è ancora raggiungibile direttamente. Spesso lo è. La configurazione dell'edge non serve a nulla se un attaccante può parlare con il processo Node senza passarci.

Cosa fare oggi

1. Fate l'inventario di ogni processo Node, non solo dell'app principale. Eseguite node -v dentro ogni immagine container che rilasciate, compresi cron job e sidecar. Il tag di un'immagine base fissato non si aggiorna da solo: ricostruite e rifate il deploy.
2. Aggiornate a 22.23.5, 24.22.3 o 26.13.1, a seconda della vostra linea. Non c'è nessun flag di configurazione che risolva il problema.
3. Cercate nel codice il pattern della fuga HTTPS: grep -rn "flushHeaders" . Se trovate occorrenze in un handler HTTPS e qualche route restituisce o salva i body delle richieste, portate quel servizio in cima alla coda. Se era esposto a internet, ruotare la sua chiave TLS costa poco, anche senza attacchi segnalati.
4. Se siete sulla 20.x o sulla 25.x, mettete la migrazione sulla board di questo sprint. Rimandarla al prossimo trimestre non è più un'opzione.
5. Verificate che i vostri origin accettino traffico solo dalla CDN o dal load balancer.

Nulla di tutto questo è un lavoro glamour e, onestamente, l'aggiornamento in sé di solito è la parte facile. Ci vuole più tempo per trovare il servizio dimenticato che termina da solo il proprio TLS. Se volete capire come affrontiamo questo tipo di audit, la nostra panoramica dei servizi e i lavori passati vi daranno un'idea, e il nostro team di sviluppo si occupa di questi aggiornamenti di runtime di continuo.

Se un servizio Node con una configurazione TLS propria che nessuno tocca dal lancio vi suona familiare, parliamone.