.NET e PowerShell 7, falla Brotli CVE-2026-111497: versioni da installare e verifiche

Articolo aggiornato al 28 ottobre 2026. La situazione è ancora in evoluzione: lo aggiornerò se Microsoft rilascia nuove correzioni.

Avete server con un gestionale, un portale o un servizio interno scritto in .NET? Oppure usate PowerShell 7 per gli script di manutenzione? Domenica 25 ottobre Microsoft ha pubblicato aggiornamenti fuori ciclo per .NET 8, 9 e 10 che correggono CVE-2026-111497, una vulnerabilità nel decoder Brotli che Microsoft classifica come critica per .NET e Visual Studio e importante per PowerShell.

Brotli è l’algoritmo di compressione usato da molti server web e client HTTP. Il difetto sta nella decompressione: un flusso Brotli costruito apposta provoca una scrittura fuori dai limiti del buffer, con la possibilità di leggere o corrompere la memoria del processo. Il problema nasce nella libreria di Google ed è lo stesso già corretto da Node.js il 21 ottobre; in rete lo trovate anche come “Node2Shell” o “HTTP2Shell”. Esistono proof of concept pubblici, ma al momento non risultano attacchi reali.

Chi è coinvolto

Le versioni corrette sono queste:

• .NET 8: 8.0.33
• .NET 9: 9.0.22
• .NET 10: 10.0.14
• PowerShell 7: 7.4.22, 7.5.13 e 7.6.9, a seconda del ramo che usate
• .NET 11 è ancora in anteprima: chi lo sta provando deve passare alla Release Candidate 3

Il .NET Framework 4.x, quello integrato in Windows, non è coinvolto. Sono interessate invece le applicazioni che decomprimono dati Brotli con ASP.NET Core (request decompression), con la decompressione automatica delle risposte di HttpClient o con le API Brotli di System.IO.Compression. La decompressione delle richieste e quella automatica delle risposte sono disattivate di default, quindi molte applicazioni non sono esposte. Il punto è che dall’esterno non lo potete sapere: a meno di avere il sorgente sotto mano, io aggiornerei comunque, dando la precedenza a ciò che è raggiungibile da Internet.

Attenzione: .NET 8 e .NET 9 escono dal supporto il 10 novembre 2026, tra meno di due settimane. Questo è con ogni probabilità uno degli ultimi aggiornamenti di sicurezza che riceveranno: se un fornitore vi ha installato un’applicazione su uno di questi due rami, è il momento di chiedergli quando passa a .NET 10.

Prima di iniziare: l’inventario

Come per PHP2Shell la settimana scorsa (ne ho parlato in questo articolo), il lavoro vero è capire cosa gira davvero sulle macchine. Su ogni server lanciate:

dotnet --list-runtimes
pwsh -v

Se avete diversi server nel dominio, potete raccogliere tutto in un colpo da PowerShell con WinRM attivo:

Invoke-Command -ComputerName SRV01, SRV02, SRV03 -ScriptBlock {
    if (Get-Command dotnet -ErrorAction SilentlyContinue) { dotnet --list-runtimes }
    else { "dotnet non presente" }
}

Il comando però vede solo i runtime condivisi. Le applicazioni self-contained si portano dietro il loro runtime nella propria cartella, e per quelle aggiornare .NET sul server non serve a niente: vanno ricompilate e ripubblicate da chi le ha sviluppate. Per scovarle, cercate la libreria di base di .NET fuori dalla cartella standard:

Get-ChildItem -Path C:\ -Recurse -Filter System.Private.CoreLib.dll -ErrorAction SilentlyContinue |
    Where-Object FullName -notlike '*\dotnet\shared\*' |
    Select-Object DirectoryName, @{n='Versione'; e={$_.VersionInfo.ProductVersion}}

Su dischi grandi ci mette un po’: lanciatelo fuori orario. Prima di aggiornare, come sempre, uno snapshot della VM o almeno un backup recente, soprattutto sui server applicativi.

L’aggiornamento su Windows

1. Se usate WSUS o avete attivato in Windows Update l’opzione per gli altri prodotti Microsoft, controllate se gli aggiornamenti di .NET sono già arrivati. Non date per scontato che siano installati: verificate con dotnet --list-runtimes.
2. In alternativa usate winget, che io preferisco perché aggiorna solo ciò che è già presente:

winget upgrade --id Microsoft.DotNet.Runtime.8
winget upgrade --id Microsoft.DotNet.AspNetCore.8
winget upgrade --id Microsoft.DotNet.HostingBundle.8
winget upgrade --id Microsoft.PowerShell

3. Sostituite 8 con 9 o 10 per gli altri rami installati. Sui server dove manca winget scaricate gli installer dalla pagina ufficiale di download di .NET.
4. Riavviate le applicazioni: un processo già avviato continua a usare il runtime vecchio. Sui server IIS, dopo l’Hosting Bundle, riavviate i servizi web:

net stop was /y
net start w3svc

Attenzione: net stop was /y ferma tutti i siti del server. Avvisate gli utenti o fatelo in una finestra di manutenzione.

Su Linux e nei container

Con i pacchetti della distribuzione o del repository Microsoft basta il normale aggiornamento, seguito dal riavvio dei servizi che usano .NET:

sudo apt-get update && sudo apt-get install --only-upgrade 'dotnet-runtime-*' 'aspnetcore-runtime-*'
dotnet --list-runtimes
sudo systemctl restart nome-servizio

Per i container non serve aggiornare l’host: ricostruite le immagini partendo dalle immagini .NET aggiornate e ridistribuitele. Se avete installato .NET 8 o 9 dai tarball, Microsoft ha ripubblicato anche il tarball di ASP.NET Core per una seconda vulnerabilità, CVE-2026-114148, legata ai permessi dei file: reinstallatelo.

Se non potete aggiornare subito

Capita, soprattutto con i gestionali dove il fornitore deve certificare ogni versione. Nel frattempo potete ridurre l’esposizione bloccando sul reverse proxy o sul firewall applicativo le richieste in ingresso compresse con Brotli (intestazione Content-Encoding: br) e, se avete accesso alla configurazione, disattivando la decompressione Brotli nell’applicazione. Sono misure temporanee: l’aggiornamento resta l’unica correzione.

Se il problema persiste

Se dopo l’aggiornamento dotnet --list-runtimes mostra ancora la versione vecchia accanto a quella nuova, non è un errore: le versioni convivono e l’applicazione usa la più recente della stessa versione principale. Se invece un’applicazione non parte più, controllate nel Visualizzatore eventi, sotto Registri di Windows → Applicazione, gli errori con origine .NET Runtime o IIS AspNetCore Module V2, e segnalate il caso al fornitore prima di tornare indietro. Per PowerShell, verificate che il collegamento o l’attività pianificata avvii davvero il pwsh.exe aggiornato e non una copia portatile dimenticata in qualche cartella.

Vi è capitato di trovare durante l’inventario applicazioni .NET self-contained o runtime dimenticati da anni? Raccontate nei commenti come li avete gestiti: possono essere utili ad altri.