Allarme rosso per Node.js: falla critica consente l'hack immediato di qualsiasi sito (Node2Shell) (aggiornato: 23 ottobre 2026, ore 20:04)

Il red team di Imperva ha dimostrato Node2Shell, un exploit che esegue codice arbitrario dentro un'applicazione Node.js usando dati compressi con Brotli costruiti ad arte. Il bersaglio è CVE-2026-111497, una vulnerabilità di gravità alta nel decoder. L'advisory di sicurezza di Node.js, pubblicato il 21 ottobre 2026, conferma che la falla consente l'esecuzione di codice da remoto. Chi decomprime dati Brotli di provenienza non fidata, che arrivino dal corpo di una richiesta HTTP o dalla risposta di un server esterno, ha quindi un ottimo motivo per aggiornare subito.

Node2Shell: dal crash all'esecuzione di codice

La falla è corretta in Node.js 22.23.4, 24.22.1 e 26.12.1. Lo stesso aggiornamento sistema 10 vulnerabilità, 4 delle quali di gravità alta, ma CVE-2026-111497 è la più seria del gruppo.

Il 22 ottobre 2026 è comparso su GitHub un primo proof of concept pubblico. Otteneva però l'esecuzione di codice solo su una build volutamente indebolita. Su una build standard, il suo autore ha ottenuto un crash e una lettura limitata della memoria del processo, e ha ammesso di non essere riuscito a costruire un attacco funzionante.

Imperva (Thales Group) è andata oltre. L'analisi del ricercatore Ron Masas, pubblicata lo stesso giorno, descrive l'esecuzione di codice fornito dall'attaccante sull'immagine ufficiale di Node.js 24.22.0 per Linux arm64, senza debugger e senza build personalizzate. Il nome scelto da Imperva, nel frattempo, è diventato il modo comune per indicare il bug stesso: Node2Shell.

Il perimetro del risultato va letto con attenzione. L'attacco ha richiesto diversi tentativi e riguarda una sola build con una specifica configurazione applicativa: altre architetture e i rami 22.x e 26.x non sono stati testati. Sulla release corretta 24.22.1, gli stessi dati vengono rifiutati e nessun codice viene eseguito.

Chi è esposto: Express 5, fetch() e zlib

Un server HTTP Node.js "nudo" non decodifica da solo i corpi delle richieste compressi con Brotli. Il rischio dipende quindi da come l'applicazione tratta questi dati, e le strade d'ingresso sono tre.

• Corpi delle richieste: i body parser di Express 5 (express.json(), urlencoded(), text(), raw()) e body-parser 2.x decodificano i corpi con Content-Encoding: br quando sono applicati a una route. Imperva ha ottenuto l'esecuzione di codice con versioni fissate tra Express 5.0.0 e 5.3.0 e tra body-parser 2.0.0 e 2.3.0, sia tramite raw() sia tramite json(). Non sono state provate tutte le release intermedie
• Risposte HTTP: il fetch() integrato in Node.js decomprime in automatico le risposte Brotli, quindi un server controllato dall'attaccante, o compromesso, può raggiungere l'applicazione. Webhook e funzioni che contattano URL forniti dagli utenti sono i bersagli tipici
• Uso diretto: input non fidato passato alle funzioni Brotli di node:zlib

Imperva ha riprodotto l'esecuzione di codice sia attraverso i corpi delle richieste sia attraverso le risposte. Il problema non riguarda solo Node.js: anche Bun è vulnerabile, e la correzione è arrivata con la versione 1.4.4.

2Restano invece senza fix i rami a fine supporto, cioè 20.x e precedenti, oltre a 23.x e 25.x. I pacchetti delle distribuzioni Linux (Debian, Ubuntu, Fedora, RHEL, Alpine) possono usare la libreria Brotli di sistema al posto di quella inclusa in Node.js: in quel caso, la correzione arriva con gli aggiornamenti della distribuzione.

Cosa fare adesso

Node.js non ha pubblicato alcuna soluzione temporanea: l'unica difesa è l'aggiornamento.

1. Controllare la versione installata. Il comando node --version va lanciato ovunque giri Node.js: portatili, runner CI, server e anche dentro i container.
2. Ricostruire e ridistribuire le immagini container. Un'immagine fissata a un tag precedente, ad esempio node:22.23.3-alpine, resta vulnerabile finché non viene ricostruita.
3. Fare l'inventario di ogni runtime. Contano anche le copie di Node.js incluse nelle immagini container e nelle applicazioni distribuite come eseguibile singolo. Le piattaforme gestite che integrano una propria versione di Node.js possono essere in ritardo rispetto alle release ufficiali.
4. Aggiornare prima i servizi più esposti. La priorità va a quelli che accettano corpi delle richieste compressi con Brotli o che scaricano contenuti da server non sotto il proprio controllo.

Dopo l'aggiornamento, i log diventano anche un piccolo sistema di allarme. Un decoder non corretto rifiuta l'input malformato solo in un secondo momento, con un errore sulla lunghezza dei blocchi (-9). Quello corretto lo blocca subito con il codice -17. Se quest'ultimo compare nei log di un servizio aggiornato, è probabile che qualcuno abbia inviato uno stream costruito proprio con questa forma. Chi è fermo su un ramo a fine supporto non riceverà alcuna correzione: per lui l'unico aggiornamento possibile è il passaggio a un ramo ancora supportato.

Fonti: imperva.com, thehackernews.com, aikido.dev, hadrian.io