Il 21 ottobre 2026 Node.js ha corretto una falla critica in Brotli. La dimostrazione Node2Shell permette l'esecuzione di codice remoto: ecco le versioni da aggiornare nei server e nei container.
Il 21 ottobre 2026 il progetto Node.js ha pubblicato aggiornamenti di sicurezza urgenti per sanare la vulnerabilità Node.js Brotli (identificata con il codice CVE-2026-111497), un difetto critico nel componente di decompressione dei dati. Il 23 ottobre 2026 la testata The Hacker News ha documentato la ricerca condotta da Imperva, i cui analisti hanno sviluppato una dimostrazione pratica denominata "Node2Shell". Questo attacco dimostra come un flusso di dati Brotli appositamente manipolato permetta a un utente malintenzionato di eseguire codice arbitrario all'interno del server colpito. Il problema riguarda i rami 22.x, 24.x e 26.x di Node.js: per proteggere le infrastrutture aziendali è necessario aggiornare i runtime e ricostruire integralmente i container esposti.
I dettagli tecnici di CVE-2026-111497 e Node2Shell
La classificazione ufficiale assegnata da Google LLC alla falla CVE-2026-111497 riporta un punteggio CVSS 4.0 pari a 9.2, che indica un livello di gravità critico. Il difetto software si trova all'interno del file sorgente c/dec/decode.c della libreria Brotli (versioni dalla 1.0.3 alla 1.2.0). A livello tecnico, si tratta di una scrittura di memoria fuori dai limiti del buffer di destinazione (CWE-787) e di un mancato controllo dei valori di ritorno (CWE-252) durante le operazioni di decodifica.
Fino al 22 ottobre 2026 non risultano attacchi attivi registrati in rete. Tuttavia, la disponibilità pubblica della dimostrazione Node2Shell aumenta sensibilmente il rischio che vengano avviate campagne di attacco automatizzate. In passato, si riteneva che le anomalie nella gestione del formato Brotli potessero causare unicamente l'arresto anomalo del servizio. La ricerca di Imperva smentisce questo assunto, provando che un aggressore esterno può inviare una richiesta HTTP malevola e compromettere il processo applicativo senza disporre di alcuna credenziale di accesso.
Sistemi e architetture coinvolte
Il difetto coinvolge i rami di sviluppo 22.x, 24.x e 26.x di Node.js. Durante i test, gli analisti hanno ottenuto l'esecuzione di codice sul pacchetto ufficiale di Node.js versione 24.22.0 per architettura Linux arm64. Le versioni non più supportate, come la linea 20.x e quelle inferiori, non riceveranno correzioni ufficiali.
L'esposizione delle aziende a questo rischio è alta perché molti software gestionali, interfacce web, microservizi e portali per i clienti si appoggiano su Node.js. I vettori di ingresso per l'attacco sono due:
- Richieste in ingresso: il rischio si concretizza quando un'applicazione web impiega componenti per l'analisi dei dati in entrata, come i parser del framework Express 5 (versioni testate dalla 5.0.0 alla 5.3.0) o la libreria
body-parser(versioni dalla 2.0.0 alla 2.3.0), che si occupano di decodificare le richieste HTTP compresse in formato Brotli. - Risposte in uscita: il problema si presenta anche quando il servizio aziendale interroga server di terze parti tramite la funzione nativa
fetch()e riceve in risposta un pacchetto compresso con Brotli malformato.
Un ulteriore elemento di rischio deriva dall'infrastruttura. La presenza frequente di Node.js all'interno di container rende la vulnerabilità invisibile alle scansioni di sicurezza superficiali, le quali spesso si limitano a controllare i pacchetti del sistema operativo dell'infrastruttura di base, ignorando le librerie integrate nei singoli applicativi.
Come intervenire sui server e sui container
Per chiudere la vulnerabilità e prevenire l'esecuzione remota di codice, i responsabili IT devono applicare le seguenti procedure:
- Aggiornare il runtime: installare tempestivamente le versioni corrette di Node.js rilasciate il 21 ottobre 2026. L'installazione della versione 24.22.1, ad esempio, scarta il flusso di dati non valido e blocca l'attacco. Applicare le rispettive versioni corrette anche sui rami 22.x e 26.x.
- Ricostruire i container: rigenerare da zero le immagini Docker e le macchine virtuali aziendali che contengono eseguibili Node.js impacchettati. Limitarsi all'aggiornamento dei soli pacchetti di sistema non risolve il problema.
- Dismettere i rami obsoleti: migrare immediatamente i progetti ancora fermi su Node.js 20.x o versioni precedenti verso una linea supportata, poiché per questi rami non sono previste correzioni.
- Applicare protezioni perimetrali provvisorie: qualora l'aggiornamento definitivo richieda finestre di manutenzione programmate, applicare regole di blocco temporaneo tramite firewall per applicazioni web (WAF) per respingere le richieste Brotli non verificate. Questa misura protegge il traffico in ingresso, ma i filtri perimetrali non bloccano le minacce derivanti dalle chiamate in uscita effettuate con
fetch().
Verificare nel registro dei servizi aziendali quali applicazioni espongono route basate su Express 5 o integrano chiamate HTTP esterne su Node.js.
