Confused Deputy in Azure Backup and AKS exposes non-CVE organizations

A security researcher claims that Microsoft silently solved a critical vulnerability in Azure Backup for AKS after rejecting its report and blocking the issuance of a CVE, leaving organizations without a clear way to measure their exposure. According to the researcher, the failure allowed to scale privileges from the low-confidence "Backup Contributor" role to cluster-admin permissions in Kubernetes, exploiting the way Azure sets up Trusted Access relationships for backups.

The technique described fits what the community knows as a type of attack Confused Deputy where the interaction between Azure RBAC and Kubernetes RBAC breaks the expected authorisation barriers and allows an identity with limited permits to activate the elevation. The researcher's own technical report explains how to activate backup support in a target cluster forced Azure to create trust links with administrator privileges in Kubernetes, operations that could be used to extract secrets or restore malicious loads in the cluster; see the original explanation here: olearysec.com.

The chronology that facilitates the case shows regular tensions in responsible disclosure processes: the initial discovery and shipment occurred in March, Microsoft Security Response Center (MSRC) rejected the rating as vulnerability on the grounds that the attack required prior administrative access, and the discussion escalated CERT / CC, which validated the failure and assigned an identifier (VU # 284781). Microsoft then asked MITRE not to be assigned a CVE, and the application of CNAs hierarchy rules left Microsoft with the final power to issue the CVE or not; CNA rules are available at: cve.org. The episode was publicly reported by specialized media covering the dispute and the apparent correction: BleepingComputer.

The most disturbing thing for defenders is that, following the disclosure, the researcher observed operational changes that prevented the reproduction of the original explosion: manual steps are now required to configure Trusted Access and additional permissions checks appear on the identities managed by the vault and the cluster, which suggests an applied correction on the supplier's side without formal notice. Microsoft states that no "product changes" were made because the previous behavior, as assessed, was expected; the researcher and CERT / CC disagreed with that interpretation.

This case has several practical and security government implications. Without a CVE or public advice security equipment cannot quantify the number of resources exposed, the temporary risk window or prioritize remediations based on an affected inventory. In addition, silent corrections make it difficult to independently validate mitigation and reduce legal and operational traceability in regulated environments. The dispute also reveals frictions in the triage of reports, including the controversial mention of content "generated by IA" as a factor that distracts from technical analysis.

For security teams that manage AKS and Azure Backup, I recommend acting immediately: audit and list all the assignments of the role Backup contributor in all vaults and subscriptions, confirm if any managed identity (MSI) has unexpected permits on clusters or groups of snapshots resources, and check the Trusted Access configuration in the AKS clusters. Activate and review access control logs, RBAC bindings change alerts and backup enabling operations, and consider rotating secrets / credentials that might have been compromised. Implement less privileged policies and administrative restrictions on who can enable backups and manage vault identities, and use Azure Policy and Azure Monitor to automate detection and blocking of unauthorized changes.

In addition, document and record any interaction with the supplier: request written confirmation of the changes applied, time frames and mitigation scope, and require technical advice or a CVE to track exposure in vulnerability management tools. If you manage environments with compliance requirements, include this review in the next access control audit and risk management processes.

The episode highlights a broader need: CNAs outreach programs and hierarchies must balance ecosystem protection and transparency towards customers. As long as there is no mechanism that aligns incentives to report corrections and issue CVEs impartially where appropriate, organizations and defenders will continue to face a Insufficient visibility window which complicates effective cloud risk mitigation.