Falla Node.js CVE-2026-111497 da 9,2 su 10: come ho messo al sicuro le web app mie e dei miei clienti in 4 passi

Il 21 ottobre 2026 Node.js ha rilasciato un aggiornamento di sicurezza per una falla nel decompressore Brotli, la CVE-2026-111497. Ha un punteggio CVSS di 9,2 su 10, livello critico, e nei casi peggiori permette a un attaccante di eseguire codice sul server dove gira la tua web app. Le versioni corrette sono 22.23.4, 24.22.1 e 26.12.1. Le mie web app e quelle dei miei clienti sono in Node, quindi ho fatto il giro di tutti i progetti in quattro passi.

Cosa fa la falla di Node.js sui dati compressi?

La CVE-2026-111497 sfrutta il modo in cui Node.js decomprime i dati che viaggiano su internet in formato Brotli. Secondo l’advisory ufficiale di Node.js, un input Brotli malformato provoca una scrittura fuori dai limiti di un buffer interno. Le conseguenze vanno dal crash del processo alla lettura della memoria, fino all’esecuzione di codice da remoto.

Un’applicazione Node.js è esposta quando il suo codice, o una libreria che usa, decomprime dati Brotli controllati da un attaccante con node:zlib. Può succedere nel corpo di una richiesta in arrivo o nella risposta di un server esterno.

Il punteggio di 9,2 è quello assegnato da Google nel record CVE (CVSS 4.0), perché il bug sta nella libreria Brotli. Node.js nel suo advisory la classifica come "High". La patch copre tutte e tre le versioni supportate: 22.x, 24.x e 26.x. Rispetto alla falla di PHP di qualche giorno prima, la vulnerabilità di Node.js è meno sfruttabile, ma resta grave.

Come ho controllato tutti i progetti in Node.js?

Questi sono i quattro passi che ho fatto sui progetti miei e dei miei clienti.

1. Inventario con Claude Code. Con Claude Code ho elencato, per ogni progetto, frontend, backend e funzioni serverless, e quale versione di Node.js usa ciascuno.
2. Chi aggiorna cosa. Ho separato quello che il provider aggiorna da solo da quello che devo aggiornare io.
3. Esposizione di ogni backend. Ho analizzato quanto fosse esposto ogni backend alla falla.
4. Aggiornamento ovunque. Ho aggiornato Node.js su tutti i progetti, anche sul mio Mac, e ho controllato che l’aggiornamento non portasse regressioni.

Chi aggiorna Node.js: il provider o tu?

Sui frontend in hosting gestito, come Vercel, la piattaforma aveva già fatto tutto. Il bollettino di sicurezza di Vercel conferma che il giorno stesso sono state attivate regole del firewall per bloccare gli attacchi noti, e che i progetti su Node.js 22.x e 24.x ricevono le versioni corrette senza cambiare impostazioni.

Sui backend la situazione cambia. La versione di Node.js di un backend la scelgo io, e nessuno la può cambiare al posto mio. Vercel stesso lo scrive: chi usa Node.js fuori dai suoi runtime gestiti deve aggiornare comunque, firewall o no. Vale per backend esterni, container, server di CI e ambienti di sviluppo locali.

Questa distinzione è il passaggio che conta di più. Sapere chi è responsabile di ogni pezzo ti dice dove intervenire subito e dove basta verificare. Avevo fatto lo stesso ragionamento per PHP, e l’ho raccontato nell’articolo su chi deve aggiornare PHP e a quale versione.

Quanto era esposto ogni backend?

Un backend da aggiornare può essere più o meno a rischio. Per questo ho analizzato i backend uno per uno, guardando se e dove ricevono dati compressi dall’esterno.

In uno in particolare la falla si poteva sfruttare da internet senza login. È il caso più grave possibile: chiunque poteva mandare la richiesta malevola. L’ho sistemato subito, prima di tutti gli altri.

Dare una priorità a ogni progetto serve a questo. Quando i progetti sono tanti, partire da quello esposto pubblicamente riduce il rischio nelle prime ore.

Cosa mi porto a casa da questa vulnerabilità?

Usciranno sempre più vulnerabilità. Siamo in un periodo in cui le falle in librerie e framework escono una dopo l’altra: PHP l’altro ieri, Node.js ieri. Conviene stare sul pezzo e darsi un processo per aggiornare appena esce la correzione di una libreria o di un framework vulnerabile. Vale sia per chi fa vibe coding, sia per un’azienda con un prodotto o un software più grande.

Claude Code aiuta tantissimo in questo lavoro: l’inventario di versioni e dipendenze su molti progetti è proprio il genere di compito che un agente fa bene. Se il software della tua azienda lo segue qualcun altro, chiedigli che processo ha per questi casi: fa parte di uno sviluppo software su misura fatto bene, anche dopo il rilascio.

Le versioni a fine vita vanno aggiornate subito. Una versione a fine vita non riceve più patch: se domani esce una falla, per lei non arriva nessuna correzione. È esattamente il caso di Node.js 20, che secondo Vercel è a fine vita e non riceverà la correzione per la CVE-2026-111497. Un progetto che "funziona da anni" può essere proprio il più esposto.

Se hai una web app in Node.js, il momento di controllarla è oggi: versione, chi la aggiorna, quanto è esposta.