Node2Shell, HTTP2Shell o Broccoli2Shell: come verificare se si è vulnerabili

La vulnerabilità Node2Shell, altrimenti nota come HTTP2Shell o Broccoli2Shell, non è più soltanto un problema dimostrato in laboratorio. Negli USA, CISA (Cybersecurity and Infrastructure Security Agency) ha inserito la falla CVE-2026-111497 nel catalogo Known Exploited Vulnerabilities dopo le prime evidenze di tentativi di sfruttamento, mentre reti di honeypot hanno iniziato a intercettare richieste costruite per colpire applicazioni che decodificano dati Brotli, cioè contenuti compressi con l’algoritmo spesso usato sul Web per ridurre le dimensioni di pagine, script e altri dati trasferiti in rete.

Una falla nata nel decoder di una libreria di compressione può trasformarsi in un problema di esecuzione di codice remoto per Node.js, ma anche per molti altri software che incorporano lo stesso componente.

Il codice difettoso risale a Brotli 1.0.3, pubblicato addirittura a marzo 2018. Una prima correzione fu prodotta a fine febbraio 2026, senza però che in quel momento gli sviluppatori riconoscessero le implicazioni di sicurezza del bug e senza una nuova release dedicata. Solo mesi dopo, grazie anche all’analisi dei ricercatori di OpenAI Codex Security, la gravità del problema è diventata evidente.

La portata dell’incidente che riguarda Brotli

Della grave falla emersa in Brotli abbiamo parlato nei giorni scorsi. Ma com’è possibile controllare in pochi secondi se un server è vulnerabile e come si può metterlo al sicuro? La risposta parte da un comando molto semplice: node -v.

Rimanere passivi non è una buona idea: CISA si è subito attivata considerato il volume di attacchi, in aumento. Le conseguenze di un’aggressione rivolta nei confronti di Brotli, spaziano dal crash fino alla potenziale esecuzione di codice remoto.

Il progetto Node.js ha corretto il problema il 21 ottobre 2026 nelle versioni 22.23.4, 24.22.1 e 26.12.1. Se il sistema usa una release precedente appartenente a uno di questi rami, bisogna aggiornarla.

Il problema ha però radici più profonde. CVE-2026-111497 interessa il decoder della libreria Brotli sviluppata da Google e non soltanto Node.js. Le versioni Brotli dalla 1.0.3 alla 1.2.0 contengono il codice vulnerabile; Google ha pubblicato le release corrette 1.0.10, 1.1.1 e 1.2.1. La falla ha quindi coinvolto anche altri progetti che incorporano la stessa implementazione, tra cui componenti Python e .NET (non a caso Microsoft ha rilasciato, di domenica, un aggiornamento out-of-band per .NET).

Node2Shell: il comando più rapido per sapere quale Node.js stai usando

Oltre al comando node -v, identico su Windows, Linux e macOS, è possibile effettuare un controllo un po’ più completo:

node -p "process.version + ' | Brotli ' + process.versions.brotli + ' | ' + process.execPath"

Questa istruzione mostra tre informazioni: la versione di Node.js effettivamente eseguita, la versione Brotli dichiarata dal runtime e soprattutto il percorso del file node in uso. L’ultimo dato è prezioso quando sulla stessa macchina convivono installazioni differenti.

Attenzione però a non basare il giudizio esclusivamente sul numero restituito da process.versions.brotli. Le release di sicurezza di Node.js hanno integrato direttamente la correzione upstream nel codice Brotli incluso nel runtime; la discriminante più sicura resta quindi la versione Node.js pubblicata come release di sicurezza dal progetto.

Controllare che Windows non stia eseguendo un’altra copia di Node.js

Su Windows può capitare più facilmente del previsto di avere Node.js installato in più punti: installer ufficiale, nvm-windows, programmi di sviluppo, shell Unix compatibili o vecchie directory ancora presenti in PATH. Per individuare tutte le copie raggiungibili dal prompt si può impartire il seguente comando:

where.exe node

In alternativa, utilizzando PowerShell, si può ottenere un risultato ancora più leggibile:

Get-Command node -All | Select-Object Source,Version

Su Linux e macOS l’equivalente è il comando which -a node oppure type -a node.

npm audit non basta per scoprire Node2Shell

Lanciare npm audit è utile per individuare vulnerabilità nelle dipendenze JavaScript dichiarate dal progetto, ma la falla CVE-2026-111497 risiede anche nel Brotli nativo incorporato nel runtime Node.js. Non è quindi necessario che nel package.json compaia una dipendenza chiamata “brotli”.

Un’applicazione può raggiungere il decoder vulnerabile attraverso il modulo nativo node:zlib, per esempio usando API quali brotliDecompress(), brotliDecompressSync() oppure createBrotliDecompress(). Una ricerca nel sorgente aiuta quindi a capire quanto sia concretamente esposta.

Su Linux e macOS, dalla directory del progetto si può impartire il comando seguente:

grep -RniE "brotliDecompress|createBrotliDecompress|BROTLI|Content-Encoding.*br" . --exclude-dir=node_modules

In PowerShell:

Get-ChildItem -Recurse -File | Select-String -Pattern "brotliDecompress|createBrotliDecompress|BROTLI|Content-Encoding.*br"

Una corrispondenza non dimostra automaticamente che l’applicazione sia sfruttabile: bisogna capire se dati Brotli controllabili dall’esterno arrivano davvero al decoder. È però un buon modo per individuare rapidamente i punti da esaminare.

Quando un’applicazione Node.js è realmente esposta e come aggiornare

La vulnerabilità diventa pericolosa quando un aggressore riesce a fornire al decoder dati Brotli non attendibili. Un server che accetta richieste compresse con Content-Encoding: br, un servizio che decomprime file caricati dagli utenti o un’applicazione che elabora risposte Brotli provenienti da sistemi non fidati sono esempi molto più interessanti per un attaccante.

L’exploit di cui parla CISA non è riuscito ancora a ottenere una shell nei test del laboratorio, ma il framework utilizzato corrispondeva a codice proof-of-concept pubblico e i tentativi falliti potevano comunque provocare il crash del processo.

La soluzione preferibile è semplice: installare una versione Node.js corretta. Per chi utilizza il ramo LTS 24.x, al momento della pubblicazione dell’aggiornamento la versione sicura è Node.js 24.22.1. Sono corrette anche Node.js 22.23.4 e 26.12.1 per i rispettivi rami.

Chi usa nvm, ad esempio, può installare e selezionare la release LTS corretta con:

nvm install 24.22.1

nvm use 24.22.1

Subito dopo conviene ripetere:

node -v

Su sistemi dove Node.js arriva dal gestore pacchetti della distribuzione Linux, bisogna applicare gli aggiornamenti pubblicati dal distributore. Non sempre il numero di versione coincide esattamente con quello upstream: Debian, Ubuntu, Red Hat e altre distribuzioni possono applicare una patch di sicurezza tramite backport mantenendo una numerazione apparentemente precedente. In quel caso va verificato il bollettino del vendor e il changelog del pacchetto.

Attenzione a Docker: aggiornare Node.js sull’host può non servire

Un caso molto frequente riguarda i container: aggiornare Node.js sul server non modifica il runtime incluso in un’immagine Docker già costruita. Per verificare un container in esecuzione si può usare:

docker exec NOME_CONTAINER node -v

Se restituisce, ad esempio, v24.22.0, bisogna aggiornare l’immagine di base nel Dockerfile, ricostruire l’immagine e ridistribuire il container. Dopo il deploy è bene ripetere lo stesso comando dentro il nuovo container.

Vale anche per le immagini derivate da node:22, node:24 o node:26. Un’immagine costruita giorni o settimane prima non diventa sicura soltanto perché il tag remoto punta nel frattempo a una release aggiornata.

Infine un chiarimento rispetto all’immagine che abbiamo utilizzato come copertina: il nome Broccoli2Shell, uno dei 3 con cui è nota la falla che affligge Brotli, nasce semplicemente dall’assonanza con “broccoli“. È stato poi aggiunto il classico suffisso 2Shell usato per evocare la possibilità di arrivare all’esecuzione di comandi sul sistema vulnerabile.