Azure SRE Agent OBO Bypass Exposed Managed-Identity Scope

The Incident

On August 6, 2026, Microsoft’s early August security update disclosed CVE-2026-62830 (CVSS 9.9, CWE-862 Missing Authorization, Scope: Changed) — a Critical elevation-of-privilege flaw in Azure SRE Agent, Microsoft’s AI-powered autonomous site reliability engineering service that monitors, diagnoses, and remediates issues in Azure-hosted applications and infrastructure. The bug sits in the agent’s On-Behalf-Of (OBO) OAuth token-exchange path: a low-privileged remote attacker with no user interaction can invoke the OBO exchange and receive a token that inherits the agent’s service-principal permissions across the environment the agent manages. The Scope: Changed vector is the load-bearing detail — the boundary the attacker breaks (the OBO handler) is not the boundary they end up exercising (every Azure resource the agent’s managed identity can reach).

Microsoft mitigated the flaw server-side on August 6, 2026; no customer patch is required. Microsoft’s guidance to customers is to audit managed-identity assignments, review RBAC, and monitor for anomalous privilege elevation. The advisory shipped alongside CVE-2026-59118 (Microsoft Copilot Cowork, CVSS 9.3, CWE-285 Improper Authorization) — a second Microsoft AI-agent authorization failure in the same release.

This is the second Azure SRE Agent authority failure in four months. In April, CVE-2026-32173 (CVSS 8.6, CWE-287 Improper Authentication) let any Entra ID holder subscribe to another tenant’s live agent session over SignalR. That let an outside caller watch the agent work. CVE-2026-62830 lets an outside caller become it.

MITRE ATT&CK: T1078.004 (Valid Accounts: Cloud Accounts) covers the attacker’s inheritance of the agent’s service-principal identity across the managed environment.

The Authority Path That Failed

The identity carrying execution authority is Azure SRE Agent’s user-assigned managed identity (UAMI) — a service principal that operators grant RBAC at either Reader (default) or Privileged. In Privileged mode, the agent auto-assigns Contributor per detected resource type plus Monitoring Contributor at subscription scope. That set is the scope the UAMI holds: the union of every RBAC grant the agent could ever exercise across the managed subscription and its resource groups.

The scope the agent should exercise on any given operation is much narrower — the intersection of the UAMI’s grants with the calling operator’s own grants and with what the specific operation requires. The OBO exchange is the mechanism meant to enforce that intersection: the agent presents an operator-scoped token, and OBO mints a delegation token narrowed to what the operator personally holds. CVE-2026-62830 breaks the intersection at the exchange itself. The handler treats token validity as sufficient proof to complete the exchange with the agent’s service-principal identity, and hands the caller a token carrying the agent’s full UAMI scope — Reader or Privileged, whichever the customer configured.

The trust anchor that failed first was the OBO handler’s authorization check. Token validity did not prove that the caller was entitled to request delegation from that agent at that scope. The customer-visible blast radius was the managed identity’s RBAC surface, even though Microsoft owned and fixed the vulnerable exchange.

SecurityV0 Perspective

This is nhi_compromise. The attack does not steal a static credential; it causes a delegation exchange to mint fresh service-principal-scoped tokens on demand for a caller who was never authorized to receive them. That is the same failure class as the LiteLLM/TeamPCP reference, moved from a package-supply-chain vector to a delegation-flow vector — the machine identity is still the boundary, and the boundary still failed. Static NHI failures (leaked keys, unrotated tokens) are the well-covered end of this category. A delegation flow that mints SP-scoped tokens without authorizing the request is the same failure class realized dynamically, and it is under-covered.

For customers, the immediate governance question is concrete: which Azure SRE Agents are visible across the connected environment, which managed identities back them, and what can those identities reach? Microsoft fixed the exchange, but the customer still controls the authority available behind it. That surface-wide RBAC map determines the blast radius of this flaw and the next delegation failure.

What To Do

Enumerate the Azure SRE Agent’s UAMI RBAC assignments across every subscription and resource group today. Reader vs Privileged, resource-type Contributor roles, and Monitoring Contributor at subscription scope in Privileged mode. Everything the UAMI can reach was the pre-mitigation blast radius; you cannot triage exposure without that list.
Review Azure Activity Log and Entra sign-in evidence for the affected period. Investigate unexpected operations by the agent’s service principal, especially actions outside the requesting operator’s normal scope.
Require explicit caller and scope authorization in customer-owned delegation flows. Token validity is not authorization; every exchange must verify who can delegate, to which agent, and at what scope.
Rotate managed-identity-reachable secrets when investigation cannot rule out access. Microsoft’s server-side fix closes the OBO leak forward; it does not invalidate whatever a pre-mitigation exploit may have already touched. Any key, connection string, or certificate the agent’s UAMI could reach is in scope for rotation if the activity-log review is not conclusive.
Use Reader mode unless active remediation requires Privileged mode. Privileged mode expands the managed identity’s blast radius through Contributor roles; retain it only where the operational benefit is explicit.

The Incident

The Authority Path That Failed

SecurityV0 Perspective

What To Do

Sources