Patch .NET: aggiornare il server non aggiorna la tua app

Puoi aggiornare un server, riavviare i servizi, controllare che il sistema non segnali più pacchetti arretrati e avere comunque in produzione un’applicazione .NET che esegue codice vulnerabile. Non perché l’aggiornamento sia fallito. Perché hai aggiornato una cosa diversa da quella che sta effettivamente girando.

Il bollettino straordinario pubblicato da Microsoft il 25 ottobre 2026 è un esempio quasi didattico di questa distinzione. Arrivano correzioni importanti per Brotli e per alcuni pacchetti Linux, insieme a fix che completano aggiornamenti di sicurezza distribuiti meno di due settimane prima. La parte interessante, però, non è imparare a memoria quattro numeri di versione: è capire dove risiede il runtime che devi sostituire.

Chi gestisce un’applicazione deve rispondere a una domanda meno rassicurante di “il server è aggiornato?”: quale runtime, incorporato in quale artefatto, sta eseguendo proprio quel processo? Se non sai rispondere, il tuo inventario delle patch è incompleto.

Cosa è stato corretto il 25 ottobre

Microsoft ha pubblicato aggiornamenti fuori ciclo per .NET 8.0.33, .NET 9.0.22, .NET 10.0.14 e .NET 11 Release Candidate 3. Non si tratta di una normale release funzionale. Il bollettino distingue due vulnerabilità nuove e la ripubblicazione di correzioni che il rilascio del 13 ottobre non aveva affrontato completamente.

• CVE-2026-111497: un buffer overflow nell’uso del decoder Brotli da parte di .NET, con potenziali conseguenze sulla memoria del processo. L’esposizione richiede che un percorso di decompressione elabori dati Brotli controllabili da un attaccante.
• CVE-2026-114148: metadati di proprietà non sicuri in determinati tarball .NET per Linux; in condizioni pertinenti possono consentire a un attaccante locale di modificare file e ottenere privilegi maggiori.
• CVE-2026-70197: correzione nuovamente distribuita per un problema di corruzione memoria associato a SocketAsyncEventArgs nelle linee .NET interessate.
• CVE-2026-102870: nuova correzione relativa al debugger Blazor WebAssembly, per le linee .NET 10 e 11 indicate nel bollettino.

Il punto operativo è che queste quattro voci non descrivono una singola modalità di attacco, né implicano che qualunque applicazione .NET sia sfruttabile allo stesso modo. Il riscontro tecnico di Red Hat su Brotli sottolinea una precondizione concreta: il software deve decomprimere uno stream non attendibile attraverso il percorso vulnerabile. Una libreria presente su disco non equivale, da sola, a un exploit raggiungibile.

Brotli: il rischio dipende dal percorso dei dati

Brotli è un formato di compressione utilizzato in diversi ambienti. Nel caso .NET, Microsoft cita tre superfici da verificare: la decompressione delle richieste in ASP.NET Core, la decompressione automatica delle risposte con HttpClient e le API Brotli di System.IO.Compression. Le prime due funzionalità, specifica il bollettino, non sono abilitate per impostazione predefinita. Non significa che tu possa ignorare la patch: significa che la valutazione del rischio deve passare dalla configurazione reale, non da un titolo allarmistico.

Se un endpoint accetta corpi compressi, se un client scarica contenuti Brotli da origini non fidate o se il tuo codice decomprime direttamente stream ricevuti dall’esterno, quella è una superficie da mappare. Se non lo fa, la priorità relativa può cambiare, pur restando opportuno applicare gli aggiornamenti supportati. L’advisory della libreria Brotli documenta il problema a monte; non dimostra automaticamente che ogni integrazione abbia identica esposizione o identica sfruttabilità.

Questa distinzione è utile anche fuori dall’ecosistema .NET. Avevo già affrontato un problema affine parlando di Node.js e della differenza tra aggiornare npm e aggiornare il runtime: cambiare il componente più visibile non è necessariamente cambiare quello che contiene il difetto.

Il vero spartiacque: come hai distribuito l’applicazione

La documentazione Microsoft distingue chiaramente framework-dependent e self-contained. La prima modalità usa un runtime presente nell’ambiente; la seconda lo distribuisce insieme all’applicazione. È una scelta architetturale perfettamente legittima, ma trasferisce anche la responsabilità degli aggiornamenti.

Framework-dependent: aggiorna il runtime giusto, poi riavvia

Se l’applicazione dipende dal runtime installato sul sistema, la correzione passa dall’installazione della versione aggiornata della linea effettivamente usata e dal riavvio del processo. Non basta che sulla macchina esista una versione più recente di un’altra linea: occorre verificare il framework richiesto dall’applicazione e quello effettivamente caricato.

Il comando dotnet --list-runtimes è un buon punto di partenza per vedere i runtime installati. Non è, però, una prova universale che ogni processo attivo stia già utilizzando la versione corretta. Per questo il controllo deve comprendere il riavvio e una verifica dell’ambiente runtime effettivamente usato dall’applicazione.

Self-contained: il runtime è nel pacchetto che hai pubblicato

Qui nasce l’equivoco più costoso. Una distribuzione self-contained include il runtime necessario all’applicazione. Puoi installare .NET 8.0.33 sull’host e continuare a eseguire un pacchetto pubblicato con una patch precedente. Il processo non prende automaticamente il nuovo runtime di sistema: usa quello incluso nell’artefatto.

Un aggiornamento è efficace quando raggiunge il codice in esecuzione. Il fatto che il server sia aggiornato è soltanto un indizio, non la prova.

Microsoft è esplicita: le applicazioni self-contained vanno ricompilate e ripubblicate con il runtime corretto. Per esempio, un flusso di build può pubblicare per un RID specifico e con la modalità self-contained dichiarata. Non copiare ciecamente il comando nel tuo ambiente: controlla target framework, runtime pack, eventuali pin in progetto e il contenuto dell’output.

dotnet --list-runtimes

dotnet publish -c Release -r linux-x64 --self-contained true

La verifica non si chiude quando la pipeline diventa verde. Devi sapere quale versione di runtime è finita nell’output, quale artefatto è stato distribuito e quale release sta effettivamente servendo traffico. La documentazione sulla selezione della versione .NET spiega perché la scelta del runtime avviene durante la pubblicazione self-contained, non al momento dell’avvio sul server.

Container: la patch del nodo non cambia l’immagine

Per i container il problema si ripresenta con un involucro diverso. Aggiornare il runtime dell’host o scaricare una nuova immagine base nel registry non sostituisce automaticamente i layer dell’immagine già distribuita. Serve ricostruire l’immagine usando la base corretta, pubblicarla, ridistribuirla e verificare che i pod o i container in esecuzione utilizzino davvero il nuovo digest.

Se la pipeline fa affidamento su tag mobili, registrare il digest dell’immagine in produzione diventa ancora più importante: due build con lo stesso tag non sono necessariamente lo stesso artefatto. Il risultato da verificare non è il nome della tag, ma l’immagine effettivamente avviata.

Tarball Linux e source-build: il packaging è parte della sicurezza

La seconda vulnerabilità mostra un confine diverso. Per .NET 10 e .NET 11, Microsoft limita l’impatto dei metadati di ownership ai tarball destinati ai source-build. Per .NET 8 e .NET 9 rientrano anche le distribuzioni ASP.NET Core ottenute dai relativi tarball, persino quando non si compila .NET dai sorgenti. Applicare una regola generica a tutte le installazioni Linux porterebbe a due errori opposti: sottovalutare un’installazione interessata oppure creare un allarme senza base.

Il tarball non è soltanto un contenitore neutro di file. Proprietà e permessi partecipano alla superficie di sicurezza del processo di installazione. Se il percorso di distribuzione usa questi artefatti, va aggiornato il pacchetto corretto e va verificata la procedura di estrazione e installazione, non soltanto la versione stampata da un comando.

Il 13 ottobre non bastava: la patch va verificata anche dopo il rilascio

C’è un secondo insegnamento nel bollettino: Microsoft ha dichiarato che gli aggiornamenti del 13 ottobre 2026 non avevano risolto completamente i problemi relativi a SocketAsyncEventArgs e al debugger Blazor WebAssembly. Le correzioni sono state riproposte il 25 ottobre. Non serve trasformare questo fatto in una teoria sulla qualità del software: basta prenderlo sul serio come vincolo operativo.

Una checklist che si ferma alla data dell’ultimo aggiornamento installato non può distinguere una correzione completa da una successivamente rivista. È necessario associare il bollettino alla versione finale distribuita, controllare eventuali revisioni dell’advisory e conservare traccia dell’artefatto verificato. La stessa logica vale quando si legge che una patch installata non è necessariamente la patch attiva: qui, però, il confine è ancora più netto perché può attraversare la build.

Una procedura sensata, senza inventarsi un audit

La domanda corretta per un team non è “abbiamo aggiornato .NET?”. È una sequenza verificabile che collega il bollettino al deployment. Prima di dichiarare chiusa questa manutenzione, servono almeno questi passaggi:

• Inventario: identifica applicazioni, versioni target, modalità di publish, immagini container, eventuali tarball e dipendenze Brotli.
• Esposizione: individua dove vengono decompresse richieste o risposte Brotli non attendibili; non confondere presenza della libreria con raggiungibilità.
• Correzione: aggiorna runtime framework-dependent e riavvia; ricompila e ripubblica self-contained; ricostruisci e ridistribuisci container; sostituisci i tarball pertinenti.
• Provenienza: registra versione SDK/runtime pack della build, digest dell’immagine o identificativo dell’artefatto e commit da cui proviene.
• Verifica: controlla il processo e il deployment realmente in servizio, esegui test di regressione sulle funzioni di decompressione utilizzate e verifica i rollback possibili.
• Tracciabilità: collega l’evidenza di produzione al bollettino del 25 ottobre e alle correzioni ripubblicate rispetto al 13 ottobre.

Questo non sostituisce un assessment di sicurezza né prova da solo l’assenza di altre vulnerabilità. Serve a evitare una forma di autoinganno molto comune: misurare un’operazione amministrativa e scambiarla per la riduzione del rischio. In un sistema con più ambienti, immagini e modalità di pubblicazione, l’aggiornamento va osservato fino all’ultimo passaggio.

La patch non è una proprietà del server

La manutenzione di sicurezza è spesso raccontata come un gesto: scarichi, installi, riavvii, spunti la casella. Ma un’applicazione moderna può portarsi dietro runtime, librerie native e file di packaging che non cambiano insieme al sistema operativo. E allora la casella spuntata descrive soltanto quello che hai fatto, non quello che hai corretto.

Le release straordinarie .NET del 25 ottobre 2026 sono importanti per i problemi che risolvono. Sono ancora più utili come promemoria architetturale: la superficie da proteggere è l’artefatto che gira in produzione. Il resto, compresa la schermata degli aggiornamenti del server, viene dopo.