CVE-2026-50481 Azure Active Directory Elevazione dei Privilegi: il CVSS 9.9 che non puoi correggere

Microsoft ha assegnato a CVE-2026-50481 Azure Active Directory Elevazione dei Privilegi un punteggio base CVSS 3.1 di 9.9 nella sua release di agosto 2026 — senza rilasciare nulla da installare. Ecco come si presenta un CVE critico di servizio cloud dal lato cliente, e cosa puoi ancora verificare all'interno del tuo tenant.

CVE-2026-50481 Azure Active Directory Elevazione dei Privilegi: cosa si sa

Microsoft ha pubblicato la falla il 6 agosto 2026. La sua descrizione tecnica completa è una singola frase: « Modification of assumed-immutable data (maid) in Azure Active Directory allows an authorized attacker to elevate privileges over a network. » La scheda MSRC la classifica come CWE-471, indica Latest Software Release: N/A, e mostra un elenco di remediation vuoto. Il campo Customer Action Required riporta No.

Questa combinazione è il vero punto. Un 9.9 nella directory che autentica l'intero parco Microsoft, e la posizione del vendor si riduce a « lo abbiamo già corretto ».

Ecco cosa dicono realmente le due schede di riferimento.

Leggete il vettore, non il numero. PR:L significa che l'attaccante è già autenticato con privilegi bassi — non è una falla esposta su internet senza autenticazione, è un'escalation disponibile per chiunque abbia un punto d'appoggio nel vostro tenant. S:C (scope cambiato) è ciò che spinge il punteggio a 9.9: l'impatto esce dal componente vulnerabile verso altre autorità di sicurezza. E:U e RL:O — codice di exploit non dimostrato, correzione ufficiale disponibile — fanno scendere il punteggio temporale a 8.6.

Perché non c'è nulla da correggere

Azure Active Directory non è un software che gestite voi. NVD etichetta CVE-2026-50481 come exclusively-hosted-service e lo associa al CPE cpe:2.3:a:microsoft:azure_active_directory:- — un prodotto senza versione, perché esiste una sola istanza in esecuzione, gestita da Microsoft.

Si tratta di una politica deliberata, non di una svista. Nel giugno 2024, Lisa Olson del MSRC ha annunciato il cambiamento: « We are now announcing that we will issue CVEs for critical cloud service vulnerabilities, regardless of whether customers need to install a patch or to take other actions. » Il post è esplicito sul marcatore: « In the CVE.org record, we will use the exclusively-hosted-service tag to indicate that there is no action required by the customer. »

Un CVE cloud è quindi un avviso di trasparenza, non un task operativo. La vulnerabilità esisteva nella directory multi-tenant, Microsoft l'ha corretta dal suo lato, e il CVE vi informa che è successo.

CVE-2026-50481 non era isolato. Analizzando il documento CVRF ufficiale della release di agosto 2026 di Microsoft, 21 CVE di quella release portano la dicitura Customer Action Required: No. Tre di questi si collocano direttamente nel piano identità:

Per dare un'idea della scala, Cisco Talos ha contato 421 vulnerabilità nella release di agosto 2026, 62 classificate critiche, 40 delle quali di esecuzione di codice remoto, con esattamente una sfruttata in the wild (CVE-2026-68820, un'escalation WinSock AFD con CVSS 7.0). Talos elenca CVE-2026-50481 sotto « Other critical vulnerabilities » — segnalata, non in primo piano. Se avete gestito il triage di agosto in base a « cosa devo distribuire questo weekend », dove è finita l'attenzione della maggior parte dei team — vedi il nostro riepilogo Patch Tuesday agosto 2026 degli RCE su domain controller — questo non ha generato nemmeno un ticket.

Esiste un precedente che mostra come questo sia un errore. CVE-2025-55241, il problema di Elevazione dei Privilegi di Azure Entra ID che il MSRC ha rilasciato il 4 settembre 2025, ha ottenuto un punteggio pieno di CVSS 10.0 ed è stato rilasciato anch'esso con Customer Action Required: No. Lo schema è ormai ben consolidato: le vulnerabilità identità di massima severità dell'era cloud arrivano come notifiche, non come patch.

Cosa Microsoft non ha pubblicato

Chiariamo bene il confine di ciò che è noto, perché è stretto.

Microsoft non ha pubblicato alcuna catena d'attacco, nessun criterio sui tenant interessati, nessun indicatore di compromissione, nessuna finestra di sfruttamento, né alcuna dichiarazione sul fatto che la falla sia mai stata sfruttata prima della correzione. L'unico segnale sulla debolezza è il mapping CWE. CWE-471 descrive un prodotto che « does not properly protect an assumed-immutable element from being modified by an attacker » — un input, nelle parole di MITRE, « critical enough to the functioning of the application that it should not be modifiable at all, but it is. » MITRE elenca le conseguenze come Modify Application Data e Unexpected State.

Questo vi dà la forma della classe di bug. Non vi dice quale attributo, claim o identificatore in Azure AD fosse modificabile quando non avrebbe dovuto esserlo. Chiunque pubblichi oggi un percorso di sfruttamento specifico per CVE-2026-50481 sta estrapolando dal CWE, non sta riportando un fatto accertato.

Ciò su cui potete agire è il residuo. Se un'escalation a livello di directory era raggiungibile prima della correzione lato servizio, gli artefatti di qualsiasi uso si troverebbero nei log del vostro stesso tenant — non nell'output di uno scanner.

Rilevamento

Non esiste una firma per CVE-2026-50481, e qualsiasi vendor che ne rivendichi una vi sta vendendo una supposizione. Ciò che potete fare è dare la caccia al risultato che la falla consente: un privilegio comparso senza passare per un percorso di approvazione legittimo. Questa caccia vale la pena di essere condotta indipendentemente da questo CVE.

Il tempo conta. Microsoft Entra conserva i log di audit per sette giorni su Entra ID Free e 30 giorni su P1 e P2. I log di attività di Microsoft Graph richiedono P1 o P2 e non vengono conservati affatto a meno che non li abbiate già instradati verso un workspace o un account di archiviazione. Fate il calcolo prima di pianificare la caccia. La divulgazione del 6 agosto 2026 ha già superato la finestra di sette giorni di Free, quindi un tenant Free non ha più nulla da interrogare. Un tenant P1 o P2 è ancora dentro la finestra di 30 giorni — ma solo fino a circa il 5 settembre 2026, dopodiché quella prova sparisce a meno che non sia stata esportata. Sistemate prima la pipeline; vedi le lacune di retention dei log e dei diagnostic settings di Entra ID.

Ogni nome di attività sopra riportato è ripreso testualmente dalla reference delle attività di audit di Microsoft.

Iniziate dai cambiamenti di ruolo di directory su tutta la vostra finestra di retention:

AuditLogs
| where TimeGenerated > ago(30d)
| where LoggedByService in ("Core Directory", "PIM")
| where ActivityDisplayName has "role"
| extend ActorUser = tostring(InitiatedBy.user.userPrincipalName),
         ActorApp  = tostring(InitiatedBy.app.displayName)
| project TimeGenerated, ActivityDisplayName, ActorUser, ActorApp,
          Result, TargetResources, CorrelationId
| order by TimeGenerated desc

Poi passate al livello API, dove un'identità di workload che agisce per conto proprio è visibile in un modo che il solo audit trail della directory può nascondere:

MicrosoftGraphActivityLogs
| where TimeGenerated > ago(30d)
| where RequestMethod in ("POST", "PATCH", "PUT", "DELETE")
| where RequestUri has_any ("/directoryRoles", "/roleManagement",
                            "/servicePrincipals", "/applications")
| where ResponseStatusCode between (200 .. 299)
| project TimeGenerated, RequestMethod, RequestUri, ResponseStatusCode,
          UserId, ServicePrincipalId, AppId, IPAddress, Roles, Scopes, Wids
| order by TimeGenerated desc

Notate il valore del servizio: Privileged Identity Management viene loggato come PIM, non con il nome per esteso — la stessa guida alle operazioni di sicurezza per account privilegiati di Microsoft filtra questi eventi con Service = PIM. Scriverlo per esteso restituisce un result set vuoto.

La colonna Wids contiene i ruoli a livello di tenant portati nel token del chiamante, e ServicePrincipalId separa le identità di workload dagli utenti interattivi — i due campi che trasformano un muro di chiamate Graph in una domanda a cui si può rispondere.

Rimedio

Non potete rimediare alla vulnerabilità in sé. Potete rimediare al raggio d'impatto, che è l'unica variabile che controllate di fronte a un CVE di servizio hosted.

1. Ristabilite la baseline dei titolari di ruoli privilegiati. Estraete la membership attuale di ogni ruolo di directory e confrontatela con un elenco di riferimento affidabile precedente al 6 agosto 2026. Qualsiasi aggiunta che non potete collegare a un registro di change è il finding — che provenga o meno da questo CVE.

2. Eliminate il privilegio permanente. Le escalation PR:L rendono in proporzione a quanto privilegio permanente resta in attesa. Spostate le assegnazioni permanenti verso ruoli eleggibili per PIM con approvazione e MFA all'attivazione. La nostra guida su perché i tenant accumulano troppi Global Administrator copre la fase di inventario.

3. Verificate le identità non umane. I service principal che detengono ruoli di directory o permessi applicativi Graph ad alto privilegio sono il punto d'appoggio PR:L più comune in un tenant moderno, e non subiscono phishing, rotazione né offboarding. Vedi service principal Entra con ruoli admin sovraprivilegiati.

4. Verificate l'integrità dei break-glass. Gli account di accesso di emergenza sono esclusi da Conditional Access per progettazione, il che li rende il bersaglio di massimo valore di qualsiasi escalation. Confermate che credenziali, esclusioni e alert di accesso corrispondano ancora all'intento originario — lacune negli account break-glass.

5. Aggiungete i CVE cloud al vostro processo di triage. Filtrate il Security Update Guide sulla colonna Customer Action Required che il MSRC ha aggiunto esattamente per questo scopo. « No action required » è una dichiarazione sul patching, non sulla garanzia — i 21 CVE senza azione richiesta di agosto 2026 meritano comunque ciascuno una decisione, anche se quella decisione è « registrato, nessuna esposizione ».

6. Chiudete la porta di guest ed esterni. PR:L conta qualsiasi principal autenticato. Account guest obsoleti e impostazioni di invito B2B non ristrette ampliano l'insieme di account da cui può partire un'escalation.

Come EtcSec rileva questo

EtcSec non può rilevare una vulnerabilità all'interno del servizio Microsoft stesso — nessuno può, dall'esterno. Ciò che un audit Entra di EtcSec rileva è l'esposizione che decide se un'escalation di directory resta una nota a margine o diventa un incidente: PA_PERMANENT_ADMIN_ASSIGNMENTS per il privilegio permanente che non scade mai, PA_PIM_NOT_ENABLED dove non esiste alcun confine just-in-time, PA_TOO_MANY_GLOBAL_ADMINS per un Tier 0 sovradimensionato, SP_HIGH_PRIVILEGE per i service principal che detengono ruoli di directory privilegiati, e AZ_GROUP_PRIVILEGED_CHANGES per i gruppi privilegiati i cui cambi di membership nessuno sorveglia.

Questa è la ripartizione onesta del lavoro di fronte a un CVE di servizio hosted. Microsoft possiede la correzione. Voi possedete quanto quella correzione sia stata rilevante — ed entrambe le metà di questa frase sono verificabili in audit. Per la sequenza di revisione completa, vedi come auditare la sicurezza di Microsoft Entra ID.