17.05.2026
4 min
170
A security researcher said Microsoft refused to acknowledge a critical vulnerability in Azure that could have exposed third-party cloud resources and telemetry data. The company did not issue a CVE and called the issue a result of customer configuration, not a defect in the platform itself.
A security researcher says Microsoft quietly fixed a significant flaw in its backup service for use with Azure Kubernetes Service (AKS) after the researcher’s report was denied and the relevant CVE was restricted. The weakness may allow a malicious actor to become the administrator of a Kubernetes cluster even if they only possess the low-level privileged “Backup Contributor” role.
Justin O’Leary reported the weakness to Microsoft’s Security Response Center on March 17. However, on April 13, Microsoft told him it was not a flaw since the bad guy would have had to be a cluster admin in order to do what he wanted to do. That was totally wrong according to O’Leary.
“That is factually incorrect,” the researcher stated. “This vulnerability will give users who are not entitled to execute actions against the cluster admin privileges. It also doesn’t require you to already have access to your cluster; instead, it gives you access.”
O’Leary then reached out to CERT/CC. They were able to confirm the issue independent of O’Leary. CERT gave it a VU #284781 identifier. Initially, the public announcement was to occur on June 1st. However, that did happen.
According to the researcher, Microsoft contacted MITRE on May 4th asking them not to issue a CVE for the issue. The company again insisted that the attack required administrative access first.
CERT/CC ultimately closed the case due to CNA hierarchy rules, as Microsoft has the authority to issue CVEs for its own products.
The issue involved Azure Backup for AKS and the Trusted Access mechanism used to back up Kubernetes clusters.
The Azure Backup for AKS service uses Trusted Access to grant cluster admin privileges to the backup extension in Kubernetes clusters.
According to O’Leary, the flaw allowed anyone with only the Backup Contributor role on the backup repository to activate this Trusted Access relationship without first having Kubernetes permissions.
An attacker could enable backup on the target AKS cluster, which would automatically configure Azure Trusted Access with cluster admin privileges. From there, the attacker could extract secrets through backup operations or restore malicious workloads to 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 way that bypassed expected authorization controls.
A Microsoft spokesperson said:
“Our assessment concluded that this was not a security vulnerability, but rather expected behavior that requires pre-existing administrative privileges in the customer’s environment. Therefore, no changes were made to the product to address this issue, and no CVE or CVSS scores were provided.” However, after publishing his report this month, O’Leary noted that the original attack vector no longer works.
“The current behavior returns errors that did not exist in March 2026,” he says:
ERROR: UserErrorTrustedAccessGatewayReturnedForbidden
“Trusted Access role binding missing/has been removed”
According to O’Leary, you now need to manually configure Trusted Access before enabling Azure Backup for AKS backups, which changes the previous behavior where Azure configured it automatically.
