Azure Backup AKS Privilege Escalation: No CVE Issued

A security researcher says Microsoft silently fixed a critical Azure Backup for AKS privilege escalation vulnerability after rejecting his report and blocking a CVE assignment. The vulnerability allowed a user with only the low-privileged "Backup Contributor" role to gain full cluster-admin access on a Kubernetes cluster, with zero pre-existing Kubernetes permissions required.

Microsoft told BleepingComputer the behavior was expected and that "no product changes were made." The attack path no longer works.

How the Azure Backup for AKS Privilege Escalation Worked

Azure Backup for AKS uses Microsoft's Trusted Access feature to grant backup extensions cluster-admin privileges inside Kubernetes clusters. The flaw, discovered by researcher Justin O'Leary in March 2026, lived in how that Trusted Access relationship gets configured.

Anyone holding the Backup Contributor role on a backup vault could trigger Trusted Access configuration on a target AKS cluster without already having any Kubernetes-level permissions. Azure would then automatically configure the Trusted Access binding, granting cluster-admin rights. From that position, an attacker could extract secrets through backup operations or restore malicious workloads directly into the cluster.

O'Leary classified this as a Confused Deputy vulnerability (CWE-441). The problem is a trust boundary mismatch between Azure RBAC and Kubernetes RBAC, where Azure's authorization logic effectively acted on behalf of a low-privileged caller without verifying their Kubernetes standing.

Microsoft's Response and the CERT Escalation

O'Leary reported the flaw to Microsoft on March 17, 2026. MSRC rejected it on April 13, arguing the attack required the attacker to already hold administrator access on the cluster. O'Leary called that characterization factually wrong. The vulnerability grants cluster access, it does not require it.

CERT/CC independently validated the flaw on April 16 and assigned tracking identifier VU#284781, scheduling public disclosure for June 1, 2026. That disclosure never happened. On May 4, Microsoft reportedly contacted MITRE recommending against CVE assignment, again citing the pre-existing admin access argument. Under CNA hierarchy rules, Microsoft as a CNA retains final authority over CVE issuance for its own products. CERT/CC closed the case.

Microsoft's official statement: "no product changes were made to address this report and no CVE or CVSS score were issued."

What Changed After Disclosure

After O'Leary published his findings in May 2026, the original attack path stopped working. Azure Backup for AKS now returns errors that did not exist during his March testing.

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

Azure Backup now requires Trusted Access to be manually configured before backup can be enabled, reversing the earlier automatic configuration behavior. New permission checks were added. The vault MSI now requires Reader permissions on both the AKS cluster and snapshot resource group. The AKS cluster MSI now requires Contributor permissions on the snapshot resource group. None of these checks existed during the original March testing.

Something changed. Microsoft maintains nothing did.

Impact on Defenders and Security Teams

Without a CVE or public advisory, organizations using Azure Backup for AKS have no official record of the exposure window. Security teams cannot track the vulnerability in their patch management systems. There is no remediation timeline to reference and no CVSS score to prioritize against other risks.

O'Leary puts it plainly: "Organizations that granted Backup Contributor between an unknown start date and May 2026 were exposed to privilege escalation. Without a CVE, security teams cannot track this exposure. Silent patching protects vendors, not customers."

If you have granted the Backup Contributor role to any principal in your Azure environment, audit those assignments now. Review who had that role between January and May 2026. Check Kubernetes audit logs for unexpected cluster-admin bindings. Verify that Trusted Access configurations on your AKS clusters match what your team manually authorized.

Cloud security posture tools won't catch a vulnerability that has no CVE. Scanning your AKS-adjacent attack surface directly is the more reliable option. The VibeWShield scanner can help surface misconfigurations and privilege escalation paths in your web-facing infrastructure before they become silent disclosures.

For more context on cloud privilege escalation patterns, see our guide to Confused Deputy vulnerabilities in cloud environments.

What is a Confused Deputy vulnerability in Azure RBAC? A Confused Deputy flaw occurs when a service acts on behalf of a caller without verifying the caller has sufficient permissions in the target system. In this case, Azure RBAC allowed a low-privileged role to trigger a Kubernetes-level cluster-admin binding via the Trusted Access mechanism, bypassing Kubernetes RBAC entirely.

Can Microsoft block a CVE from being issued for its own products? Yes. Microsoft is a CVE Numbering Authority (CNA). Under MITRE's CNA hierarchy rules, CNAs have authority over CVE assignment for products within their scope. If Microsoft determines a report does not meet vulnerability criteria, it can recommend against CVE issuance, and CERT/CC must defer to that hierarchy when the vendor disputes the finding.

How do I know if my AKS clusters were exposed? Check your Azure RBAC assignments for anyone holding the Backup Contributor role on backup vaults between early 2026 and May 2026. Review Kubernetes audit logs for cluster-admin role bindings that were not manually configured by your team. If you find unexpected bindings, treat the cluster as compromised and rotate credentials and secrets accordingly.

Run an automated scan of your Azure-connected web infrastructure at VibeWShield to catch privilege escalation paths and