Microsoft rilascia un aggiornamento .NET d'emergenza: falle RCE da correggere subito

Microsoft ha interrotto il normale calendario mensile degli aggiornamenti .NET con un rilascio di sicurezza straordinario pubblicato domenica 25 ottobre 2026. Sì, proprio di domenica, a conferma della gravità del problema e della necessità di aggiornare il prima possibile. Il pacchetto annunciato da Redmond è classificato come out-of-band (OOB), ovvero distribuito al di fuori del consueto ciclo di manutenzione, e interessa le versioni supportate .NET 8, .NET 9, .NET 10 e .NET 11.

Chi utilizza prodotti o pacchetti interessati dalle nuove vulnerabilità è chiamato a installare le versioni appena rilasciate anche se ha già applicato gli aggiornamenti di sicurezza pubblicati il 13 ottobre.

La nuova tornata di patch interviene su più problemi distinti: tra questi compaiono una vulnerabilità nel decoder Brotli, un errore nei tarball Linux, una corruzione della memoria nel sottosistema socket di .NET e una falla nel debugger Blazor WebAssembly capace, in determinate circostanze, di portare all’esecuzione di codice sul sistema dello sviluppatore.

CVE-2026-70197: quando IPv4 e IPv6 provocano una scrittura fuori dai limiti

Tra i problemi più interessanti dal punto di vista tecnico c’è CVE-2026-70197, classificata da Microsoft come vulnerabilità RCE (Remote Code Execution) in .NET e Visual Studio. Nello specifico, il difetto riguarda System.Net.Sockets e in particolare la classe SocketAsyncEventArgs: si tratta di un componente utilizzato per gestire operazioni socket asincrone ad alte prestazioni senza dover creare continuamente nuovi oggetti e buffer.

La vulnerabilità compare su Windows quando una stessa istanza di SocketAsyncEventArgs viene riutilizzata passando tra datagrammi IPv4 e IPv6.

Nel caso di questo specifico problema di sicurezza, un attaccante remoto non autenticato può fornire dati che raggiungono il percorso vulnerabile qualora l’applicazione utilizzi uno specifico pattern. Il problema riguarda sia i runtime CoreCLR sia Mono inclusi nelle versioni coinvolte: non basta quindi utilizzare una particolare implementazione runtime per considerarsi automaticamente protetti.

Le versioni corrette indicate da Microsoft sono .NET 8.0.33, 9.0.22 e 10.0.14, oltre alla build aggiornata di .NET 11.

CVE-2026-102870: il debugger Blazor genera e compila codice C#

Ancora più insolita è CVE-2026-102870, vulnerabilità RCE nel debugger Blazor WebAssembly.

Quando uno sviluppatore esamina un’espressione durante una sessione di debugging Blazor WebAssembly, il sistema può costruire dinamicamente sorgente C# contenente informazioni provenienti dall’applicazione in esecuzione.

Tra queste informazioni figurano, ad esempio ToString(), descrizioni di oggetti, nomi di classi e altri valori utilizzati dal debugger. Il codice generato è quindi compilato per valutare l’espressione richiesta.

Il problema nasce perché alcuni valori controllabili dall’applicazione non venivano sottoposti a un escaping corretto prima di essere inseriti nel sorgente C# generato. Se il dato dell’applicazione contiene una sequenza opportunamente costruita, può uscire dallo schema previsto e trasformarsi in vero codice C#: il risultato è una classica code injection, ma all’interno di uno strumento di sviluppo.

Perché l’attacco riesca è necessaria comunque una condizione precisa: lo sviluppatore deve utilizzare una versione vulnerabile dei pacchetti Blazor WebAssembly e deve valutare nel debugger un’espressione che coinvolga dati controllati dall’attaccante.

Aggiornare il runtime non basta: attenzione a Blazor, app self-contained e Linux

L’aggiornamento OOB richiede qualche attenzione in più rispetto al semplice aggiornamento del runtime .NET.

Microsoft avverte infatti che le applicazioni self-contained, cioè quelle che includono una propria copia del runtime, devono essere ricompilate e ridistribuite con una versione corretta: aggiornare .NET sul sistema operativo non modifica automaticamente il runtime incorporato nell’applicazione.

Lo stesso vale per Blazor WebAssembly: i progetti che utilizzano versioni vulnerabili dei pacchetti Microsoft.AspNetCore.Components.WebAssembly.Server o Microsoft.AspNetCore.Components.WebAssembly.DevServer devono aggiornare esplicitamente anche i relativi riferimenti NuGet.

Il rilascio del 25 ottobre interviene inoltre su CVE-2026-114148, vulnerabilità che riguarda alcuni tarball Linux di .NET e ASP.NET Core e può provocare proprietà dei file non corrette durante l’estrazione. Negli ambienti Linux, containerizzati o installati manualmente conviene quindi verificare non soltanto la versione del runtime, ma anche l’origine dei pacchetti e il modo in cui sono distribuiti.

Come verificare la versione .NET installata e aggiornare

Prima di procedere con l’aggiornamento è bene verificare quali runtime e SDK .NET sono presenti sul sistema.

Da Prompt dei comandi, PowerShell, Terminale Windows, shell Linux o macOS si può usare il comando che segue per ottenere una panoramica completa dell’installazione:

dotnet --info

L’istruzione seguente elencare i runtime installati:

dotnet --list-runtimes

Di seguito, il comando per controllare gli SDK disponibili:

dotnet --list-sdks

A valle del rilascio dell’aggiornamento OOB, le release corrette da verificare sono .NET 8.0.33, .NET 9.0.22 e .NET 10.0.14; per .NET 11 Microsoft ha pubblicato la nuova build 11.0.0-rc.3. Chi visualizza versioni precedenti dello stesso ramo dovrebbe quindi procedere con l’aggiornamento.

I pacchetti aggiornati si scaricano dalla pagina ufficiale Download .NET, scegliendo il ramo in uso, il sistema operativo e l’architettura corretta. Su Windows è possibile utilizzare gli installer Microsoft oppure aggiornare Visual Studio tramite Visual Studio Installer, se .NET risulta installato insieme all’ambiente di sviluppo.

Su Linux conviene invece mantenere lo stesso metodo utilizzato originariamente: repository della distribuzione, repository Microsoft o installazione manuale tramite tarball. Microsoft mette a disposizione pacchetti specifici per Windows x64/x86/Arm64, Linux e macOS.

Dopo l’installazione è opportuno eseguire nuovamente dotnet --list-runtimes e dotnet --list-sdks per verificare che le versioni corrette siano effettivamente presenti.

Come osservato in precedenza, particolare attenzione va riposta sulle applicazioni self-contained e sui pacchetti Blazor WebAssembly vulnerabili, che vanno aggiornati separatamente tramite NuGet.