Security researcher Justin O’Leary disclosed in May 2026 that a critical privilege escalation vulnerability in Azure Backup for AKS allows an attacker holding only the Azure-level “Backup Contributor” role and zero Kubernetes permissions to obtain cluster-admin access on any AKS cluster in scope. Microsoft rejected the vulnerability report, blocked CVE assignment through MITRE, and subsequently deployed a silent fix while publicly maintaining that “no product changes were made.”
CERT/CC independently validated the vulnerability, assigning it tracking identifier VU#284781. No public Microsoft advisory exists. AKS customers were not notified.
The vulnerability
Azure Backup for AKS is a Microsoft-managed backup service for Azure Kubernetes Service clusters. It uses a mechanism called Trusted Access to grant backup extensions elevated permissions inside the Kubernetes clusters they protect. Trusted Access is the legitimate path through which the backup service reaches into a cluster to take snapshots of workloads.
O’Leary found that the Trusted Access binding process could be manipulated by a user holding only the “Backup Contributor” Azure Resource Manager role. This role is intended to allow the configuration and management of backup jobs at the Azure control plane level. It grants no access to Kubernetes clusters themselves. A user in this role has no Kubernetes RBAC permissions, cannot list pods, and cannot authenticate to the Kubernetes API in any normal sense.
However, O’Leary demonstrated that a user in this role could abuse the Trusted Access mechanism to create a binding that granted cluster-admin, the highest possible Kubernetes permission level, on any AKS cluster in scope. The attack does not require existing cluster access. It creates it.
The researcher assigned the vulnerability a CVSS score of 9.9, reflecting the combination of low privilege requirements at the Azure level, no required interaction from a cluster owner or administrator, and the severity of the resulting access: full cluster-admin on a production Kubernetes cluster.
Microsoft’s rejection and CVE blocking
O’Leary reported the vulnerability to Microsoft’s Security Response Center on 17 March 2026. Microsoft rejected the report on 13 April, characterising the issue as one where “the attacker already held administrator access.” O’Leary disputes this characterisation with technical documentation showing that the exploit path begins from a user with zero Kubernetes permissions, not from an existing administrator.
Following Microsoft’s rejection, O’Leary escalated to CERT/CC. CERT/CC independently reproduced the vulnerability and validated the finding on 16 April, assigning it VU#284781. On 4 May, however, Microsoft staff contacted MITRE to recommend against CVE assignment. Under MITRE’s CNA hierarchy rules, a vendor CNA holds authority over CVE assignments for its own products. CERT/CC closed the case accordingly, leaving Microsoft with unilateral authority over the issuance of any public CVE identifier for the vulnerability.
Microsoft told BleepingComputer that the reported behaviour was expected and that “no product changes were made.”
The silent patch
After O’Leary’s disclosure period concluded, the researcher documented that the same exploit path that had worked consistently throughout his research began to fail. New permission checks appeared in the Trusted Access binding flow that had not been present when he developed and tested the exploit. The researcher’s public write-up at OLearySec details the specific behavioural changes that are consistent with a targeted code fix.
No Microsoft security advisory has been published. There is no public record of when the vulnerability was introduced, when it was addressed, or what window of exposure AKS customers experienced.
The systemic issue
The Azure Backup for AKS case raises a governance question that extends beyond any single vulnerability. Under MITRE’s CNA framework, a vendor CNA has substantial authority over whether vulnerabilities in its own products receive CVE identifiers. This authority exists partly for efficiency: vendors often have the best context for their own code and can assess whether a reported behaviour is a security defect or an expected operational characteristic.
The tradeoff is that a vendor CNA can reject an externally reported vulnerability, block the CVE assignment process, and then address the issue through an internal change that is never disclosed to customers. The result is that customers who rely on the CVE feed, on Microsoft’s own security advisories, or on tools such as Defender for Cloud to track the vulnerability status of their Azure infrastructure receive no signal that a critical privilege escalation existed and was addressed.
This is not theoretical. AKS operators who had the Azure Backup for AKS extension configured during the window between the vulnerability’s existence and Microsoft’s undisclosed fix had Kubernetes clusters that were accessible to any user in the Backup Contributor role. Without a CVE, without an advisory, and without customer notification, there is no mechanism for those operators to know this was the case, to audit their audit logs for exploitation, or to assess their exposure.
What AKS operators should do
If your organisation runs Azure Kubernetes Service with Azure Backup for AKS configured, review the permissions assigned to every service principal, managed identity, and user account holding the Azure “Backup Contributor” role across your subscriptions. Verify that none of those identities should have had cluster-admin access and that no unexpected Trusted Access bindings appear in your cluster configurations.
Audit Kubernetes API server audit logs for unexpected cluster-admin bindings, particularly any created through the Trusted Access mechanism, during the period from March through May 2026.
Apply the principle of least privilege to all Azure roles that interact with AKS clusters. Where possible, scope the Backup Contributor role to specific resource groups rather than subscription-wide assignments. Regularly review Trusted Access bindings in your clusters to verify that they reflect only the integrations you have intentionally configured and authorised.
If your organisation runs Azure Kubernetes Service and wants an independent review of its AKS security configuration, Trusted Access bindings, RBAC posture, or exposure during the relevant window, contact Excello Digital. We help European engineering teams close the gap between vendor disclosure timelines and the assurance they actually need about the security of their cloud infrastructure.