Entra Provisioning Service Vulnerability CVE-2026-59115: Two Critical SyncFabric EoP Flaws

What Is the Entra Provisioning Service Vulnerability CVE-2026-59115

This is a technical walkthrough of the Entra Provisioning Service vulnerability CVE-2026-59115, a Critical elevation-of-privilege flaw Microsoft disclosed on August 6, 2026 in Microsoft Entra Provisioning Service — also known as SyncFabric, the cloud engine that creates, updates, and removes identities across Entra ID, HR sources, SCIM-connected SaaS apps, and cross-tenant synchronization targets. It's the second Critical elevation-of-privilege flaw found in this exact component in five weeks: CVE-2026-57100, a related server-side request forgery (SSRF) issue, was quietly patched in Microsoft's July 2026 update cycle.

Neither CVE required a KB article or a customer-deployed patch — both were fixed service-side, because the Entra Provisioning Service runs entirely in Microsoft's cloud. But "no patch to deploy" does not mean "nothing to review." This article covers what's publicly confirmed about both flaws, what detection actually looks like for a Microsoft-hosted service you can't instrument directly, and the concrete hardening steps that reduce your exposure regardless of what Microsoft discloses next.

How the Two SyncFabric Vulnerabilities Work

Both CVEs live in the same component and share an identical MSRC description pattern — "allows an authorized attacker to elevate privileges over a network" — but they're two distinct bug classes.

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

CVE-2026-59115 is a path traversal bug. The .../...// sequence pattern behind CWE-35 describes input that resolves to a location outside a restricted directory. In a provisioning pipeline that reads and writes identity objects across trust boundaries — source directory, sync engine, target application — an unbounded traversal primitive is a privilege-escalation path, not just a file-disclosure bug: it's rated S:C (scope changed), meaning a successful exploit can affect resources beyond the vulnerable component itself. As of this writing, Microsoft's advisory doesn't publish the attack method, an affected-build list, a KB number, or mitigation guidance beyond the bare CVSS vector — a gap independently noted by multiple trackers (Windows Forum). NVD has not yet published its own independent CVSS assessment for this CVE either — the score shown on its listing is Microsoft's CNA rating, not an NVD reassessment.

CVE-2026-57100 is a server-side request forgery: the provisioning service, acting on the attacker's behalf, can be coerced into making requests the attacker chooses. Microsoft's own CNA rating (9.9, scope changed) and NVD's independent reassessment (8.8, scope unchanged) disagree on whether the flaw crosses a security boundary — a scoring split that shows up when an SSRF's blast radius depends on internal service topology NVD can't fully verify from the public advisory. Both scorings agree the flaw is exploitable over the network with low attack complexity and no user interaction, differing only on blast radius. Microsoft's July Patch Tuesday coverage confirms the fix was "mitigated entirely on Microsoft's infrastructure, and no customer action is required" (CrowdStrike).

What "Authorized Attacker" Means Here

Both flaws require PR:L — Microsoft's advisories describe the actor as an "authorized attacker," which is not the same as "anonymous internet user." It means the starting point is some baseline access to the target tenant or its provisioning configuration: a low-privileged but compromised user account, a delegated administrator with narrow provisioning rights, or a credential belonging to a service principal that already talks to the provisioning pipeline. That's a materially different threat model than an unauthenticated remote exploit — it puts the emphasis on how tightly you control who and what holds provisioning-adjacent access in the first place, which is exactly what the remediation steps below focus on. Neither vendor advisory nor the trackers reviewed for this article report evidence of in-the-wild exploitation for either CVE as of this writing.

Detection

Here's the uncomfortable part: SyncFabric is a Microsoft-operated cloud service, not a Windows Server role you can drop an EDR agent or a Sysmon config into. There is no published Entra-side event ID, Sentinel query, or IOC for either CVE, because the vulnerable code doesn't run in your tenant — it runs in Microsoft's. Any detection guidance that claims to fire on CVE-2026-59115 or CVE-2026-57100 exploitation specifically would be inventing a signal that doesn't exist in the public record.

What you can do is tighten monitoring around the provisioning pipeline's blast radius, since PR:L means the attack starts from access you control the assignment of:

(Sources: Microsoft Entra provisioning logs, audit log activity reference.)

Provisioning logs are retained 30 days on a premium tenant (7 days on a free tenant) — route them to Azure Monitor / Log Analytics via diagnostic settings if you need longer retention or want to alert on them. You can query provisioning activity directly through Microsoft Graph:

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

Cross-Tenant Synchronization and B2B Provisioning

The same SyncFabric engine also drives Microsoft Entra cross-tenant synchronization — the feature that automatically provisions guest identities from a partner tenant. Per Microsoft's own documentation, configuration changes for cross-tenant synchronization surface in the audit logs under the same ProvisioningManagement category as regular app provisioning, while the create/update/delete events for the synced guest accounts themselves land in the provisioning logs. If your tenant uses cross-tenant sync, the same connector-permission review in the Remediation section below applies to it — it's the identical underlying service, just a different source/target pairing.

Remediation

1. Inventory who and what qualifies as "authorized" against your provisioning configuration. PR:L means the starting point for both CVEs is some existing privilege — an admin role, a delegated permission, or a compromised service principal with rights over provisioning jobs. Review membership of roles that can read or modify provisioning configuration (Hybrid Identity Administrator, Application Administrator, and any custom roles scoped to provisioning configuration permissions) — including break-glass emergency access accounts, which often carry broad standing privilege by design and are easy to forget in a scoped review like this one.
2. Put provisioning-adjacent admin roles behind PIM, not standing assignment, so a compromised account doesn't get permanent reach into the provisioning pipeline. PIM requires Entra ID P2 licensing — see Azure AD Premium P2 features if you're unsure whether it's turned on — and how to audit Microsoft Entra ID security for a broader Conditional Access and PIM review checklist.
3. Check the service principal(s) backing your provisioning connectors — HR-driven provisioning, SCIM apps, cross-tenant synchronization — for excessive credentials, stale secrets, or admin-tier role assignments. An SSRF or path-traversal bug in the provisioning path is more dangerous when the connector's own identity is over-privileged.
4. Stream provisioning and audit logs to Log Analytics if you aren't already, so you have more than 30 days of history the next time an advisory like this lands.
5. Track the MSRC advisory for CVE-2026-59115 directly. Since Microsoft hasn't published an affected-configuration list or mitigation guidance for it yet, re-check the advisory page itself rather than relying on a snapshot — multiple trackers have flagged this gap and it may be filled in after initial publication.

If You Use HR-Driven or Cross-Tenant Provisioning

The review in step 3 matters more, not less, for HR-driven provisioning (Workday, SuccessFactors) and cross-tenant sync connectors, since they typically run with broad create/update/delete rights across your whole user population by design. Confirm the connector's credentials are scoped as narrowly as the integration allows, rotate any bearer tokens or client secrets that predate this disclosure window, and — for cross-tenant sync specifically — review your inbound and outbound automatic-redemption policies so an unexpected guest-provisioning event doesn't sail through unnoticed.

How EtcSec Detects This

EtcSec can't see inside Microsoft's SyncFabric service any more than you can — but it continuously checks the two things that determine how much damage an "authorized attacker" can do if either CVE, or the next one in this component, turns into a working exploit: whether service principals hold admin-tier roles (PA_SERVICE_PRINCIPAL_ADMIN) and whether privileged roles — including any with provisioning-adjacent permissions — sit outside PIM with standing assignment (PA_PIM_NOT_ENABLED). Tightening both closes the gap between "an attacker gets a foothold" and "an attacker escalates through the provisioning pipeline."