Aggiornamento. Questo articolo fa seguito a Node.js, la falla Brotli CVE-2026-111497 minaccia le API Express 5, pubblicato il 23 ottobre. Il nuovo sviluppo è che la stessa vulnerabilità, nata nel decodificatore Brotli di Google, riguarda anche .NET e Microsoft ha rilasciato correzioni straordinarie.

Il 25 ottobre 2026 Microsoft ha pubblicato aggiornamenti di sicurezza fuori ciclo per .NET 8, 9 e 10, oltre alla Release Candidate 3 di .NET 11. Al centro c'è la CVE-2026-111497, una scrittura fuori dai limiti nel decodificatore Brotli. Lo stesso difetto era già stato corretto in Node.js il 21 ottobre: è un buon esempio di come un bug in una libreria di base si propaghi a tutti i runtime che la incorporano.

Cosa è successo

Brotli è un formato di compressione usato da browser, CDN e server. Il difetto sta nella libreria di Google (versioni dalla 1.0.3 alla 1.2.0, corretto nelle 1.0.10, 1.1.1 e 1.2.1) e, secondo Microsoft, un attaccante non autenticato può leggere o corrompere la memoria del processo, con conseguenze che vanno dalla divulgazione di informazioni al blocco del servizio fino all'escalation di privilegi. Il punteggio indicato nel record CVE è 9,2 (CVSS 4.0); una fonte riporta però 8,1 in un'altra scheda, quindi conviene verificare il valore nell'avviso ufficiale MSRC. La scoperta è attribuita a Imperva.

La finestra di esposizione dipende dalla configurazione. Un'applicazione è a rischio se elabora dati Brotli attraverso la decompressione delle richieste in ASP.NET Core, la decompressione automatica delle risposte di HttpClient o le API System.IO.Compression. Né la decompressione delle richieste né quella automatica delle risposte sono attive per impostazione predefinita; .NET Framework non è interessato. Sono state pubblicate prove di concetto su GitHub, mentre non risultano attacchi in corso né inserimento nel catalogo CISA KEV: le fonti non sono del tutto allineate su questo punto (una scheda tecnica etichetta la falla come "exploited", ma il testo di Microsoft dice il contrario), e per prudenza va trattata come sfruttabile a breve.

Le versioni corrette sono 8.0.33, 9.0.22 e 10.0.14. Nello stesso pacchetto Microsoft ha corretto una falla sulla proprietà dei file nei tarball Linux (CVE-2026-114148, CVSS 7,8) e ha ripubblicato le correzioni per due vulnerabilità (CVE-2026-70197 e CVE-2026-102870) che il rilascio del 13 ottobre non aveva risolto del tutto.

Cosa significa per le aziende italiane

.NET è molto presente nel tessuto produttivo italiano: gestionali e portali clienti sviluppati da software house locali, applicazioni di enti pubblici e sanitari, servizi interni di banche e assicurazioni. Molte di queste applicazioni sono state scritte anni fa, sono ospitate su server gestiti dal fornitore e vengono "pubblicate" una volta e poi toccate di rado. La difficoltà non è installare l'aggiornamento di sistema, ma sapere dove gira .NET e in quale forma.

Qui sta il valore pratico dell'avviso. Un'applicazione framework-dependent si aggiorna installando il runtime e riavviando. Un'applicazione self-contained porta con sé il proprio runtime: aggiornare il server non serve, bisogna ricompilare e ripubblicare. Lo stesso vale per i container, dove va ricostruita l'immagine. In una PMI che si affida a un fornitore, il rischio concreto è che il server risulti "aggiornato" nei report di Windows Update mentre l'applicazione continua a usare il runtime vulnerabile. Chi ha più applicazioni sviluppate da terzi dovrebbe chiedere ai fornitori una conferma scritta della versione effettivamente in uso.

Dal punto di vista normativo, per i soggetti NIS2 la gestione delle vulnerabilità e la sicurezza della catena di fornitura rientrano tra le misure di base: avere un inventario del software e tempi definiti di correzione è ciò che l'ACN si aspetta di vedere nelle verifiche. Se la vulnerabilità fosse sfruttata e portasse ad accesso a dati personali, scatterebbero la valutazione e l'eventuale notifica al Garante ai sensi dell'art. 33 GDPR.

Cosa fare subito

  • Eseguire dotnet --list-runtimes su ogni server e confrontare con le versioni corrette (8.0.33, 9.0.22, 10.0.14); per .NET 11 passare dalla RC2 alla RC3.
  • Per le app framework-dependent: installare il runtime aggiornato e riavviare l'applicazione.
  • Per le app self-contained: ricompilare e ripubblicare; un host aggiornato non cambia il runtime incluso. Per i container: ricostruire e ridistribuire l'immagine.
  • Identificare le applicazioni che attivano la decompressione Brotli in ASP.NET Core o in HttpClient: sono quelle a priorità maggiore.
  • Se non si può correggere subito: disattivare la decodifica Brotli oppure bloccare su proxy o firewall le richieste in ingresso con Content-Encoding: br. Aggiornare la libreria Brotli di sistema non risolve il problema per le app che ne includono una copia propria.
  • Sui server Linux con .NET 8 o 9 installato da tarball: reinstallare da un tarball aggiornato in una cartella nuova e vuota, senza ripristinare la proprietà dei file dall'archivio; estrarre sopra l'installazione esistente non corregge il problema.
  • Controllare anche le applicazioni Node.js dello stesso ambiente, per la parte già trattata nel nostro articolo precedente.

Perché conta oltre il singolo bug

La stessa falla compare in più runtime nel giro di pochi giorni: Node.js il 21 ottobre, .NET il 25. Quando una libreria di compressione o di parsing è incorporata ovunque, l'inventario dei componenti (SBOM) diventa lo strumento per rispondere in ore anziché in settimane. Il caso mostra anche i limiti del modello "aggiorniamo il sistema operativo": il rischio vive nei runtime e nelle applicazioni, e una procedura di patch completa deve includerli.