Indice dell'articolo
Rischio e azione: Microsoft ha pubblicato il 25 ottobre 2026 un aggiornamento di sicurezza fuori banda per .NET 8, .NET 9 e .NET 10, oltre a .NET 11 Release Candidate 3. La correzione principale riguarda CVE-2026-111497, una scrittura fuori dai limiti nel decoder Brotli. Chi gestisce applicazioni che decomprimono dati Brotli non attendibili deve verificare subito il modello di distribuzione, aggiornare o ricompilare e riavviare i servizi interessati.[1]
Quando un’applicazione è realmente esposta
La sola presenza di .NET sul server non dimostra l’esposizione. Il percorso vulnerabile viene raggiunto quando l’applicazione elabora dati Brotli controllabili da un attaccante tramite la decompressione delle richieste ASP.NET Core, la decompressione automatica delle risposte di HttpClient oppure le API Brotli di System.IO.Compression. Le prime due funzioni non sono abilitate automaticamente nelle configurazioni predefinite; .NET Framework non è interessato.[2]
L’advisory assegna alla vulnerabilità severità High, CVSS 8.1. Un attaccante remoto non autenticato può tentare di leggere o corrompere la memoria del processo, con possibili conseguenze su riservatezza, disponibilità o privilegi. La complessità d’attacco è indicata come alta, ma questo non rende prudente lasciare esposti decoder che elaborano input esterni.
Versioni corrette e percorso di aggiornamento
Le release corrette sono .NET 8.0.33, 9.0.22, 10.0.14 e .NET 11 RC3. Il percorso dipende da come è stata distribuita l’applicazione:[1]
- Framework-dependent: installare il runtime corretto sul sistema e riavviare l’applicazione.
- Self-contained: ricompilare e ripubblicare, perché il runtime è incluso nel pacchetto applicativo.
- Container: ricostruire l’immagine da una base aggiornata e ridistribuire; aggiornare soltanto l’host non sostituisce il runtime nel container.
- NativeAOT: aggiornare SDK e riferimenti espliciti, poi ripubblicare. Il decoder può essere già incorporato nel binario.
Il comando dotnet --list-runtimes aiuta a verificare i runtime condivisi installati, ma non censisce da solo applicazioni self-contained, immagini container ferme nei registry o eseguibili NativeAOT. L’inventario deve quindi unire host, pipeline di build, repository delle immagini e catalogo delle applicazioni.
Non c’è soltanto Brotli
Il rilascio fuori banda include anche CVE-2026-114148, relativo a metadati di proprietà non sicuri in specifici archivi Linux. Per .NET 8 e 9 il perimetro comprende anche alcuni tarball ASP.NET Core pubblicati da Microsoft; per .NET 10 e 11 riguarda gli artefatti source-build. Scaricare un archivio aggiornato non corregge automaticamente la proprietà dei file già estratti: occorre sostituire l’installazione o verificare e ripristinare proprietario e permessi secondo la procedura del fornitore.[1]
Microsoft ha inoltre ripubblicato le correzioni per CVE-2026-70197 e CVE-2026-102870, perché l’aggiornamento del 13 ottobre non le risolveva completamente in tutti i casi. Anche chi aveva già applicato il Patch Tuesday deve quindi verificare di avere le release del 25 ottobre.[3]
Patching o risposta all’incidente?
Le fonti ufficiali consultate non indicano sfruttamento attivo di CVE-2026-111497. L’attività iniziale è quindi patch management: inventario, aggiornamento, ricostruzione degli artefatti e collaudo. Passate a incident response se rilevate crash anomali durante la decompressione, corruzione di memoria, processi figli inattesi, cambi di privilegi, file modificati o traffico incompatibile con il comportamento normale. In quel caso preservate log, dump e telemetria prima di riavviare o ridistribuire.
Checklist operativa
- Inventariare host, runtime, SDK, applicazioni self-contained, NativeAOT, container e immagini nei registry.
- Cercare l’uso di
BrotliStream,BrotliDecoder, request decompression eAutomaticDecompression. - Identificare input Brotli provenienti da client, API o servizi esterni.
- Salvare configurazioni, artefatti correnti e piano di rollback.
- Aggiornare a 8.0.33, 9.0.22, 10.0.14 o .NET 11 RC3, secondo il ramo utilizzato.
- Ricompilare self-contained, NativeAOT e container; non fermarsi all’aggiornamento del runtime host.
- Riavviare i processi e verificare la versione effettivamente caricata.
- Collaudare decompressione, API, upload, chiamate HTTP, code e monitoraggio applicativo.
- Per i tarball Linux coinvolti, controllare proprietari e permessi anche nelle installazioni già estratte.[4]
Devi aggiornare applicazioni .NET distribuite su più server o container? Richiedi una verifica tecnica a MSP In Cloud.