Microsoft .NET, quattro falle corrette fuori ciclo: patch di ottobre incomplete

🛡️ Executive Summary

• Microsoft distribuisce aggiornamenti straordinari per .NET 8, 9, 10 e 11 RC3, correggendo quattro vulnerabilità dopo il Patch Tuesday del 13 ottobre.
• La falla CVE-2026-111497 interessa la decompressione Brotli, mentre un secondo problema colpisce determinati pacchetti Linux.
• Le applicazioni self-contained, i container e alcuni componenti Blazor richiedono aggiornamenti specifici: installare il runtime sul server può non bastare.

Microsoft torna a correggere .NET appena dodici giorni dopo il Patch Tuesday di ottobre. Il 25 ottobre 2026 il gruppo ha pubblicato un aggiornamento straordinario per .NET 8, .NET 9, .NET 10 e .NET 11 Release Candidate 3, intervenendo su quattro vulnerabilità che coinvolgono la decompressione Brotli, le distribuzioni Linux, la gestione dei socket Windows e il debugger di Blazor WebAssembly. La particolarità del rilascio non riguarda soltanto la gravità dei difetti: due vulnerabilità erano già state affrontate il 13 ottobre, ma Microsoft ha riconosciuto che le correzioni non erano sufficienti. Il problema riguarda quindi anche amministratori e sviluppatori che avevano già completato gli aggiornamenti mensili, soprattutto dove applicazioni e container incorporano versioni autonome del runtime.

Microsoft corregge nuovamente due vulnerabilità del Patch Tuesday

Il bollettino ufficiale di Microsoft sugli aggiornamenti straordinari conferma che il nuovo pacchetto non si limita a risolvere le vulnerabilità emerse dopo la distribuzione ordinaria di ottobre. Microsoft ha infatti dovuto ripubblicare anche le correzioni per CVE-2026-70197 e CVE-2026-102870, rispettivamente associate a una corruzione della memoria nella gestione dei socket e a un problema di esecuzione di codice attraverso il debugger Blazor WebAssembly. Nel primo caso il difetto interessa particolari operazioni asincrone di rete su Windows e può consentire una scrittura fuori dai limiti della memoria durante la gestione dei datagrammi IPv4 e IPv6; nel secondo il rischio riguarda il processo attraverso il quale il debugger elabora espressioni contenenti dati manipolabili, aprendo la possibilità di eseguire codice nel contesto dell’ambiente di sviluppo. Non significa che ogni applicazione Blazor accessibile online sia vulnerabile a un attacco remoto senza condizioni: la sfruttabilità dipende dal componente coinvolto e dalle operazioni effettuate durante il debugging. Il nuovo intervento integra il Patch Tuesday di ottobre, che aveva già corretto oltre 1.400 vulnerabilità nei prodotti Microsoft, ma introduce un elemento particolarmente delicato per la gestione aziendale: una macchina aggiornata il 13 ottobre può richiedere ulteriori interventi per risultare protetta dalle quattro CVE interessate.

Leggi anche: .NET 11 RC1 entra nella fase finale e Microsoft corregge otto vulnerabilità

La vulnerabilità Brotli espone i processi alla corruzione della memoria

La nuova CVE-2026-111497, classificata con severità alta e punteggio CVSS 8.1, riguarda un buffer overflow nella libreria utilizzata da .NET per la decompressione Brotli. Il difetto può consentire a un attaccante non autenticato di leggere o corrompere la memoria del processo vulnerabile, provocando divulgazione di informazioni, interruzione del servizio oppure elevazione dei privilegi. L’esposizione non è però universale: la vulnerabilità interessa le applicazioni che elaborano dati Brotli controllabili dall’attaccante attraverso ASP.NET Core Request Decompression, HttpClient oppure le API System.IO.Compression. Microsoft precisa che le funzionalità di decompressione automatica delle richieste e delle risposte HTTP non sono abilitate nelle configurazioni predefinite interessate. Di conseguenza, non tutti i server ASP.NET Core sono automaticamente sfruttabili, ma le applicazioni che attivano queste funzionalità o utilizzano direttamente il decoder devono essere verificate. Il problema può estendersi agli eseguibili compilati con NativeAOT, nei quali il componente vulnerabile viene incorporato durante la compilazione. In questi ambienti aggiornare il runtime condiviso non sostituisce il codice già presente nel programma. La distinzione richiama i precedenti problemi di sicurezza di ASP.NET Core che avevano interessato anche software di terze parti, mostrando quanto una dipendenza applicativa possa trasferire il rischio a prodotti che non vengono immediatamente identificati come componenti Microsoft.

Linux presenta una falla separata nei pacchetti di distribuzione

La seconda nuova vulnerabilità, CVE-2026-114148, interessa i metadati relativi alla proprietà dei file contenuti in determinati archivi tarball Linux. Un attaccante locale potrebbe sfruttare una gestione non sicura dell’ownership per modificare file e ottenere privilegi superiori a quelli autorizzati. Microsoft distingue esplicitamente le distribuzioni coinvolte: per .NET 8 e .NET 9 risultano interessati anche specifici archivi ASP.NET Core Runtime e targeting pack, mentre per .NET 10 e .NET 11 il problema riguarda le distribuzioni Linux prodotte attraverso processi di compilazione dai sorgenti. Non è quindi corretto classificare come vulnerabile qualsiasi installazione Linux di .NET, perché il rischio dipende dalla provenienza dei pacchetti e dalla modalità di distribuzione. Il problema assume maggiore importanza per le organizzazioni che utilizzano immagini personalizzate, repository interni e infrastrutture di compilazione automatizzata, dove gli artefatti vengono conservati e riutilizzati anche dopo la disponibilità di una correzione. Un sistema operativo aggiornato può continuare a ospitare applicazioni costruite con componenti precedenti, mentre la semplice sostituzione di una libreria non garantisce la bonifica di tutti i pacchetti generati. La gestione della vulnerabilità richiede quindi di verificare origine dei tarball, versioni incorporate e pipeline di distribuzione, evitando di confondere la sicurezza del sistema host con quella degli artefatti applicativi.

Le versioni corrette cambiano anche la manutenzione dei container

Le release distribuite da Microsoft sono .NET 8.0.33, .NET 9.0.22, .NET 10.0.14 e .NET 11 RC3. Per le applicazioni framework-dependent occorre aggiornare il runtime utilizzato e riavviare i processi, mentre per quelle self-contained è necessario ricompilare e ripubblicare il software perché il runtime viene distribuito insieme all’applicazione. Lo stesso principio interessa i container, che devono essere ricostruiti utilizzando immagini aggiornate prima di procedere alla ridistribuzione. Anche le applicazioni NativeAOT richiedono una nuova compilazione, mentre i componenti Blazor interessati dalla correzione devono essere verificati a livello di dipendenze NuGet, perché aggiornare soltanto il runtime non sostituisce automaticamente i pacchetti utilizzati dal progetto. Il comando dotnet --list-runtimes consente di controllare le versioni condivise installate, ma non individua necessariamente quelle incorporate negli eseguibili autonomi o nelle immagini containerizzate. È proprio questa differenza a rendere più complesso il patch management: l’aggiornamento del server non coincide sempre con l’aggiornamento dell’applicazione. Gli amministratori devono inoltre controllare che le nuove build siano effettivamente entrate negli ambienti di produzione, perché la presenza di una versione corretta nella pipeline di sviluppo non garantisce che sia già utilizzata dai servizi esposti.

Continua con:

Windows, Patch Tuesday record: zero-day sfruttata, VPN corretta e RDP rotto

Imprese e pubbliche amministrazioni devono verificare i software distribuiti

Per imprese, software house e pubbliche amministrazioni italiane il rischio principale riguarda l’inventario delle dipendenze e la capacità di intervenire sui prodotti gestiti da fornitori esterni. Applicazioni gestionali, portali web e servizi API possono utilizzare versioni differenti di .NET, comprese distribuzioni autonome non immediatamente visibili attraverso gli strumenti di aggiornamento del sistema operativo. Per questo motivo la verifica deve coinvolgere non soltanto gli amministratori dei server, ma anche i responsabili dello sviluppo applicativo e i fornitori che mantengono gli ambienti di produzione. Non risultano, nella comunicazione Microsoft consultata, campagne di sfruttamento attivo confermate per le quattro vulnerabilità, e sarebbe quindi scorretto descrivere il rilascio come una risposta a compromissioni già accertate. La priorità rimane comunque elevata perché il nuovo pacchetto corregge difetti potenzialmente importanti e sostituisce interventi precedenti risultati incompleti. Il rilascio straordinario dimostra soprattutto che la sicurezza degli ambienti .NET non può essere valutata soltanto attraverso la data dell’ultimo Patch Tuesday: conta la versione realmente eseguita da ciascuna applicazione, comprese quelle che incorporano componenti non aggiornabili attraverso il sistema host.