Azure SRE Agent's 9.9 Authorization Flaw Could Have Let a Caller Inherit Its Identity

CVE-2026-62830 is a missing authorization flaw in Azure SRE Agent, Microsoft's AI-powered agent for Azure site-reliability teams, which triages incidents, queries telemetry and, when configured, executes remediation. Microsoft disclosed it in August 2026 and scored it 9.9 out of 10 — Critical — under CVSS 3.1. Any Azure tenant running the agent was in scope of the bug; the incident archive records no confirmed victim and no exploitation. Microsoft's description of the flaw is one sentence: "Missing authorization in Azure SRE Agent allows an authorized attacker to elevate privileges over a network." The service was fixed server-side, and Microsoft says customers had nothing to patch. The full entry, with its severity and confidence grades, sits in the Orca AI Incident Archive alongside the neighbouring incidents in this series.

What Microsoft published, and what it left out

Microsoft's Security Update Guide entry for CVE-2026-62830 records an elevation of privilege in Azure SRE Agent, weakness CWE-862 (Missing Authorization), a base score of 9.9 and a temporal score of 8.6. The vector — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C — describes a network attack that needs only low privileges, no user interaction, and produces high confidentiality, integrity and availability impact. Microsoft credits the finding to security researcher wtm of Offensi in the advisory's acknowledgements.

Two parts of that vector carry the story. The scope metric is Changed (S:C), which Microsoft's own metric documentation defines as a case where the vulnerable component and the impacted component are different and managed by different security authorities. The temporal metrics are Unproven exploit code, Official fix and Confirmed, which is why the temporal score sits below the base.

The advisory's FAQ explains why a 9.9 exists with no download link: "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." Microsoft tags the product as an exclusively hosted service, which is why the entry carries no build number and no affected-version range.

The exploitability table is as clear as the FAQ. Publicly disclosed: No. Exploited: No. Exploitation assessment: Less Likely. What the advisory does not describe is the on-behalf-of flow, the managed identity, or runbooks. Nor does it give a version range: the CPE is the product with no version, and the only affected version listed is a dash. Everything a reader would want about the mechanism has to come from somewhere else, and that somewhere else is mostly the archive's own entry.

What the agent is, and why its identity is the thing worth reaching

Azure SRE Agent is not a chatbot bolted onto a dashboard. Microsoft's Azure SRE Agent documentation describes an agent that connects to Azure resources, observability tools, incident platforms and source code repositories, gathers signals, correlates deployments, proposes mitigations and — depending on the run mode a customer sets — executes them. In Review mode an administrator approves the write actions; in Autonomous mode the agent applies them without waiting. Its reach is extended through skills and runbooks, Azure CLI operations, custom agents, Python tools, MCP connectors and agent hooks.

The same documentation states the fact that makes the CVE interesting: "The agent authenticates with managed identity and operates under Azure role-based access control (RBAC)." A managed identity is an Entra identity assigned to a service, and what it can do is exactly what its role assignments allow. The agent's authority is therefore not a property of the agent's code but of the roles attached to that identity — which is the boundary a missing authorization check would fail to protect.

A separate technical write-up, HackTricks Cloud's entry on Azure SRE Agent privilege escalation, describes the structural version of this problem without citing CVE-2026-62830. It lists control-plane operations that let a caller steer an agent — opening a thread, approving a proposed remediation, rebinding the agent's configuration, repointing a data connector — and frames the result as a confused deputy: the caller does not need the agent's permissions, only a way to make the agent use them. That entry is not about this CVE and should not be read as corroboration of it. It is useful for the same reason the score is: it shows where the authority actually sits.

The mechanism: what the archive describes, and what the vendor confirms

The archive's entry describes the flaw as a failure in what it calls the Scope-Changed OBO (on-behalf-of) flow. An on-behalf-of flow is a token exchange in which one service swaps a caller's credential for a token that lets it call a downstream service as that caller. If the authority check at that exchange fails, the archive says, the downstream call can fall back to the agent's own tenant-scoped managed identity instead of the caller's identity. A low-privileged but authenticated caller would then inherit the agent's service-principal permissions and could modify runbooks, telemetry and infrastructure — not just the agent, but every Azure resource the managed identity holds a role on.

That description is coherent with everything Microsoft did publish, and it is not in what Microsoft published. The vendor's text confirms three pieces: the authorization check was missing, the caller needs only low privileges, and the impact crosses a security-authority boundary. It does not confirm the token exchange, the identity inheritance, or the runbook and telemetry examples. The archive's entry is the source for those, and the archive is a secondary dataset, not the vendor.

A search for independent reporting turns up the same paragraph in more than one place: the headline about the OBO flow and the blast radius appears syndicated on forkast.news and on Yahoo Tech, among others. Syndication makes that coverage one source, not several. No outlet reviewed for this article published its own telemetry, proof of concept or reproduction of the mechanism.

What is established, what is described, and what was never claimed

The archive grades this record A — well documented, primary sources agree — and does not mark it disputed. It records no real-world harm. That grade is about the record's core facts, and those do agree across the sources; it is not a claim that every sentence in the entry has been independently reproduced.

• Established by the vendor. CVE-2026-62830 affects Azure SRE Agent, is CWE-862 missing authorization, carries a CVSS 3.1 base score of 9.9 and a temporal score of 8.6, required no customer action, was not publicly disclosed, and has not been recorded as exploited.

• Established by independent security reporting and enrichment. Cisco Talos's August 2026 Patch Tuesday roundup lists the CVE with the same 9.9 and the same missing-authorization weakness, and places it under Microsoft's "less likely" exploitation assessment. CISA's SSVC evaluation, recorded through NVD, rates exploitation as none, automatable as no, and technical impact as total. OpenCVE's enrichment lists an EPSS score of 0.00778 and records that the CVE is not in CISA's Known Exploited Vulnerabilities catalogue.

• Described, not independently confirmed. The OBO token-exchange failure, the inheritance of the agent's managed identity, and the runbook, telemetry and infrastructure consequences come from the archive's entry and from syndicated secondary coverage. Microsoft's advisory does not name them. They are the most useful part of the record and the least documented part of it.

• Not established anywhere. No exploitation, no victim, no public proof of concept, no build number and no affected-version range. Microsoft's exploitability line — publicly disclosed No, exploited No, less likely — is the closest thing to a status report that exists.

• Mainstream coverage is absent. Searches for this CVE across general technology and security press returned no article from The Register, BleepingComputer, SecurityWeek or Help Net Security. Its public footprint is the vendor advisory, vulnerability databases, a Patch Tuesday roundup and the syndicated piece. For a 9.9 that is unusual, and it is a fact about the record rather than a judgment about the risk.

The fix, and the checks that outlast it

Because Azure SRE Agent is a hosted service, the fix was applied on Microsoft's side. There is no update to install, no build number to compare against an inventory, and no way for a customer to confirm from the outside that a tenant was protected before a given date. Microsoft's position is that no action is required, and for the vulnerability itself that position is correct.

The archive's entry adds guidance the advisory does not spell out: audit managed identity assignments, review RBAC against what the agent actually needs, and monitor for anomalous privilege escalation. That guidance is the archive's, not a quotation from Microsoft.

The practical consequence follows from the architecture rather than from any source's recommendation, so treat it as inference. If the agent's authority is its role assignments, then the durable controls are the scope of those assignments and the retention of the control-plane logs that would show them being used. A service-side fix closes the path; it does not retroactively narrow a managed identity that was over-provisioned, and it cannot help an organisation that did not keep the logs. Both of those are things a customer still owns after the CVE is closed.

Where it sits in the August 2026 batch

Talos's roundup makes the comparison unavoidable. That month it also lists CVE-2026-59118 in Copilot Cowork, an elevation of privilege through improper authorization scored 9.3, and CVE-2026-56162 in Azure SQL Database, an elevation of privilege scored 10.0. The one vulnerability Talos reports as exploited in the wild that month was neither of these: it was CVE-2026-68820, in Windows AFD for WinSock. The AI-product entries in Talos's list are authorization bugs, and that is the specific shape of the risk this record documents.

None of that makes CVE-2026-62830 a breach. It is a transparency CVE for a service that was already fixed, published so that customers can see what was wrong and check their own configurations. The record's value is the configuration question it leaves behind — what the agent's identity could reach, and whether anyone would have noticed it being used — not a patch to schedule.