CVE-2026-62911: perché l'85 per cento dei server Exchange on-premises è vulnerabile e cosa c'è dietro dal punto di vista tecnico

Alla fine di agosto 2026, il CERT-Bund del BSI ha pubblicato un dato che fa riflettere: circa l’85 per cento dei server Exchange on-premises in Germania è vulnerabile alla falla CVE-2026-62911. Dal 14 agosto, l’autorità sta notificando gli operatori di rete interessati. Il motivo è la pubblicazione di un proof of concept che consente la compromissione completa del sistema. Dietro l’asettico numero CVE si cela una delle falle Exchange più interessanti degli ultimi anni: un attacco relay attraverso un endpoint che la maggior parte degli amministratori non ha sul radar. Questo articolo spiega il meccanismo, contestualizza i dati del BSI e descrive la procedura concreta.

Chi desidera soltanto inquadrare l’aggiornamento di sicurezza dell’11 agosto 2026 trova una panoramica di tutte e sette le CVE, comprese build e disattivazione di OWA Light, nell’articolo sull’aggiornamento di sicurezza di agosto. Qui esaminiamo nel dettaglio l’unica falla critica.

Cos’è realmente CVE-2026-62911

Microsoft classifica CVE-2026-62911 come Elevation of Privilege con un punteggio CVSS di 8.0 e la considera l’unica vulnerabilità Critical del Patch Tuesday di agosto. Una descrizione più precisa è fornita dalla categoria CWE: CWE-294, «Authentication Bypass by Capture-Replay». L’attaccante non aggira l’autenticazione indovinando una password, ma intercettando un’autenticazione valida di un altro account e riutilizzandola contro un endpoint di destinazione. In pratica, si tratta di un classico attacco NTLM relay.

La falla è stata scoperta da Orange Tsai del team di ricerca DEVCORE. L’ha dimostrata durante la competizione Pwn2Own Berlin 2026, come parte di una catena di tre vulnerabilità che insieme consentivano l’esecuzione di codice remoto con privilegi SYSTEM sul server Exchange. Proprio questa combinazione spiega l’apparente contraddizione in molte segnalazioni: considerata isolatamente, CVE-2026-62911 è un’escalation dei privilegi che presuppone un contesto già autenticato. In combinazione con una tecnica di coercizione che forza anzitutto l’autenticazione, diventa un attacco non autenticato dalla rete. Il PoC sfrutta esattamente questa combinazione.

Il nocciolo: MRSProxy senza Channel Binding

L’endpoint vulnerabile si chiama MRSProxy, abbreviazione di Mailbox Replication Service Proxy. Exchange lo mette a disposizione per consentire lo spostamento delle cassette postali tra server e, in ambienti ibridi, tra on-premises ed Exchange Online. MRSProxy accetta l’autenticazione Negotiate, ma non verifica i cosiddetti Channel Bindings. Ed è proprio questa verifica il cuore del problema.

Il Channel Binding collega l’autenticazione al canale TLS sottostante. In termini semplificati, il client inserisce nei dati di autenticazione un’impronta crittografica della connessione TLS. Il server verifica se tale impronta corrisponde alla connessione attraverso cui arrivano i dati. Se non corrisponde, l’autenticazione è avvenuta tramite un canale diverso da quello dichiarato e il server la rifiuta. Questa procedura costituisce la base tecnica di Extended Protection for Authentication. In assenza della verifica, un’autenticazione intercettata altrove può essere inoltrata all’endpoint e l’attaccante viene quindi trattato come l’account originale.

Il punto decisivo per l’esercizio: questa falla esisteva nonostante Extended Protection fosse già attivo per impostazione predefinita nelle versioni attuali di Exchange. L’endpoint MRSProxy costituiva un’eccezione nella protezione; non imponeva il Channel Binding che altri endpoint applicano. L’aggiornamento di sicurezza chiude esattamente questa lacuna facendo sì che MRSProxy esegua la verifica. Per questo non esiste nemmeno un workaround tramite Exchange Emergency Mitigation: l’aggiornamento di agosto è la correzione.

Come si svolge l’attacco

Il proof of concept pubblicato combina quattro elementi. Ognuno è noto; è la loro interazione a costituire l’attacco.

Nel primo passaggio, l’attaccante induce il server Exchange ad autenticarsi autonomamente. A tal fine utilizza la tecnica di coercizione PetitPotam tramite l’interfaccia RPC di stampa MS-EFSR: una chiamata predisposta induce il server ad autenticarsi presso l’attaccante con il proprio account computer. Questo account dispone di privilegi elevati sul sistema Exchange. Nel secondo passaggio, l’attaccante inoltra immediatamente questo accesso all’endpoint MRSProxy, invece di rispondervi direttamente. Poiché MRSProxy non verifica il Channel Binding (passaggio tre), Exchange accetta l’accesso inoltrato, anche se proviene da un canale completamente diverso. L’attaccante agisce ora con i privilegi dell’account server e nel quarto passaggio può scrivere un file, solitamente una webshell ASPX, ed eseguire tramite essa codice arbitrario come SYSTEM.

Il risultato è la compromissione completa del server. Dal punto di vista delle vittime, ciò significa accesso a tutte le cassette postali: leggere e inviare e-mail, scaricare allegati, indipendentemente dal singolo utente. Un server Exchange non è quindi più un sistema di posta isolato, bensì un piede nella porta dell’Active Directory sottostante.

Versioni interessate e patch

Sono interessate tutte le configurazioni on-premises supportate. L’aggiornamento di sicurezza dell’11 agosto 2026 porta i server alle seguenti build:

Qui risiede la vera causa dell’elevato tasso di vulnerabilità. Exchange Server 2016 e 2019 sono fuori dal supporto regolare dall’ottobre 2025. Gli aggiornamenti di sicurezza da maggio a ottobre 2026 sono disponibili solo per chi è iscritto al programma a pagamento Extended Security Updates (Period 2). Secondo il BSI, in Germania sono noti soltanto nove server Exchange 2016/2019 sui quali è stata installata una patch tramite questo programma. Tutti gli altri restano semplicemente senza patch.

Exchange Online non è interessato dalla falla; Microsoft ha già messo in sicurezza il lato cloud. Negli ambienti ibridi, tuttavia, l’aggiornamento deve essere installato su ogni server on-premises, compresi i server di sola gestione e le macchine su cui sono installati soltanto gli Exchange Management Tools.

Leggere correttamente i dati del BSI

La rilevazione proviene dal CERT-Bund, che determina lo stato delle patch dei server Exchange raggiungibili da Internet tramite scansioni proprie e dati di partner. Tre numeri sono centrali e sono correlati.

Primo: alla fine di ottobre 2025, il 92 per cento dei circa 33’000 server Exchange on-premises in Germania eseguiva una versione non più supportata. Questa è la situazione strutturale di partenza. Secondo: circa l’85 per cento di questi server è vulnerabile a CVE-2026-62911 perché non dispone della patch di agosto. Terzo: solo nove server sono dimostrabilmente patchati tramite il programma ESU Period 2. I numeri descrivono lo stesso quadro da due prospettive. Gran parte dei server non è senza patch perché un aggiornamento è stato trascurato, ma perché per la versione in uso non ne esiste più uno regolare. Il vero ritardo non è una lacuna nelle patch, ma una lacuna nella migrazione.

Per la Svizzera non esiste una rilevazione altrettanto capillare. La situazione di partenza è tuttavia strutturalmente simile, poiché anche qui Exchange 2016 e 2019 sono molto diffusi e sono ugualmente fuori supporto dall’ottobre 2025. L’NCSC (Ufficio federale della cibersicurezza) raccomanda sistematicamente l’installazione immediata degli aggiornamenti in caso di falle critiche sfruttabili attivamente. Chi gestisce Exchange on-premises 2016 o 2019 in Svizzera si trova davanti alla stessa decisione degli operatori tedeschi: effettuare le patch tramite ESU come soluzione transitoria, quindi migrare.

Cosa fare ora

Le misure sono chiare e hanno senso nel seguente ordine.

Installate l’aggiornamento di sicurezza di agosto su tutti i server Exchange. Per Exchange SE si tratta di un aggiornamento regolare e pubblico. Per Exchange 2016 e 2019 richiede l’iscrizione al programma ESU Period 2; senza questa iscrizione, la patch non è disponibile. Per questa falla non esiste una procedura alternativa tramite Exchange Emergency Mitigation.

Verificate che Extended Protection sia attivo e configurato correttamente su tutti gli endpoint. È la protezione strutturale e duratura contro attacchi relay di questo tipo e li blocca dove il Channel Binding ha effetto. L’aggiornamento e Extended Protection non si sostituiscono a vicenda: la patch chiude la falla specifica di MRSProxy, mentre Extended Protection rafforza l’autenticazione nel complesso. Entrambi sono necessari.

Limitate l’accesso da Internet ai servizi Exchange basati sul web. Un server i cui endpoint di gestione e replica non siano raggiungibili apertamente dalla rete, ad esempio perché accessibili solo tramite VPN, sottrae a questo attacco la sua base. Ciò non sostituisce l’aggiornamento, ma riduce sensibilmente la superficie di attacco.

E la vera conseguenza dei dati del BSI: pianificate la migrazione da Exchange 2016/2019. Il programma ESU è un ponte fino a ottobre 2026, non una condizione permanente. Chi oggi effettua le patch nel programma ESU acquista tempo per il passaggio ordinato a Exchange SE o a Exchange Online, niente di più. Ogni ulteriore mese su una versione non più supportata prolunga il periodo in cui la prossima falla colpirà senza una patch disponibile.