Azure Backup for AKS Vulnerability
A security researcher, Justin O'Leary, discovered a critical privilege escalation flaw in Azure Backup for AKS, which allowed cluster-admin access from the low-privileged "Backup Contributor" role. The researcher reported the issue to Microsoft on March 17, but the company rejected the report on April 13, claiming the issue only involved obtaining cluster-admin on a cluster where "the attacker already held administrator access."
Dispute Over Vulnerability
O'Leary disputes Microsoft's claim, stating that the vulnerability allows a user with zero Kubernetes permissions to gain cluster-admin, and that the attack does not require existing cluster access. The researcher further claims that Microsoft described the submission to MITRE as "AI-generated content," which did not address the technical merits of the report.
CERT/CC independently validated the vulnerability on April 16 and assigned it an identifier, VU#284781. However, Microsoft staff reportedly contacted MITRE recommending against CVE assignment, arguing that the issue required pre-existing administrative access.
How the Attack Worked
Azure Backup for AKS uses Trusted Access to grant backup extensions cluster-admin privileges inside Kubernetes clusters. The flaw allowed anyone with only the Backup Contributor role on a backup vault to trigger that Trusted Access relationship without already having Kubernetes permissions. An attacker could enable backup on a target AKS cluster, causing Azure to automatically configure Trusted Access with cluster-admin privileges.
Microsoft's Response
Microsoft says that no changes were made to address the report, and that the behavior was expected. However, O'Leary observed that the original attack path no longer works, and that Azure Backup for AKS now requires Trusted Access to be manually configured before backup can be enabled. The researcher also observed additional permission checks that were absent during his original testing in March.
A Microsoft spokesperson told BleepingComputer: "Our assessment concluded that this is not a security vulnerability, but rather expected behavior that requires pre-existing administrative privileges within the customer’s environment. Therefore, no product changes were made to address this report and no CVE or CVSS score were issued."
Implications
The rejection of the vulnerability report and the lack of a CVE or advisory have left defenders with little visibility into the exposure window or remediation timeline. O'Leary writes: "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."
The case highlights a structural problem with no easy fix, where disputes between security researchers and major vendors over severity, exploitability, and disclosure have become common. The lack of a framework that realigns incentives for all parties risks making responsible disclosure a bureaucratic exercise that serves no one—least of all the organizations left exposed in the dark.
- Microsoft rejected a critical Azure vulnerability report, claiming the issue was expected behavior.
- The researcher documented a silent patch, which appears to have fixed the vulnerability.
- The lack of a CVE or advisory has left defenders with little visibility into the exposure window or remediation timeline.
Without a framework that realigns incentives for all parties, responsible disclosure risks becoming a bureaucratic exercise that serves no one—least of all the organizations left exposed in the dark.
Source: BleepingComputer