Security & privacy

Microsoft rejects critical Azure vulnerability report, no cve issued

At a glance:

  • Critical privilege escalation flaw in Azure Backup for AKS reported by researcher Justin O'Leary.
  • Microsoft classified the issue as expected behavior, made no product changes and blocked a CVE.
  • CERT/CC validated the bug (VU#284781) and observed a silent patch despite the lack of a public advisory.

Report and Microsoft response

Security researcher Justin O'Leary discovered a privilege‑escalation flaw in Azure Backup for Azure Kubernetes Service (AKS) in March 2026 and submitted a detailed report to the Microsoft Security Response Center on March 17. The report described how a user with the low‑privileged "Backup Contributor" role could obtain full cluster‑admin rights, a scenario O'Leary labeled a critical vulnerability.

Microsoft replied on April 13, rejecting the report and stating that the behavior was "expected" and required pre‑existing administrative access. The company asserted that no product changes were made and that no CVE or CVSS score would be issued. O'Leary countered that the claim misrepresented the attack, emphasizing that the exploit works from a zero‑permissions state and does not need prior admin rights.

How the attack worked

Azure Backup for AKS leverages Trusted Access to automatically grant backup extensions cluster‑admin privileges inside a Kubernetes cluster. The flaw allowed anyone with only the Backup Contributor role on a backup vault to trigger this Trusted Access relationship without any Kubernetes permissions. An attacker could:

  1. Enable backup on a target AKS cluster.
  2. Cause Azure to automatically configure Trusted Access with cluster‑admin rights.
  3. Use the elevated rights to extract secrets or restore malicious workloads.

O'Leary classified the issue as a Confused Deputy vulnerability (CWE‑441), where Azure RBAC and Kubernetes RBAC trust boundaries intersected in a way that bypassed normal authorization checks.

CERT validation and CVE dispute

After Microsoft’s rejection, O'Leary escalated the matter to the CERT Coordination Center (CERT/CC). On April 16, CERT/CC independently validated the vulnerability and assigned it the tracking identifier VU#284781. The agency initially scheduled public disclosure for June 1, 2026, but the disclosure never occurred.

On May 4, Microsoft staff reportedly contacted MITRE, recommending that a CVE not be assigned, again arguing that the issue required pre‑existing admin access. CERT/CC later closed the case under CNA hierarchy rules, leaving Microsoft—being a CNA itself—with final authority over CVE issuance for its products.

Evidence of a silent patch

Although Microsoft claimed no changes were made, O'Leary observed that the original attack path stopped working after his disclosure. New error messages appeared, such as:

ERROR: UserErrorTrustedAccessGatewayReturnedForbidden
"The Trusted Access role binding is missing/has gotten removed"

He further noted that Azure Backup for AKS now requires manual configuration of Trusted Access before backup can be enabled, reversing the prior automatic behavior. Additional permission checks were added: the vault managed identity now needs Reader rights on both the AKS cluster and its snapshot resource group, while the AKS cluster managed identity requires Contributor rights on the snapshot resource group. These changes indicate a silent patch was applied without a public advisory or customer notification.

Broader implications for security disclosure

The lack of a CVE or advisory leaves defenders without visibility into the exposure window or remediation timeline, forcing security teams to rely on undocumented, vendor‑specific signals. O'Leary warns that organizations that granted Backup Contributor privileges between an unknown start date and May 2026 were exposed to privilege escalation.

The case underscores a growing tension between security researchers and large cloud providers over vulnerability severity, exploitability, and disclosure practices. It also highlights concerns that AI‑generated reports are overwhelming triage systems, potentially obscuring genuine findings. Without a transparent framework that aligns incentives for vendors, researchers, and defenders, responsible disclosure risks becoming a bureaucratic exercise that benefits none.

Editorial SiliconFeed is an automated feed: facts are checked against sources; copy is normalized and lightly edited for readers.

FAQ

What was the vulnerability discovered in Azure Backup for AKS?
The flaw allowed a user with only the Backup Contributor role on a backup vault to automatically trigger Trusted Access, granting cluster‑admin privileges in the AKS cluster. This enabled privilege escalation from zero Kubernetes permissions to full control, letting attackers extract secrets or deploy malicious workloads.
Why did Microsoft refuse to assign a CVE to the issue?
Microsoft argued that the exploit required pre‑existing administrative access and therefore represented expected behavior, not a security vulnerability. The company communicated this stance to both the researcher and MITRE, and recommended against CVE issuance, despite evidence of a silent patch.
How did researchers determine that Microsoft had silently patched the bug?
After the report, O'Leary observed that the original attack path no longer succeeded and new error messages appeared, indicating missing Trusted Access role bindings. Additional permission checks were introduced, requiring manual Trusted Access configuration and extra RBAC rights, confirming that Microsoft changed the behavior without publishing an advisory or CVE.

More in the feed

Prepared by the editorial stack from public data and external sources.

Original article