Il 21 ottobre 2026 il progetto Node.js ha pubblicato un rilascio di sicurezza che corregge dieci vulnerabilità. Una in particolare merita attenzione immediata da chiunque gestisca applicazioni web in JavaScript: la CVE-2026-111497, una scrittura fuori dai limiti (out-of-bounds write) nel decodificatore Brotli incluso in Node.js, classificata "High" dal progetto e valutata 9,2 su scala CVSS 4.0 nel record CVE, quindi di fatto critica. Chi sviluppa o ospita servizi Node dovrebbe leggere i dettagli qui sotto prima di decidere con quale urgenza intervenire.

Cosa è successo

Brotli è un algoritmo di compressione molto diffuso sul web, usato da browser, CDN e server per ridurre le dimensioni di pagine e risposte. Node.js lo include nel modulo zlib e lo usa internamente in diverse funzioni. Il difetto risiede nel codice di decompressione (la libreria Brotli di Google, versioni dalla 1.0.3 alla 1.2.0): uno stream Brotli costruito ad arte può provocare una scrittura oltre i limiti di un buffer di memoria. Le conseguenze possibili, a seconda delle condizioni, vanno dal crash del processo alla divulgazione di memoria fino all'esecuzione di codice con i privilegi del processo Node.

Le versioni corrette sono Node.js 22.23.4, 24.22.1 e 26.12.1. Le linee non più supportate, come Node.js 20 e le versioni dispari, non ricevono correzioni: il progetto precisa che le versioni a fine vita risultano sempre vulnerabili in un rilascio di sicurezza. La falla è stata segnalata da OpenAI Codex Security, un altro caso di strumenti basati su intelligenza artificiale che trovano bug in componenti molto maturi. Nel rilascio sono state corrette anche altre tre vulnerabilità "High": la CVE-2026-105482 (dns.resolve tronca i nomi che contengono il carattere NUL) e le CVE-2026-105483 e CVE-2026-106069, che permettono di aggirare il controllo del nome host nei certificati TLS quando l'indirizzo IP è scritto in forme insolite.

Sul fronte dello sfruttamento, al momento non risultano attacchi confermati e la CVE non è nel catalogo CISA KEV. Esiste codice pubblicato su GitHub che manda in crash Node.js non aggiornato, mentre le affermazioni di una esecuzione di codice completa e pre-autenticazione, avanzate da un ricercatore, non sono state verificate in modo indipendente dalle fonti consultate. Conviene quindi trattare il rischio come serio ma non ancora dimostrato su larga scala: la finestra tra divulgazione e primi exploit funzionanti, negli ultimi mesi, si è ridotta spesso a poche ore.

Chi è davvero esposto

Non tutte le applicazioni Node sono vulnerabili allo stesso modo: occorre che l'applicazione decomprima dati Brotli controllati da un attaccante. I casi più concreti:

  • Express 5 con express.json(): il body-parser 2.x decodifica per impostazione predefinita i corpi delle richieste con Content-Encoding: br, quindi un'API esposta a Internet è raggiungibile senza alcuna autenticazione.
  • Express 4 (body-parser 1.x) rifiuta i corpi Brotli con errore 415, ma il codice applicativo può comunque usare zlib per altri scopi.
  • fetch() lato server: se l'applicazione scarica risorse da host non fidati che rispondono in Brotli, il decodificatore viene invocato sulla risposta.

Questa distinzione è importante perché evita due errori opposti: sottovalutare il problema perché "non uso Brotli" (spesso lo usa il framework al posto nostro) e prendere il panico su sistemi che non decomprimono mai dati esterni.

Cosa significa per le aziende italiane

Node.js è la base di moltissimi portali, API per app mobile, microservizi e backend di e-commerce sviluppati da software house italiane, spesso per conto di PMI che non conoscono nemmeno la versione di runtime in produzione. Vedo tre scenari ricorrenti.

Il primo è il runtime "dimenticato" dentro un container: l'immagine è stata costruita due anni fa su Node 18 o 20, funziona e nessuno la ricostruisce. Per queste versioni non esiste patch: l'unica via è migrare a una linea supportata, e questo è un progetto, non un aggiornamento da pomeriggio. Va pianificato adesso, non dopo un incidente.

Il secondo è la filiera: l'azienda utente raramente scrive il codice, ma ne risponde. Chiedere al fornitore, per iscritto, quale versione di Node usa e quando aggiornerà è il minimo di diligenza. Per i soggetti NIS2 il tema ricade nelle misure su gestione delle vulnerabilità e sicurezza della catena di fornitura, e la scadenza del 31 ottobre per rendere operative le misure di base rende la tracciabilità di queste verifiche un'evidenza preziosa in caso di ispezione dell'ACN.

Il terzo è la protezione dei dati: un'esecuzione di codice su un backend che tratta dati personali di clienti è potenzialmente una violazione ai sensi del GDPR, con obbligo di valutare la notifica al Garante entro 72 ore dalla scoperta. Aggiornare in anticipo costa meno che gestire una notifica.

Un dettaglio interessante dello stesso rilascio: l'archivio dei certificati radice incluso in Node.js è stato aggiornato per togliere la fiducia alle autorità intermedie legate alla compromissione di eMudhra, di cui abbiamo parlato in questo approfondimento. Anche questo è un buon motivo per non rimandare l'aggiornamento. Nella stessa giornata è arrivata anche la correzione di emergenza per PHP, di cui trovi il seguito in PHP2Shell, ora c'è la patch: chi gestisce uno stack web misto dovrebbe affrontare entrambi gli interventi nella stessa finestra di manutenzione.

Cosa fare subito

  • Identificare le versioni: eseguire node --version su server e nei container, e npm ls express body-parser nei progetti, per capire quali applicazioni usano Express 5.
  • Aggiornare a 22.23.4, 24.22.1 o 26.12.1 e ricostruire le immagini container; ricompilare anche gli eseguibili singoli (SEA) e gli snapshot, che incorporano il runtime.
  • Migrare dalle linee a fine vita (Node 20 e precedenti) verso 22.x o 24.x, con una data concordata con il fornitore.
  • Mitigazione temporanea: impostare express.json({ inflate: false }) (rifiuta anche i corpi gzip, quindi da testare sui client reali) oppure respingere a livello di reverse proxy o WAF le richieste con Content-Encoding: br verso le API che non ne hanno bisogno. Sono misure ponte, non sostituiscono la patch.
  • Ridurre l'impatto: eseguire Node con un utente senza privilegi, limitare i segreti presenti nelle variabili d'ambiente e usare filesystem in sola lettura nei container.
  • Verificare i log dal 21 ottobre per crash anomali del processo o richieste con corpi Brotli insoliti; non inviare traffico di exploit ai propri server per "provare".
  • Documentare data, versione e responsabile dell'intervento: serve come evidenza per NIS2 e per il registro dei trattamenti.