CVE-2026-69836 Entra ID Vulnerabilità: RCE CVSS 10.0

CVE-2026-69836 Entra ID Vulnerabilità: cosa è successo e perché è importante

Il 20 agosto 2026, Microsoft ha pubblicato un avviso per CVE-2026-69836, una vulnerabilità in Microsoft Entra ID che ha ottenuto un punteggio CVSS perfetto di 10.0. Il titolo ufficiale è diretto: "Microsoft Entra ID Remote Code Execution Vulnerability" (vulnerabilità di esecuzione di codice remoto in Microsoft Entra ID). Secondo lo stesso avviso di Microsoft, la causa principale è una deserializzazione di dati non affidabili, e l'impatto è l'esecuzione di codice remoto da parte di un attaccante non autenticato sulla rete — senza credenziali, senza interazione dell'utente, senza accesso preliminare richiesto.

Per il provider di identità di un tenant, questa combinazione è pressoché il peggio che una valutazione possa raggiungere. Entra ID è il piano di controllo che emette ogni token, valuta ogni policy di Accesso Condizionale e regola ogni attivazione di ruolo privilegiato in un ambiente Microsoft 365 o Azure. Una falla di esecuzione di codice remoto in questo piano di controllo, raggiungibile senza autenticazione, è sulla carta un allarme massimo.

Ma si tratta anche di un CVE di un servizio cloud, e questo cambia le regole del gioco. Non c'è nessuna patch da scaricare, nessun articolo KB, nessuna finestra di manutenzione. Microsoft ha corretto il codice vulnerabile lato server prima ancora che la maggior parte dei difensori avesse visto l'avviso. Questo unico fatto — niente da installare — è esattamente ciò che rende questo CVE degno di una lettura attenta piuttosto che di uno sguardo veloce.

Dentro la falla: deserializzazione CWE-502 e un punteggio CVSS perfetto

Microsoft classifica CVE-2026-69836 sotto CWE-502, Deserialization of Untrusted Data (deserializzazione di dati non affidabili). In termini semplici: da qualche parte nel servizio Entra ID, i dati in ingresso venivano riconvertiti in oggetti attivi senza convalidare a sufficienza la loro provenienza o il loro contenuto. I bug di deserializzazione sono una classe ben nota di primitiva di esecuzione di codice remoto — gli attaccanti costruiscono un payload serializzato malevolo che, una volta ricostruito dal codice vulnerabile, esegue logica arbitraria invece di limitarsi a reidratare una struttura dati. È la stessa famiglia di bug dietro alcuni degli RCE Java e .NET più dannosi dell'ultimo decennio, e ora ha una voce anche in Entra ID.

Il vettore base CVSS 3.1 pubblicato da Microsoft è:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Letto da sinistra a destra, ogni metrica raggiunge il massimo di gravità: AV:N (vettore di attacco: rete — raggiungibile da internet), AC:L (complessità dell'attacco: bassa — nessuna condizione particolare richiesta), PR:N (privilegi richiesti: nessuno — non autenticato), UI:N (interazione dell'utente: nessuna), S:C (ambito: modificato — la falla coinvolge risorse oltre il componente vulnerabile), e C:H/I:H/A:H (impatto alto su riservatezza, integrità e disponibilità). Questa combinazione produce il punteggio base di 10.0. Il punteggio temporale di Microsoft si attesta a 8.7, riflettendo le tre metriche temporali che aggiunge alla stessa stringa vettoriale — E:U (maturità del codice di exploit: non comprovata), RL:O (livello di remediation: correzione ufficiale) e RC:C (fiducia nel report: confermata) — sovrapposte a questo RCE di rete non autenticato.

Il ribaltone sullo sfruttamento: cosa ha corretto Microsoft — e perché conta più del punteggio

Ecco il dettaglio che rende questo CVE davvero istruttivo, e non solo un altro titolo di gravità critica: la cronologia delle revisioni dell'avviso di Microsoft mostra che lo stato di sfruttamento è cambiato il giorno successivo.

Revisione 1.0 — 20 agosto 2026: «Information published.» (Informazione pubblicata.)
Revisione 1.1 — 21 agosto 2026: «Corrected Exploited to No. This vulnerability was not exploited in the wild. This is an informational change only.» (Corretto il campo Sfruttata a No. Questa vulnerabilità non è stata sfruttata in condizioni reali. Si tratta solo di una modifica informativa.)

Diverse testate che hanno seguito la divulgazione il 21 agosto — tra cui Help Net Security, The Hacker News e The Register — hanno riportato il CVE in un momento in cui il suo stato di sfruttamento era ancora in evoluzione, prima che Microsoft lo fissasse definitivamente a «Exploited: No». The Register ha in particolare notato che Microsoft ha definito la correzione «informational only» (solo informativa), e che non è stato pubblicato da nessuna parte alcun dettaglio tecnico di una reale catena di attacco.

La posizione attuale e corretta di Microsoft, così come riportata nel campo Exploit Status dell'avviso, recita:

Publicly Disclosed: No
Exploited: No
Latest Software Release: Exploitation Less Likely

Perché non c'è nessuna patch da applicare — e perché non è la stessa cosa di "niente da fare"

Le FAQ di Microsoft per CVE-2026-69836 sono esplicite sul modello di remediation: «This vulnerability has already been fully mitigated by Microsoft. There is no action for users of this service to take. The purpose of this CVE is to provide further transparency.» (Questa vulnerabilità è già stata completamente mitigata da Microsoft. Non è richiesta alcuna azione da parte degli utenti di questo servizio. Lo scopo di questo CVE è fornire maggiore trasparenza.) L'avviso rimanda alla spiegazione di Microsoft sul perché i CVE dei servizi cloud funzionano in questo modo, «Toward greater transparency: Unveiling Cloud Service CVEs» (aka.ms/MSRC-Cloud-CVEs).

Questo è un modello legittimo e sempre più comune per i piani di controllo SaaS: Microsoft possiede il codice, Microsoft possiede la correzione, e il CVE esiste solo perché il settore abbia una documentazione pubblica del fatto che una falla critica sia esistita e sia stata chiusa. Il ricercatore accreditato per la scoperta, Robert Fitzpatrick, è elencato nell'avviso di Microsoft come qualcuno che ha segnalato la falla insieme a Microsoft — è stata individuata e chiusa internamente, non da un red team esterno che ha pubblicato un exploit funzionante.

Nulla di tutto ciò cancella il fatto che, per una certa finestra di tempo, nel vostro provider di identità sia esistita una primitiva di RCE non autenticata e raggiungibile via rete. "Completamente mitigata" descrive la vulnerabilità da questo momento in poi. Non dice nulla su cosa possa o meno essere accaduto durante la finestra in cui era aperta — e sebbene Microsoft affermi categoricamente che la falla "non è stata sfruttata in condizioni reali", non pubblica né le prove né la portata dietro questa conclusione.

Rilevamento: dare la caccia quando non c'è nessuna catena di attacco pubblicata

Ecco la parte scomoda: Microsoft non ha pubblicato IOC, nessuna regola di rilevamento specifica per questo CVE, né alcuna descrizione di come apparirebbe un tentativo di sfruttamento contro questa falla. Non c'è nulla contro cui verificare una firma. Questo non significa che la caccia sia inutile — significa che va costruita a partire da ciò che un RCE riuscito contro Entra ID toccherebbe plausibilmente, non da un playbook fornito dal vendor.

Cosa esaminare	Dove cercare	Perché conta qui
Accessi tra il 19 e il 22 agosto 2026 (UTC)	Log di accesso di Entra ID / `auditLogs/signIns`	Delimita la finestra di divulgazione e correzione con margine su entrambi i lati
Accessi a rischio segnalati da Identity Protection	Report delle rilevazioni di rischio di Entra ID Protection	Un RCE che si sposta verso l'emissione di token potrebbe manifestarsi come segnali di rischio anche senza una firma nota
Registrazioni app o credenziali di service principal nuove o modificate	Log di audit di Entra ID, riquadro Applicazioni	Una classica mossa di persistenza dopo aver ottenuto esecuzione di codice contro un piano di controllo dell'identità
Nuove assegnazioni di ruoli privilegiati o attivazioni PIM fuori dagli schemi abituali	Cronologia di audit PIM, log di assegnazione dei ruoli di directory	Le concessioni di privilegi inaspettate sono tra i pochi artefatti che una compromissione del piano di controllo lascerebbe
Concessioni di consenso ad app sconosciute o registrate di recente	Log di consenso delle applicazioni aziendali di Entra ID	Il consenso OAuth è un passo laterale comune non appena un attaccante ha un punto d'appoggio nello strato dell'identità

Perché la retention dei log viene prima di tutto

Prima che tutto questo sia possibile, il vostro tenant ha bisogno di log che coprano effettivamente la finestra. Se la retention dei log di audit di Entra ID del vostro tenant è breve, l'intero esercizio diventa privo di senso oltre a qualche giorno indietro.

Estrarre i dati grezzi

# Estrarre i log di accesso che coprono la finestra di divulgazione/correzione (timestamp UTC).
# Richiede il permesso AuditLog.Read.All. Gli spazi all'interno di $filter devono essere
# codificati in percentuale: curl rifiuta un URL che contiene spazi non codificati prima ancora di inviare qualcosa.
curl -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$filter=createdDateTime%20ge%202026-08-19T00:00:00Z%20and%20createdDateTime%20le%202026-08-22T00:00:00Z"

Immettete l'output nel processo di revisione delle anomalie che già usate per i dati di accesso — l'obiettivo non è una query magica, ma assicurarsi che la finestra sia effettivamente interrogabile.

Remediation: una checklist di controlli compensativi, non una patch

Non c'è nessuna patch del vendor da distribuire per CVE-2026-69836. Quello che potete fare è assicurarvi che i controlli in grado di rilevare le conseguenze di una compromissione del provider di identità — questa o la prossima — siano effettivamente attivati.

Identity Protection e Accesso Condizionale

Attivate una policy di rischio di accesso in Identity Protection. Senza di essa, Entra ID calcola segnali di rischio, ma nulla agisce su di essi.
Supportatela con una policy di Accesso Condizionale basata sul rischio che rafforzi l'autenticazione o blocchi l'accesso quando il rischio di accesso è elevato, invece di affidarvi solo al punteggio di rischio. Consultate la nostra analisi delle lacune comuni di copertura della policy di base di Accesso Condizionale per capire come appare un set completo di policy.
Attivate la risposta automatizzata al rischio in modo che le sessioni a rischio vengano gestite quasi in tempo reale invece di attendere un ciclo di revisione manuale — per saperne di più consultate la nostra guida alle policy di rischio di Identity Protection in Entra ID.

Logging e revisione continua

Estendete la retention dei log di audit a una finestra che supporti davvero la caccia retrospettiva, e non solo il troubleshooting quotidiano. Il nostro articolo su logging, retention e impostazioni di diagnostica in Entra ID copre la configurazione pratica.
Rivedete i service principal con privilegi elevati e la loro attività di accesso per individuare qualsiasi cosa inaspettata intorno alla finestra di divulgazione — il nostro articolo sul rilevamento di anomalie di accesso dei service principal illustra come appare una baseline per le identità di workload.
Iscrivetevi alle notifiche di aggiornamento degli avvisi MSRC. Lo stato di sfruttamento di questo CVE è cambiato un giorno dopo la pubblicazione — se avete letto solo il titolo del giorno della divulgazione, vi siete persi la correzione.

Questo non è il primo CVE Entra ID di quest'anno pubblicato con "nessuna azione richiesta al cliente". Abbiamo trattato lo stesso schema zero-patch in CVE-2026-62869, una vulnerabilità di spoofing in Entra ID, e di nuovo in CVE-2026-50481, una falla di elevazione dei privilegi in Azure Active Directory — un CVSS 9.9 pubblicato anch'esso con un elenco di remediation vuoto e Customer Action Required: No. Lo schema sta diventando la norma: Microsoft distribuisce la correzione, e l'unica cosa che resta ai tenant è decidere fino a che punto guardare indietro.

Come EtcSec rileva tutto questo

L'audit Azure di EtcSec non rileva — e non può rilevare — lo sfruttamento di un CVE lato servizio come CVE-2026-69836; questa visibilità risiede interamente all'interno dell'infrastruttura stessa di Microsoft. Ciò che verifica sono esattamente le lacune che trasformano un incidente come questo in un punto cieco: se esiste o meno una policy di rischio di accesso, se quel rischio è supportato da una policy di Accesso Condizionale basata sul rischio, se le risposte al rischio sono automatizzate anziché manuali, se la retention dei log di audit è abbastanza lunga da supportare una caccia retrospettiva, e se i service principal detengono privilegi amministrativi senza revisione continua.