Se l'app, il sito, il negozio online o l'API della tua azienda è stato sviluppato con Node.js, compresi i siti realizzati con Next.js e i backend con Express o NestJS, chiedi oggi stesso al tuo sviluppatore di aggiornare Node.js alla versione 22.23.4, 24.22.1 o 26.12.1 e poi di ricostruire e riavviare il server. Il progetto Node.js ha rilasciato queste versioni il 21 ottobre 2026 per chiudere una falla nota come Node2Shell (CVE-2026-111497), valutata 9.2 su 10, che permette a un aggressore senza alcuna password di eseguire codice sul tuo server inviando dati compressi costruiti ad arte. L'Autorità nazionale per la cybersicurezza dell'Arabia Saudita (NCA) ha emesso un'allerta di livello «molto alto», e il 27 ottobre l'agenzia statunitense per la cybersicurezza CISA ha confermato che la falla viene sfruttata in attacchi reali.

Che cosa è successo esattamente?

La falla si trova in Brotli, un formato di compressione che server web e browser usano per ridurre i dati che si scambiano, e Node.js include una propria copia del decoder Brotli di Google. Secondo l'avviso di sicurezza di Node.js, dati compressi malformati fanno scrivere al decoder oltre la fine di un buffer interno, il che può mandare in crash l'applicazione, far trapelare il contenuto della sua memoria o permettere a un aggressore di eseguire codice. L'avviso attribuisce la segnalazione al team Codex Security di OpenAI, e lo stesso rilascio ha corretto 10 vulnerabilità in totale, 4 delle quali di gravità alta.

Poi tutto è andato veloce. Il 22 ottobre, un giorno dopo la correzione, il Red Team di Imperva ha eseguito codice sull'immagine ufficiale di Node.js 24.22.0 attraverso due percorsi quotidiani: la funzione integrata fetch() e i corpi delle richieste gestiti da Express 5. Il 26 ottobre ELLIO ha registrato traffico di sfruttamento reale con codice d'attacco pubblico. Il 27 ottobre CISA ha aggiunto la falla al suo catalogo delle vulnerabilità sfruttate attivamente.

Il difetto in sé è vecchio. Secondo il record CVE, riguarda le versioni di Brotli dalla 1.0.3 alla 1.2.0, e OpenAI afferma che la causa di fondo era stata corretta nel codice sorgente di Brotli a febbraio 2026, senza che nessuno sapesse che si trattava di una falla di sicurezza e senza una nuova versione, finché il 21 ottobre è uscito Brotli 1.2.1. Se ti sembra familiare, è normale: la settimana scorsa abbiamo parlato di PHP2Shell, la falla che ha aperto i server PHP e WordPress. Node2Shell è lo stesso tipo di rischio per le applicazioni scritte in JavaScript.

La mia app è coinvolta?

Node.js fa girare la parte server di una larga parte dei siti moderni, dei backend delle app mobili, delle dashboard e delle API. Se il tuo sistema è stato sviluppato negli ultimi anni da un'agenzia o da uno sviluppatore freelance, è molto probabile che giri su Node.js senza che tu lo sappia. Le linee coinvolte sono 22.x, 24.x e 26.x precedenti alle versioni corrette, oltre alle linee fuori supporto 20.x, 23.x e 25.x, che secondo il progetto Node.js sono sempre coinvolte e non riceveranno correzioni.

Usare Node.js non basta per essere esposti: qualcosa deve consegnare i dati dell'aggressore al decoder. I ricercatori indicano tre percorsi comuni:

  • Richieste compresse in arrivo. I parser del corpo delle richieste di Express 5, body-parser 2 e Koa decomprimono automaticamente i corpi in formato Brotli, prima ancora che il tuo codice venga eseguito.
  • Contenuti che il tuo server scarica. Se la tua app apre link esterni, come anteprime dei link, webhook, crawler o agenti di IA che leggono pagine web, un sito ostile può rispondere con dati compressi avvelenati. La funzione integrata fetch() di Node, axios e le richieste lato server in framework come Next.js li decomprimono automaticamente.
  • File caricati dagli utenti. Qualsiasi codice che decomprime dati Brotli forniti da un cliente o da un visitatore.

Il rischio va oltre Node.js. L'allerta della NCA cita anche Python, Bun ed Envoy, e Microsoft ha rilasciato il 25 ottobre correzioni per .NET 8, 9, 10 e 11, Visual Studio 2019, 2022 e 2026 e PowerShell da 7.4 a 7.6, classificando la falla come critica per .NET con la valutazione «Exploitation More Likely». Microsoft precisa che la decompressione Brotli non è attiva per impostazione predefinita in .NET, quindi sono esposte solo le applicazioni che l'hanno attivata.

Se il tuo sito è ospitato su Vercel, l'azienda dice nel suo avviso di aver distribuito regole firewall che bloccano il percorso d'attacco in entrata per tutti i progetti lo stesso giorno in cui Node.js ha pubblicato la correzione, e che tutti i nuovi deploy usano un Node.js corretto dal 28 ottobre. I progetti esistenti richiedono un nuovo deploy, e quelli ancora su Node.js 20 devono passare alla 22 o alla 24.

Cosa fare oggi: cinque passi

  1. Fai una domanda per iscritto. Quale versione di Node.js gira sui nostri server e dentro le nostre immagini Docker? Chiedi al tuo sviluppatore di controllare il numero di versione di Node.js con il comando node -v. Non fidarti del numero di versione di Brotli: ELLIO ha rilevato che mostra 1.2.0 sia sulle versioni corrette sia su quelle vulnerabili.
  2. Aggiorna a una versione corretta. 22.23.4, 24.22.1 o 26.12.1. Se sei su 20.x, 23.x o 25.x, passa a una linea supportata come la 22 o la 24, e fai dei test prima di andare in produzione.
  3. Ricostruisci e riavvia. Un processo in esecuzione mantiene il vecchio codice. Ricostruisci le immagini dei container su un'immagine di base corretta, perché un Dockerfile fissato sulla 24.22.0 continuerà a distribuire la versione vulnerabile finché qualcuno non modifica quella riga. Controlla anche i server di staging, le pipeline di build e le funzioni serverless.
  4. Aggiorna le altre copie. I pacchetti Python Brotli e brotlicffi (versioni 1.2.1 e 1.2.1.0), Bun, Envoy, la libreria Brotli della tua distribuzione Linux e .NET tramite l'aggiornamento Microsoft del 25 ottobre.
  5. Controlla i log e i file di crash. Cerca richieste compresse in Brotli insolitamente grandi e crash ripetuti dei processi. ELLIO avverte che la maggior parte degli attacchi falliti manda in crash il processo e che un file di crash può contenere i cookie di sessione e le chiavi dei visitatori, quindi limita chi può leggere i file di crash (core dumps) e per quanto tempo li conservi.

Se non puoi aggiornare oggi

Come misura temporanea, blocca sul server di frontend o sul firewall le richieste in arrivo che portano l'intestazione Content-Encoding: br, se la tua app non ne ha bisogno. Vercel e Imperva hanno aggiunto regole firewall per questa falla, ma la stessa Vercel sottolinea che un firewall non copre le risposte che il tuo server scarica da altri siti: solo l'aggiornamento di Node.js chiude quel percorso. Considera ogni livello di protezione come tempo guadagnato, non come un sostituto dell'aggiornamento.

Il punto di vista di Origami

Due falle critiche nelle fondamenta del web in un solo mese, prima PHP2Shell e poi Node2Shell, raccontano una storia chiara: il codice scritto dal tuo team può essere a posto mentre l'ambiente di esecuzione sottostante è aperto. La correzione di Node2Shell è rimasta circa otto mesi nel codice sorgente di Brotli prima che qualcuno capisse che si trattava di un problema di sicurezza, e una volta resi pubblici i dettagli, ai ricercatori è bastato un giorno per eseguire codice su una build ufficiale. Quello che vediamo in molte aziende è un'app consegnata anni fa, senza nessuno responsabile dei suoi aggiornamenti e senza un elenco dei punti in cui Node.js gira davvero. Se è il tuo caso, inizia quell'elenco oggi. In Origami sviluppiamo app web e sistemi, molti dei quali su Node.js e Next.js, e teniamo sotto controllo gli aggiornamenti del loro ambiente dal primo giorno. Se vuoi far controllare la tua app o aggiornare Node.js senza interruzioni, contattaci.

Fonti