In March 2026, security researcher Justin O’Leary uncovered a privilege escalation flaw inside Azure Backup for AKS that would spark a heated dispute over disclosure. Microsoft rejected the report, claimed the behavior was expected, and blocked a Common Vulnerabilities and Exposures (CVE) identifier. Yet after the researcher went public, the original attack path stopped working — new errors appeared, and permission checks emerged. This incident raises uncomfortable questions about silent patching and the visibility defenders rely on. Let us walk through what happened, why it matters, and how you can protect your clusters.
The Discovery: A Privilege Escalation Flaw in Azure Backup for AKS
Justin O’Leary, a security researcher with a focus on cloud infrastructure, was examining Azure Backup for Azure Kubernetes Service (AKS) when he stumbled upon a troubling interaction. The feature uses Trusted Access to grant backup extensions elevated permissions inside a Kubernetes cluster. Under normal design, a user must already hold Kubernetes-level privileges to enable and manage backups. O’Leary found a way around that requirement.
Specifically, a user assigned only the Backup Contributor role on a Recovery Services vault could trigger the Trusted Access relationship without holding any Kubernetes RBAC permissions. That meant someone with a low-privilege Azure role could gain cluster-admin access inside a target AKS cluster. O’Leary classified this as a Confused Deputy vulnerability (CWE-441), where Azure RBAC and Kubernetes RBAC trust boundaries blurred in a way that bypassed expected authorization controls.
The attack path did not require existing admin rights. According to O’Leary, an attacker could enable backup on a target AKS cluster, causing Azure to automatically configure Trusted Access with cluster-admin privileges. From there, they could extract secrets through backup operations or restore malicious workloads into the cluster. This is exactly the kind of cross-boundary escalation that security teams dread.
O’Leary reported the issue to Microsoft on March 17, 2026, providing a detailed proof of concept. He expected a swift acknowledgment. Instead, he received a rejection.
Microsoft’s Response: Rejection and Dispute
On April 13, 2026, the Microsoft Security Response Center (MSRC) closed the report. Their reasoning: the vulnerability only allowed an attacker to obtain cluster-admin on a cluster where they already held administrator access. O’Leary strongly disputed that characterization. “This is factually incorrect,” he stated. “The vulnerability allows a user with zero Kubernetes permissions to gain cluster-admin. The attack does not require existing cluster access — it grants it.”
Microsoft also described the submission to MITRE as “AI-generated content,” a remark O’Leary felt sidestepped the technical merits. The company’s stance was clear: this was not a security vulnerability but expected behavior that required pre-existing administrative privileges. Consequently, no CVE or CVSS score was issued.
According to Microsoft’s spokesperson, who spoke with BleepingComputer after the story broke, “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.”
This was not the end of the matter.
CERT/CC Validation and the Blocked CVE
After Microsoft rejected his report, O’Leary escalated the issue to the CERT Coordination Center (CERT/CC). On April 16, 2026, CERT/CC independently validated the vulnerability. They assigned it an identifier, VU#284781, and scheduled public disclosure for June 1, 2026.
CERT/CC operates under a hierarchy of Common Vulnerability Enumeration (CVE) Numbering Authorities (CNAs). Microsoft is a CNA for its own products. On May 4, 2026, Microsoft staff reportedly contacted MITRE, recommending against assigning a CVE. They reiterated the same argument: the issue required pre-existing administrative access.
Under CNA hierarchy rules, CERT/CC closed the case, leaving Microsoft as the final authority on whether to issue a CVE for its own product. Microsoft chose not to. No public advisory, no CVE number, no official acknowledgment. The researcher was left with a validated vulnerability and no way to share a standard identifier with the security community.
The case highlights a structural challenge: when a CNA disagrees with an external validator, the CNA holds the cards. Defenders are left without a CVE to track, prioritize, or communicate about the flaw.
The Technical Details: How the Azure Backup AKS Vulnerability Worked
Understanding the flaw requires a look at Azure Backup for AKS and its Trusted Access feature. Trusted Access allows Azure services to securely connect to AKS clusters by automatically creating role bindings. In this case, the backup service extension required cluster-admin permissions inside the target cluster.
According to O’Leary, a user with only the Backup Contributor role on a backup vault could trigger the Trusted Access flow. Azure would then automatically create a cluster-admin role binding for the backup service. The user did not need any Kubernetes Role-Based Access Control (RBAC) permissions beforehand. The trust boundary between Azure RBAC and Kubernetes RBAC was effectively bypassed.
Once the Trusted Access binding existed, the attacker could perform backup and restore operations. Backup operations can include secrets, configuration data, and persistent volumes. Restore operations allow injecting arbitrary workloads. In short, the attacker could extract sensitive data or plant malicious containers inside the cluster — all starting from a low-privilege Azure role.
This is a classic Confused Deputy problem. The “deputy” in this case is the Azure Backup extension. It acts on behalf of the user, but the authorization check happened only at the Azure RBAC level, not at the Kubernetes RBAC level where cluster-admin permissions were actually granted.
Evidence of a Silent Patch
After O’Leary published his findings in June 2026, he noticed something odd. The original exploit path no longer worked. Commands that previously succeeded now returned errors like UserErrorTrustedAccessGatewayReturnedForbidden with the message “The Trusted Access role binding is missing/has gotten removed.”
Furthermore, Azure Backup for AKS now requires Trusted Access to be manually configured before backup can be enabled. Previously, enabling backup automatically configured the Trusted Access link. This change represents a material shift in behavior — one that directly addresses the vulnerability O’Leary reported.
Microsoft insists no product changes were made. Yet the evidence strongly suggests a silent patch. New permission checks, new error messages, and a new prerequisite all appeared after disclosure. If no code changed, how did the behavior change? The researcher and many in the security community interpret this as a silent fix without a CVE or advisory.
Silent patching creates real problems for defenders. Without a CVE, there is no way to track which clusters were vulnerable, which versions are affected, or when the fix was applied. Security teams cannot assess risk, prioritize updates, or communicate to auditors. It also erodes trust between the security community and the vendor.
You may also enjoy reading: The Ultimate Tech Pack Checklist: Key Considerations for Fashion Designers.
Implications for Security Teams
The absence of a CVE for this azure backup aks vulnerability means that many organizations remain unaware of the risk. If your team relies exclusively on CVE lists for vulnerability tracking, this incident fell through the cracks. Even if Microsoft quietly fixed the behavior, legacy clusters or configurations that predate the change may still be vulnerable.
Additionally, the vulnerability highlights the complexity of cross-service permissions in cloud environments. Azure RBAC and Kubernetes RBAC operate on different planes. The mistake was assuming that Azure-level authorization was sufficient to grant Kubernetes cluster-admin privileges. This is a boundary that security teams must actively monitor.
Another concern is the precedent this sets for future disclosures. If a major cloud provider can reject a validated vulnerability, block a CVE, and silently patch, researchers may become less willing to report flaws. That would leave everyone less safe.
For organizations using Azure Backup for AKS, the incident underscores the need to verify Trusted Access configurations manually. Do not assume that the default behavior is secure. Review role assignments, audit role bindings, and ensure that backup users do not have more permissions than intended.
What Organizations Should Do Now
Even without an official CVE, there are practical steps to secure your AKS clusters against this class of vulnerability.
Audit Trusted Access Bindings
List all Trusted Access relationships in your AKS clusters. Use the Azure CLI or portal to see which Azure resources have role bindings. Confirm that backup vaults are the only services with elevated permissions, and that those permissions are necessary.
Limit Backup Contributor Role
Review who holds the Backup Contributor role on your Recovery Services vaults. This role grants the ability to enable backup on AKS clusters. If a user does not need to configure backup for multiple clusters, restrict their scope. Use Azure RBAC scoping to limit the vaults and resources they can access.
Enable Manual Trusted Access Configuration
The current behavior requires manual configuration of Trusted Access. Make sure your IaC templates and scripts enforce this. Do not rely on automatic provisioning of Trusted Access, even if earlier documentation suggested it was acceptable.
Monitor for Unexpected Role Bindings
Set up Azure Policy or custom alerts to detect when new cluster-admin role bindings are created in your AKS clusters. Use Kubernetes audit logs and Azure Monitor to track changes to RBAC resources. Any unexpected binding should trigger an investigation.
Stay Informed Beyond CVEs
Security bulletins are not the only source of truth. Follow respected researchers, contribute to security mailing lists, and monitor cloud provider release notes. In this case, following Justin O’Leary on social media provided more transparency than Microsoft’s official channels.
Test Your Own Environments
If you have a testing subscription, try reproducing the original attack path (with appropriate controls). See if your clusters still allow automatic Trusted Access creation from a low-privilege role. This hands-on approach will reveal any lingering misconfigurations.
The lack of a CVE for this azure backup aks vulnerability does not mean the risk is gone. It means the responsibility lies with your team to detect and mitigate it. Treat this as a lesson in defense-in-depth across Azure and Kubernetes boundaries.
Cloud security is still maturing. This incident shows that trust boundaries can blur, and vendors may not always prioritize transparency. As a defender, your best asset is a skeptical eye and a willingness to verify every permission chain — especially those that span multiple authorization systems.
