Node2Shell: da formato compresso a RCE su Node.js, dimostrato su build ufficiale Linux arm64

Il 22 ottobre 2026 i ricercatori della Imperva Red Team hanno pubblicato la dimostrazione di esecuzione di codice remoto su una build ufficiale non modificata di Node.js 24.22.0 Linux arm64, sfruttando dati Brotli craftati. La vulnerabilità è tracciata come CVE-2026-111497.

Il meccanismo: un bug nel decoder Brotli

Il bug risiede nel file c/dec/decode.c del decoder Brotli integrato in Node.js. Secondo l'analisi di Imperva, un flusso Brotli craftato presenta una transizione di blocco impossibile che il decoder vulnerabile interpreta come richiesta di ulteriore input, anziché arrestarsi con un errore. Questa condizione invalida genera una scrittura fuori dai limiti del buffer.

I test condotti con memory sanitizer hanno confermato l'out-of-bounds write dalla condizione invalida. Il decoder Brotli viene invocato automaticamente da percorsi dati comuni: Express 5 con body-parser 2.x decoda automaticamente i request body Brotli quando app.use(express.json()) è attivo, come verificato nel codice sorgente da Brandefense. Parallelamente, fetch() di Node.js decoda automaticamente risposte Brotli.

Dal crash alla shell: il superamento del precedente limite

Il primo proof of concept pubblico per questa vulnerabilità raggiungeva l'esecuzione di codice solo su build deliberatamente indebolite per la ricerca. Su build standard, l'autore di quel PoC aveva riportato un crash e una lettura limitata della memoria di processo, non l'esecuzione di codice.

Il lavoro di Imperva supera questo limite. I ricercatori hanno operato su Node.js 24.22.0 Linux arm64, la build ufficiale distribuita dal progetto, senza ricorrere a binary instrumentati o configurazioni debug.

"Our standalone proof of concept ran code carried in a Brotli response or request body inside applications using the official Node.js 24.22.0 Linux arm64 image. It needed no debugger or instrumented binary." — Imperva Red Team

I ricercatori hanno descritto il risultato con un marker file: "In the working proof of concept, the test application had no code to create our marker file. After it received the Brotli data, the file appeared. Code carried in that data had run inside the target process."

La stessa input, testata su Node.js 24.22.1, è stata rifiutata senza generare marker.

"The same inputs on Node.js 24.22.1 were rejected and created no marker." — Imperva Red Team

Imperva ha precisato che il proof of concept "did not succeed on every attempt". I risultati confermano l'esecuzione di codice per le configurazioni testate, ma con un processo che richiede più tentativi.

Percorsi di attacco e runtime esposti

La superficie d'attacco non richiede che l'applicazione implementi esplicitamente la decompressione Brotli. Express 5 dipende da body-parser nella serie 2.x, che decoda automaticamente i formati br, gzip, deflate e zstd con l'opzione inflate attiva di default. Un server con app.use(express.json()) espone il decoder vulnerabile a dati controllati dall'attaccante.

Il secondo percorso passa attraverso fetch() nativo di Node.js: una risposta HTTP con Content-Encoding Brotli viene decodata automaticamente, senza intervento del codice applicativo. Questo vettore colpisce sia client che consumano API esterne, sia logiche server-side che effettuano chiamate outbound.

Bun era vulnerabile fino alla versione 1.4.4, secondo Aikido. Deno e altri runtime non sono menzionati nelle fonti disponibili.

Perché cambia il giudizio di rischio

Fatto: Prima della dimostrazione Imperva, la vulnerabilità era percepita come limitata a crash o lettura di memoria su build standard. Il primo PoC pubblico non aveva raggiunto RCE su configurazioni di produzione.

Analisi: La dimostrazione su build ufficiale sposta CVE-2026-111497 dalla categoria dei bug teorici a quella degli exploit pratici, almeno per l'architettura testata. Il non-determinismo del PoC non elimina il rischio: un attaccante con capacità di retry può comunque ottenere esecuzione.

Cosa fare adesso

• Aggiornare il runtime Node.js alle versioni 22.23.4, 24.22.1 o 26.12.1 rilasciate il 21 ottobre 2026: il fix è nel runtime, non nelle dipendenze npm.
• Verificare che le immagini container in CI/CD e produzione non ripristinino versioni vulnerabili tramite layer caching o pin non aggiornati.
• Rivedere le piattaforme managed: Vercel ha già attivato regole WAF il 21 ottobre, ma le infrastrutture self-hosted richiedono intervento diretto.
• Controllare che Bun, se presente nell'ecosistema, sia aggiornato alla versione 1.4.4 o successiva.

Cautele e limiti delle fonti

Un ricercatore citato da Brandefense ha espresso dubbi sulla raggiungibilità pratica della bad write in condizioni reali, evidenziando una linea di dissenso nella valutazione della sfruttabilità. Questa voce non invalida la dimostrazione Imperva, ma segnala che la comunità di sicurezza non ha raggiunto consenso unanime sulla facilità di exploitation.

I test di Imperva si riferiscono esclusivamente a Node.js 24.22.0 su Linux arm64. Non è verificato che l'exploit funzioni su x86_64 o su altre versioni del runtime. Il tasso di successo preciso non è stato quantificato oltre l'indicazione di "several tries".

Il fix upstream, commit Brotli 0ed4268a, risale a febbraio 2026 ed è stato cherry-picked da Node.js in ottobre. Le fonti non commentano le ragioni di questo intervallo.

Fonti

• thehackernews.com
• brandefense.io
• aikido.dev
• imperva.com
• brandefense.io