Microsoft Rejects Critical Azure Vulnerability Report, No CVE Issued
Microsoft Rejects Critical Azure Vulnerability Report 🚨
A security researcher claims Microsoft quietly fixed an Azure Backup for AKS vulnerability after rejecting his report and blocking a CVE from being issued. The researcher’s report describes a critical privilege escalation flaw that allowed cluster-admin access from the low-privileged “Backup Contributor” role. Microsoft disputes the claim, telling BleepingComputer the behavior was expected and that no product changes were made, despite the researcher documenting new permission checks and failed exploit attempts after disclosure, suggestive of a silent patch.
Security researcher Justin O’Leary discovered the security flaw this March, reporting it to Microsoft on March 17. Microsoft Security Response Center (MSRC) rejected the report on April 13, claiming the issue only involved obtaining cluster-admin on a cluster where “the attacker already held administrator access,” a characterization O’Leary says misrepresents the attack entirely. The researcher stated, “‘This is factually incorrect,’… ‘The vulnerability allows a user with zero Kubernetes permissions to gain cluster-admin. The attack does not require existing cluster access – it grants it.’”
After the rejection, O’Leary escalated the issue to CERT Coordination Center, which independently validated the vulnerability on April 16 and, according to the researcher, assigned it an identifier, VU#284781. However, on May 4, Microsoft staff reportedly contacted MITRE recommending against CVE assignment, again arguing the issue required pre-existing administrative access. CERT/CC later closed the case under CNA hierarchy rules, effectively leaving Microsoft (which is a CNA) with final authority over CVE issuance for its own products.
The researcher detailed how the attack worked: Azure Backup for AKS uses Trusted Access to grant backup extensions cluster-admin privileges inside Kubernetes clusters. According to O’Leary, 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. From there, an attacker could extract secrets through backup operations or restore malicious workloads into the cluster. O’Leary classified the issue as a Confused Deputy vulnerability (CWE-441), where Azure RBAC and Kubernetes RBAC trust boundaries interacted in a manner that bypassed expected authorization controls.
Despite the apparent fix, a Microsoft spokesperson previously 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.” However, following the disclosure of his report this month, O’Leary observed that the original attack path no longer works. He states that “‘Current behavior returns errors that did not exist in March 2026,’… ‘The Trusted Access role binding is missing/has gotten removed.’” According to O’Leary, Azure Backup for AKS now requires Trusted Access to be manually configured before backup can be enabled, reversing the earlier behavior where Azure configured it automatically. He also observed additional permission checks that were absent during his original testing in March. In summary, the vulnerability appears to have been fixed, but Microsoft has neither issued a public advisory nor notified customers. The researcher emphasized the impact, stating, “‘Without a CVE, security teams cannot track this exposure. Silent patching protects vendors, not customers.’ Organizations that granted Backup Contributor between an unknown start date and May 2026 were exposed to privilege escalation.”