CVE-2026-62869: spoofing dell'identità in Entra ID

Cos'è la vulnerabilità di spoofing dell'identità CVE-2026-62869 in Entra ID

La vulnerabilità di spoofing dell'identità CVE-2026-62869 in Entra ID è una falla che Microsoft ha corretto nell'ambito del proprio pacchetto di aggiornamenti di sicurezza di agosto 2026. La descrizione dell'avviso ufficiale di Microsoft, ripubblicata da diversi tracker di vulnerabilità, è diretta: «Una verifica insufficiente dell'autenticità dei dati in Azure Entra ID consente a un attaccante autorizzato di eseguire spoofing sulla rete.» Il Security Update Guide di Microsoft la classifica come Critica; il monitoraggio indipendente basato su CVSS (NVD, Tenable, Mallory.ai) colloca il punteggio base CVSS v3.1 a 8,8, che rientra nella fascia di gravità standard «Alta». La falla è classificata sotto CWE-345, Verifica insufficiente dell'autenticità dei dati — una classe di debolezza che MITRE definisce come un prodotto che «non verifica sufficientemente l'origine o l'autenticità dei dati, in un modo che lo porta ad accettare dati non validi».

✅ Già corretta, nessuna azione necessaria: Microsoft dichiara che il problema è già stato completamente mitigato lato servizio — non è richiesta alcuna applicazione di patch, modifica di configurazione o altra azione lato cliente. Si tratta di una spiegazione retrospettiva di una falla che Microsoft ha già chiuso all'interno della propria infrastruttura Entra ID, non di una minaccia attiva che richieda una risposta di emergenza oggi.

Cronologia della divulgazione

6 agosto 2026 — La vulnerabilità emerge per la prima volta in un lotto iniziale di aggiornamenti di sicurezza Microsoft (secondo il monitoraggio degli avvisi di Feedly e la copertura di TheWindowsUpdate.com).
11 agosto 2026 — Data di pubblicazione formale registrata dal monitoraggio di intelligence sulle vulnerabilità di Tenable, in coincidenza con il Patch Tuesday di quel mese. La revisione di Zero Day Initiative ha conteggiato 398 nuove CVE Microsoft pubblicate quel giorno, di cui 62 classificate come Critiche.
13 agosto 2026 — Data dell'ultimo aggiornamento secondo il monitoraggio di Tenable.

CVE-2026-62869 non era la vulnerabilità sotto attacco attivo quel mese — la revisione di Zero Day Initiative attribuisce questa distinzione alla non correlata CVE-2026-68820 (una falla di elevazione dei privilegi nel driver Ancillary Function Driver for WinSock di Windows), e precisa esplicitamente che CVE-2026-62869 «non era pubblicamente nota né sotto attacco attivo al momento della pubblicazione».

Cosa significa «verifica insufficiente dell'autenticità dei dati» (CWE-345)

Microsoft non ha pubblicato un'analisi tecnica della causa radice per CVE-2026-62869 e — a differenza di altre recenti CVE di Entra ID — al momento della stesura di questo articolo non è emersa pubblicamente alcuna analisi indipendente dei ricercatori sull'esatta catena di sfruttamento. Ciò che i dati dell'avviso stabiliscono è la categoria del bug: CWE-345, una classe di debolezza che MITRE colloca direttamente sotto CWE-693 (Fallimento del meccanismo di protezione), accanto a debolezze correlate come CWE-346 (Errore di convalida dell'origine) e CWE-347 (Verifica non corretta della firma crittografica).

In pratica, questa classe di falla si presenta nelle piattaforme di identità ogni volta che un servizio accetta un'asserzione — un token, un'attestazione, un segnale di delega, un'interazione legata all'identità — senza confermare adeguatamente che tale asserzione provenga realmente da dove dichiara di provenire. Il meccanismo specifico varia: può trattarsi di una firma non verificata, di un campo emittente o destinatario non convalidato, oppure di un confine di fiducia tra tenant o servizi che non viene applicato con il rigore dovuto. EtcSec ha già trattato un esempio concreto di questo schema generale: CVE-2025-55241, dove un tipo di token interno a Entra ID e una lacuna nella convalida del tenant in un'API legacy si sono combinati per consentire a un attaccante di impersonare qualsiasi Amministratore Globale su tutti i tenant, e più di recente CVE-2026-59115, due falle Critiche di elevazione dei privilegi nel servizio di provisioning di Entra. Questi casi sono utili per capire perché i bug imparentati con CWE-345 siano pericolosi in una piattaforma di identità — un singolo presupposto di fiducia non applicato può compromettere ogni controllo a valle — ma le loro esatte catene tecniche non si trasferiscono a CVE-2026-62869; ciascuna è una vulnerabilità distinta con una propria causa radice, e questo articolo non presume il contrario.

ℹ️

ℹ️ Nota: il vettore CVSS e la classificazione CWE sono fatti pubblicati da Microsoft/NVD. Il percorso dati specifico sfruttato all'interno di Entra ID per CVE-2026-62869 non è stato divulgato da Microsoft, e questo articolo non ne inventa uno.

Perché ha ottenuto 8,8: leggere il vettore CVSS

Il vettore CVSS v3.1 per CVE-2026-62869, secondo il monitoraggio di Tenable, è AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Ogni componente indica qualcosa di concreto su ciò che un exploit avrebbe richiesto:

Metrica	Valore	Cosa significa
Vettore di attacco	Rete (N)	Sfruttabile da remoto, senza necessità di accesso locale o di rete adiacente
Complessità dell'attacco	Bassa (L)	Nessuna condizione speciale o tempistica richiesta oltre alla falla stessa
Privilegi richiesti	Bassi (L)	L'attaccante deve essere un principal «autorizzato» (autenticato) — non un attore anonimo e non autenticato
Interazione dell'utente	Nessuna (N)	Non è richiesto alcun clic, approvazione o azione da parte della vittima
Ambito	Invariato (U)	L'impatto rimane all'interno dell'autorità di sicurezza propria del componente vulnerabile
Riservatezza / Integrità / Disponibilità	Alta / Alta / Alta	Uno spoofing riuscito potrebbe leggere, alterare e interrompere dati o interazioni legate all'identità

Cosa significa qui «attaccante autorizzato»

La metrica «Privilegi richiesti: Bassi» è il dettaglio su cui vale la pena soffermarsi: non si trattava di una falla che un estraneo poteva innescare senza alcuna impronta nel tenant. Richiedeva un attaccante già in possesso di una qualche forma di accesso autenticato e autorizzato — la formulazione stessa dell'avviso è «un attaccante autorizzato» — che usasse quella posizione per falsificare dati o interazioni legate all'identità che Entra ID avrebbe dovuto verificare con maggior rigore. Il punteggio EPSS di Tenable per questa CVE si attesta intorno allo 0,4%, e il monitoraggio di intelligence sulle vulnerabilità di Mallory.ai non riporta alcun codice exploit proof-of-concept pubblico identificato per essa, coerentemente con una falla corretta prima di aver attirato attenzione significativa al di fuori del fornitore.

Rilevamento: su cosa costruire visibilità

Poiché Microsoft ha chiuso il percorso di accesso sottostante sulla propria infrastruttura prima che questa CVE venisse assegnata, non esiste alcun indicatore di compromissione lato tenant, query KQL o Event ID pubblicato da Microsoft o da ricercatori indipendenti per questa falla specifica — e questo articolo non ne inventerà uno. Ciò che è realmente attuabile, invece, è assicurarsi che il proprio tenant disponga della telemetria necessaria per rilevare questa categoria di problema — un principal autenticato che riesce a falsificare o simulare con successo un'interazione legata all'identità — che si tratti di questa CVE, di una variante che Microsoft non ha ancora individuato, o di un bug completamente diverso ma della stessa natura.

Segnale	Dove si trova	Perché è rilevante qui
Accessi a rischio e rilevamenti di rischio	Entra ID Protection	Segnala gli accessi e le interazioni che i modelli di rilevamento propri di Microsoft considerano anomali per l'account, indipendentemente dal superamento della MFA
Criteri di rischio di accesso dell'Accesso Condizionale	`SignInLogs` di Entra / report sui criteri CA	Conferma che i criteri basati sul rischio stiano effettivamente applicandosi, e non solo registrando, quando una sessione appare falsificata o fuori pattern
Attività di accesso di entità servizio e applicazioni	`AuditLogs`, `SignInLogs` di Entra (non interattivi)	I percorsi autenticati e a basso privilegio da servizio a servizio sono esattamente il tipo di principal descritto da un caso di abuso «attaccante autorizzato» come questo
Stato di applicazione della protezione dei token	Report dell'Accesso Condizionale	Mostra se il tenant vincola i token al dispositivo richiedente, riducendo ciò che un token falsificato o riprodotto può fare anche se emesso

Questa è la stessa impostazione che EtcSec raccomanda dopo aver analizzato i rilevamenti di rischio di accesso di Entra ID per il replay di token AiTM e i pattern di viaggio impossibile: le singole tecniche di attacco cambiano, ma la risposta difensiva — osservare realmente i segnali di rischio invece di limitarsi a registrarli — resta costante.

Cosa non copre questa guida al rilevamento

Nessuno dei segnali sopra elencati è un indicatore specifico per CVE-2026-62869 — Microsoft non ne ha pubblicato alcuno, e questo elenco non va letto come una regola di rilevamento per questo bug in particolare. Consideratelo come la base generale di telemetria dell'identità che offre una possibilità di rilevare il prossimo bypass della verifica di autenticità, questo incluso, qualora non fosse già stato corretto lato server.

Rimedio

Non c'è nulla da correggere per CVE-2026-62869 in sé — la correzione di Microsoft è già distribuita sull'intero tenant, e nessuna modifica di configurazione chiude o riapre nulla lato vostro. Il lavoro duraturo consiste nel ridurre ciò che qualsiasi futuro bug di verifica dell'autenticità in Entra ID potrebbe fare all'interno del vostro tenant:

💡

💡 Vittoria rapida: se i vostri criteri di rischio dell'Accesso Condizionale sono in modalità solo report invece di essere applicati, questo è il divario più conveniente da colmare per primo — è il controllo più direttamente mirato a individuare un «attaccante autorizzato» che si comporta come uno non autorizzato.

Attivate e applicate l'Accesso Condizionale basato sul rischio, coprendo sia il rischio di accesso sia il rischio utente, anziché lasciare Identity Protection in modalità solo report o audit. Un criterio che si limita a osservare il comportamento a rischio non impedisce un'interazione falsificata proveniente da un principal già autenticato.
Gestite gli accessi a rischio invece di lasciarli accumulare. Il valore di Identity Protection crolla se le code di utenti e accessi a rischio non vengono attivamente esaminate e corrette — una coda mai revisionata equivale funzionalmente a nessun rilevamento.
Abilitate la protezione dei token dell'Accesso Condizionale ovunque la licenza e il supporto applicativo lo consentano. Vincolare i token al dispositivo richiedente riduce ciò che un token falsificato o riprodotto con successo — di questa categoria di bug o di un'altra — può fare altrove.
Bloccate l'autenticazione legacy sull'intero tenant. I protocolli legacy non supportano la convalida moderna dei token né l'applicazione dell'Accesso Condizionale, eludendo così esattamente il tipo di verifiche di autenticità di cui tratta questa classe di CVE. L'analisi di EtcSec sulle lacune comuni dell'Accesso Condizionale illustra come le eccezioni di autenticazione legacy e i vuoti di ambito riaprano silenziosamente questa esposizione anche nei tenant che credono di averla chiusa.
Confermate che il vostro tenant non abbia ereditato impostazioni predefinite non sicure. I nuovi tenant Entra possono ancora essere distribuiti con l'autenticazione legacy consentita e i Security Defaults disabilitati; consultate la guida di EtcSec sull'hardening del tenant Azure per la baseline che ogni tenant dovrebbe verificare, indipendentemente da qualsiasi singola CVE.

Perché questo non riguarda solo questa CVE

Nessuno di questi passaggi dipende specificamente da CVE-2026-62869 — Microsoft ha già chiuso quella porta. Sono importanti perché «un attaccante autenticato falsifica un'interazione legata all'identità che Entra ID avrebbe dovuto verificare» è uno schema di bug ricorrente nelle grandi piattaforme di identità, non un evento isolato.

Come EtcSec rileva questo problema

L'audit Entra ID di EtcSec non ha visibilità sulla logica di verifica lato servizio propria di Microsoft — quell'infrastruttura è interamente all'interno del control plane di Microsoft, e non è mai stata qualcosa che un audit lato tenant potesse osservare o correggere direttamente. Ciò che EtcSec verifica continuamente è la postura lato tenant che determina quanti danni possa causare qualsiasi bug della classe spoofing o bypass dell'autenticità: se esistono e si applicano criteri di Accesso Condizionale basati sul rischio di accesso (CA_NO_RISK_BASED_SIGNIN), se gli accessi a rischio vengono effettivamente indagati (RISK_SIGNINS_NOT_INVESTIGATED), se la protezione dei token dell'Accesso Condizionale è configurata (CA_TOKEN_PROTECTION_DISABLED), se l'autenticazione legacy è ancora consentita al di fuori dell'applicazione dell'Accesso Condizionale (CA_NO_LEGACY_AUTH_BLOCK), e se Identity Protection stessa è configurata (AZ_IDENTITY_PROTECTION_DISABLED).

ℹ️

ℹ️ Nota: EtcSec verifica automaticamente queste condizioni a ogni audit Azure/Entra. Eseguite un audit gratuito per scoprire se la postura di rilevamento e hardening del vostro tenant intercetterebbe il prossimo bypass della verifica di autenticità — o lo lascerebbe passare inosservato.