La vulnerabilità Brotli riguarda .NET e Node.js: come verificare e aggiornare le applicazioni

Un’applicazione può ricevere normale traffico HTTPS e al contempo elaborare input pericolosi se decomprime dati Brotli forniti dagli utenti. Il 25 ottobre 2026 Microsoft ha rilasciato aggiornamenti straordinari per .NET per correggere un buffer overflow nel decoder Brotli; la vulnerabilità è identificata come CVE-2026-111497. Node.js ha incluso la correzione per la stessa vulnerabilità in un rilascio di sicurezza separato il 21 ottobre. Per gli sviluppatori, il primo passo è individuare il percorso che porta i dati esterni al decoder, quindi aggiornare il runtime e ricompilare o riavviare l’applicazione.

Secondo la descrizione di Microsoft, la vulnerabilità .NET potrebbe consentire a un aggressore non autenticato di leggere o danneggiare la memoria del processo, con possibili conseguenze quali divulgazione di dati, denial of service o escalation dei privilegi. Le correzioni sono state pubblicate per .NET 8, 9 e 10, oltre che per .NET 11 Release Candidate 3. Per .NET 8 sono indicati il runtime 8.0.33 e gli SDK 8.0.133 o 8.0.427. .NET Framework non è interessato da questa vulnerabilità.

Dove si presenta l’esposizione

Il rischio si presenta quando un’applicazione passa un flusso Brotli non attendibile a un decoder vulnerabile. In .NET può accadere usando la decompressione delle richieste di ASP.NET Core, la decompressione automatica delle risposte tramite HttpClient o chiamando direttamente API di System.IO.Compression, per esempio BrotliStream e BrotliDecoder. La raccomandazione .NET elenca questi percorsi e specifica che la decompressione delle richieste in ingresso e quella automatica delle risposte sono disabilitate per impostazione predefinita.

L’inventario dei pacchetti è solo il punto di partenza dell’analisi. Individua le configurazioni del middleware e dei client HTTP, le chiamate dirette al decoder e i componenti di terze parti che accettano dati compressi. Verifica se questi dati provengono da client, webhook, proxy o API esterne, e quali limiti di dimensione e tempo di elaborazione vengono applicati prima della decompressione. Questo aiuta a determinare dove il codice vulnerabile riceve dati controllabili dall’esterno.

Aggiornare .NET

Installa l’aggiornamento per il ramo in uso: .NET 8 — 8.0.33, .NET 9 — 9.0.22, .NET 10 — 10.0.14; per .NET 11, Release Candidate 3. Per le applicazioni dipendenti dal framework, installa il runtime aggiornato e riavvia l’applicazione. Le applicazioni self-contained devono essere ricompilate e pubblicate di nuovo: aggiornare il runtime sull’host non sostituisce la copia inclusa nell’applicazione. Ricompila i container e distribuiscili usando immagini .NET aggiornate.

Per NativeAOT, usa anche SDK e pacchetti runtime aggiornati quando pubblichi di nuovo. Se al momento non è possibile distribuire la correzione, disabilita temporaneamente Brotli nei percorsi di ingresso individuati che accettano dati non attendibili. Verifica le richieste normali e le integrazioni: disabilitare la compressione può modificare la gestione dei client che inviano corpi compressi.

Verificare Node.js e le dipendenze di sistema

Il progetto Node.js ha segnalato la vulnerabilità il 21 ottobre: è interessato il decoder Brotli integrato in Node.js 22.x, 24.x e 26.x. Il rilascio di sicurezza di Node.js indica rispettivamente come corrette le versioni 22.23.4, 24.22.1 e 26.12.1. Aggiorna il ramo supportato in uso e riavvia il servizio. Secondo il progetto, il problema si verifica quando l’applicazione decomprime dati forniti da un aggressore tramite node:zlib; il danneggiamento della memoria può causare un arresto anomalo, la divulgazione del contenuto della memoria o l’esecuzione remota di codice.

Controlla anche le dipendenze distribuite separatamente da Node.js o .NET di sistema. Verifica le versioni di Brotli nei container e negli artefatti di build, quindi ripeti il controllo dopo la distribuzione. Nella CI, fissa la versione dell’immagine di base aggiornata e includi il monitoraggio delle versioni delle librerie vulnerabili nel normale processo di build.

Procedura rapida

1. Compila un elenco delle applicazioni, degli SDK, dei runtime, dei container e delle build NativeAOT che usano Brotli.
2. Individua i punti in cui i dati esterni passano attraverso una decodifica automatica o diretta.
3. Aggiorna .NET, Node.js e le librerie distribuite separatamente alle versioni corrette; ricompila le applicazioni autonome e i container.
4. Riavvia i processi e verifica le versioni nell’ambiente in esecuzione, non soltanto nei file del progetto.
5. Finché la correzione non è distribuita, limita l’elaborazione di input Brotli non attendibili nei percorsi vulnerabili individuati.

La priorità dipende dalla combinazione di due fattori: la presenza di un componente vulnerabile e la possibilità di fargli elaborare un flusso compresso appositamente predisposto. L’aggiornamento corregge il difetto, mentre la mappatura dei percorsi di ingresso aiuta a verificare che la correzione sia arrivata ai processi, alle build autonome e ai container.