Vulnerabilità Entra Provisioning Service CVE-2026-59115: due falle critiche di elevazione dei privilegi in SyncFabric

Cos'è la vulnerabilità Entra Provisioning Service CVE-2026-59115

Questo articolo propone un'analisi tecnica della vulnerabilità Entra Provisioning Service CVE-2026-59115, una falla critica di elevazione dei privilegi divulgata da Microsoft il 6 agosto 2026 in Microsoft Entra Provisioning Service — noto anche come SyncFabric, il motore cloud che crea, aggiorna ed elimina identità su Entra ID, sorgenti HR, app SaaS connesse via SCIM e destinazioni di sincronizzazione cross-tenant. È la seconda falla critica di elevazione dei privilegi individuata in questo stesso componente in cinque settimane: CVE-2026-57100, un problema correlato di server-side request forgery (SSRF), è stata corretta silenziosamente nel ciclo di aggiornamenti di luglio 2026 di Microsoft.

Nessuna delle due CVE ha richiesto un articolo KB né una patch distribuita dal cliente — entrambe sono state corrette lato servizio, perché Entra Provisioning Service viene eseguito interamente nel cloud di Microsoft. Ma "nessuna patch da distribuire" non significa "niente da verificare". Questo articolo copre ciò che è pubblicamente confermato su entrambe le falle, come si presenta realmente il rilevamento per un servizio ospitato da Microsoft che non è possibile strumentare direttamente, e le misure concrete di hardening che riducono la tua esposizione, indipendentemente da cosa Microsoft divulgherà in seguito.

Come funzionano le due vulnerabilità di SyncFabric

Entrambe le CVE risiedono nello stesso componente e condividono un pattern di descrizione MSRC identico — "consente a un attaccante autorizzato di elevare i privilegi sulla rete" — ma sono due classi di bug distinte.

Fonti: NVD — CVE-2026-59115, NVD — CVE-2026-57100, GitHub Advisory Database — GHSA-w2pm-fvgr-6r6g, Tenable — CVE-2026-57100.

CVE-2026-59115 è un bug di path traversal. Il pattern di sequenza .../...// alla base della CWE-35 descrive un input che si risolve in una posizione esterna a una directory ristretta. In una pipeline di provisioning che legge e scrive oggetti identità attraverso confini di fiducia — directory sorgente, motore di sincronizzazione, applicazione destinazione — una primitiva di traversal senza limiti è una via di escalation dei privilegi, non solo un bug di divulgazione file: è classificata S:C (scope modificato), il che significa che uno sfruttamento riuscito può interessare risorse oltre il componente vulnerabile stesso. Al momento della stesura, l'avviso di Microsoft non pubblica il metodo di attacco, un elenco delle build interessate, un numero KB, né indicazioni di mitigazione oltre al nudo vettore CVSS — una lacuna rilevata in modo indipendente da più osservatori (Windows Forum). Anche la NVD non ha ancora pubblicato una propria valutazione CVSS indipendente per questa CVE — il punteggio mostrato sulla sua scheda è il rating CNA di Microsoft, non una rivalutazione NVD.

CVE-2026-57100 è un server-side request forgery: il servizio di provisioning, agendo per conto dell'attaccante, può essere costretto a effettuare le richieste scelte dall'attaccante. Il rating CNA proprio di Microsoft (9.9, scope modificato) e la rivalutazione indipendente della NVD (8.8, scope invariato) sono in disaccordo sul fatto che la falla attraversi un confine di sicurezza — una divergenza di punteggio che emerge quando il raggio d'impatto di un SSRF dipende da una topologia di servizio interna che la NVD non può verificare pienamente dall'avviso pubblico. Entrambe le valutazioni concordano sul fatto che la falla sia sfruttabile in rete con bassa complessità di attacco e senza interazione dell'utente, differendo solo sul raggio d'impatto. La copertura del Patch Tuesday di luglio di Microsoft conferma che la correzione è stata "mitigata interamente sull'infrastruttura di Microsoft, e non è richiesta alcuna azione da parte del cliente" (CrowdStrike).

Cosa significa qui "attaccante autorizzato"

Entrambe le falle richiedono PR:L — gli avvisi di Microsoft descrivono l'attore come un "attaccante autorizzato", che non equivale a un "utente anonimo di internet". Significa che il punto di partenza è un accesso di base al tenant target o alla sua configurazione di provisioning: un account utente con privilegi bassi ma compromesso, un amministratore delegato con diritti di provisioning limitati, o una credenziale appartenente a un service principal che già dialoga con la pipeline di provisioning. È un modello di minaccia sostanzialmente diverso da un exploit remoto non autenticato — pone l'accento su quanto rigorosamente controlli chi e cosa detiene un accesso adiacente al provisioning fin dall'inizio, che è esattamente ciò su cui si concentrano le misure di remediation seguenti. Né l'avviso del vendor né gli osservatori consultati per questo articolo riportano evidenze di sfruttamento attivo per l'una o l'altra CVE al momento della stesura.

Rilevamento

Ecco la parte scomoda: SyncFabric è un servizio cloud gestito da Microsoft, non un ruolo di Windows Server su cui puoi installare un agente EDR o una configurazione Sysmon. Non esiste alcun ID evento lato Entra, query Sentinel o IOC pubblicato per l'una o l'altra CVE, perché il codice vulnerabile non viene eseguito nel tuo tenant — viene eseguito in quello di Microsoft. Qualsiasi indicazione di rilevamento che affermi di attivarsi specificamente sullo sfruttamento di CVE-2026-59115 o CVE-2026-57100 starebbe inventando un segnale che non esiste nel registro pubblico.

Ciò che puoi fare è rafforzare il monitoraggio attorno al raggio d'impatto della pipeline di provisioning, dato che PR:L significa che l'attacco parte da un accesso di cui controlli tu l'assegnazione:

(Fonti: Log di provisioning di Microsoft Entra, riferimento delle attività dei log di audit.)

I log di provisioning vengono conservati 30 giorni su un tenant premium (7 giorni su un tenant gratuito) — inoltrali ad Azure Monitor / Log Analytics tramite le impostazioni di diagnostica se hai bisogno di una conservazione più lunga o vuoi generare avvisi su di essi. Puoi interrogare direttamente l'attività di provisioning tramite Microsoft Graph:

GET https://graph.microsoft.com/v1.0/auditLogs/provisioning?$filter=provisioningStatusInfo/status eq 'failure'&$orderby=activityDateTime desc&$top=50

Sincronizzazione cross-tenant e provisioning B2B

Lo stesso motore SyncFabric guida anche la sincronizzazione cross-tenant di Microsoft Entra — la funzionalità che effettua automaticamente il provisioning delle identità guest da un tenant partner. Secondo la stessa documentazione di Microsoft, le modifiche di configurazione della sincronizzazione cross-tenant compaiono nei log di audit sotto la stessa categoria ProvisioningManagement del provisioning app standard, mentre gli eventi di creazione/aggiornamento/eliminazione degli account guest sincronizzati stessi finiscono nei log di provisioning. Se il tuo tenant usa la sincronizzazione cross-tenant, la stessa revisione dei permessi dei connettori descritta nella sezione Remediation qui sotto si applica anche a essa — è lo stesso servizio sottostante, cambia solo l'abbinamento sorgente/destinazione.

Remediation

1. Fai l'inventario di chi e cosa è qualificato come "autorizzato" rispetto alla tua configurazione di provisioning. PR:L significa che il punto di partenza di entrambe le CVE è un privilegio già esistente — un ruolo di amministrazione, un permesso delegato, o un service principal compromesso con diritti sui job di provisioning. Rivedi l'appartenenza ai ruoli che possono leggere o modificare la configurazione di provisioning (Hybrid Identity Administrator, Application Administrator, e qualsiasi ruolo personalizzato con permessi sulla configurazione di provisioning) — inclusi gli account di accesso di emergenza break-glass, che spesso portano per progettazione un ampio privilegio permanente e sono facili da dimenticare in una revisione mirata come questa.
2. Metti i ruoli di amministrazione adiacenti al provisioning dietro PIM, non in assegnazione permanente, in modo che un account compromesso non ottenga un accesso duraturo alla pipeline di provisioning. PIM richiede una licenza Entra ID P2 — vedi le funzionalità di Azure AD Premium P2 se non sei sicuro che sia attiva — e come verificare la sicurezza di Microsoft Entra ID per una checklist di revisione più ampia su Conditional Access e PIM.
3. Verifica il/i service principal a supporto dei tuoi connettori di provisioning — provisioning guidato da HR, app SCIM, sincronizzazione cross-tenant — alla ricerca di credenziali eccessive, secret obsoleti o assegnazioni di ruolo di livello admin. Un bug SSRF o di path traversal nel percorso di provisioning è più pericoloso quando l'identità stessa del connettore è iperprivilegiata.
4. Invia i log di provisioning e di audit a Log Analytics se non lo stai già facendo, così da avere più di 30 giorni di storico la prossima volta che arriva un avviso come questo.
5. Segui direttamente l'avviso MSRC per CVE-2026-59115. Poiché Microsoft non ha ancora pubblicato un elenco delle configurazioni interessate né indicazioni di mitigazione per questa falla, ricontrolla la pagina dell'avviso stessa invece di affidarti a uno snapshot — più osservatori hanno segnalato questa lacuna e potrebbe essere colmata dopo la pubblicazione iniziale.

Se usi provisioning guidato da HR o cross-tenant

La revisione del punto 3 conta di più, non di meno, per il provisioning guidato da HR (Workday, SuccessFactors) e i connettori di sincronizzazione cross-tenant, poiché tipicamente operano per progettazione con ampi diritti di creazione/aggiornamento/eliminazione sull'intera popolazione di utenti. Conferma che le credenziali del connettore siano delimitate nel modo più stretto possibile consentito dall'integrazione, ruota ogni bearer token o client secret precedente a questa finestra di divulgazione e — specificamente per la sincronizzazione cross-tenant — rivedi le tue policy di redemption automatica in entrata e in uscita affinché un evento imprevisto di provisioning guest non passi inosservato.

Come EtcSec rileva questo

EtcSec non può vedere all'interno del servizio SyncFabric di Microsoft più di quanto tu possa fare — ma verifica in modo continuo le due cose che determinano quanti danni può causare un "attaccante autorizzato" se una di queste CVE, o la prossima in questo stesso componente, diventa un exploit funzionante: se i service principal detengono ruoli di livello admin (PA_SERVICE_PRINCIPAL_ADMIN) e se i ruoli privilegiati — inclusi quelli con permessi adiacenti al provisioning — si trovano fuori da PIM con assegnazione permanente (PA_PIM_NOT_ENABLED). Stringere entrambi riduce il divario tra "un attaccante ottiene un punto d'appoggio" e "un attaccante fa escalation attraverso la pipeline di provisioning".