Microsoft blocks – A security researcher says Microsoft quietly fixed a privilege-escalation issue in Azure Backup for AKS after rejecting his report and blocking a CVE. CERT Coordination Center validated the problem and assigned tracking identifier VU#284781, but the public dis
A security researcher who reported a critical privilege-escalation issue in Azure Backup for AKS says Microsoft rejected his report. blocked a CVE from being issued. and then appeared to reverse the vulnerable behavior without telling customers.. The dispute has left defenders with limited visibility while the core technical disagreement—how the flaw works and whether it should be treated as a vulnerability—plays out in the open.
Justin O’Leary says he discovered the flaw this March and submitted it to Microsoft on March 17.. Microsoft’s Security Response Center (MSRC) rejected the report on April 13. arguing the issue only involved obtaining cluster-admin on a cluster where the attacker already held administrator access.. O’Leary called that description “factually incorrect,” saying: “The vulnerability allows a user with zero Kubernetes permissions to gain cluster-admin.. The attack does not require existing cluster access — it grants it.”
The back-and-forth then widened beyond the technical merits.. O’Leary says Microsoft described the submission to MITRE as “AI-generated content,” without addressing the technical substance of his report.. After the rejection. he escalated the issue to the CERT Coordination Center. which independently validated the vulnerability on April 16 and—according to O’Leary—assigned it an identifier. VU#284781.
CERT/CC had initially scheduled public disclosure for June 1, 2026, but that disclosure never happened. Later, Microsoft staff reportedly contacted MITRE on May 4 recommending against CVE assignment, again framing the problem as one that 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 dispute hinges on how Azure Backup for AKS uses Trusted Access.. O’Leary says Trusted Access grants backup extensions cluster-admin privileges inside Kubernetes clusters.. In his description. someone with only the “Backup Contributor” role on a backup vault could trigger that Trusted Access relationship without already having Kubernetes permissions.
He describes an attacker enabling backup on a target AKS cluster. after which Azure automatically configured Trusted Access with cluster-admin privileges.. From there, O’Leary says the attacker could extract secrets through backup operations or restore malicious workloads into the cluster.. He classified the issue as a Confused Deputy vulnerability (CWE-441). where Azure RBAC and Kubernetes RBAC trust boundaries interact in a way that bypasses expected authorization controls.
Microsoft disputes the idea that the behavior amounts to a security vulnerability.. In a statement to BleepingComputer. a Microsoft spokesperson said: “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.”
But O’Leary says observation after disclosure tells a different story.. He reports that the original attack path no longer works. saying: “Current behavior returns errors that did not exist in March 2026.” The error he cites is: “ERROR: UserErrorTrustedAccessGatewayReturnedForbidden” and includes: “The Trusted Access role binding is missing/has gotten removed.” He also says 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.
O’Leary further claims additional permission checks appeared after his March testing.. He says the vault MSI now requires Reader permissions on both the AKS cluster and snapshot resource group. while the AKS cluster MSI requires Contributor permissions on the snapshot resource group.. In his telling. the vulnerability appears to have been fixed. yet Microsoft did not issue a public advisory or notify customers.
Without a CVE or advisory, he argues, defenders have less visibility into the exposure window or remediation timeline.. “Organizations that granted Backup Contributor between an unknown start date and May 2026 were exposed to privilege escalation,” O’Leary writes.. “Without a CVE, security teams cannot track this exposure.. Silent patching protects vendors, not customers.”
One tension runs through the case: multiple rounds of disagreement over severity and exploitability. with the disclosure path repeatedly constrained by the way vulnerability handling rules work between vendors. CERT/CC. and the CNA framework.. CERT/CC validation still led to closure under CNA hierarchy rules. and Microsoft’s rejection and CVE-blocking position remained decisive for its own products even as the behavior O’Leary observed shifted after the initial report.
The pattern is hard to miss in the timeline: the report was rejected by MSRC on April 13. CERT/CC validated the issue on April 16 and assigned VU#284781. the June 1. 2026 public disclosure never happened. and Microsoft then moved to recommend against CVE assignment on May 4—after which CERT/CC closed the case under CNA hierarchy rules.
The episode also points to a broader friction now common between large vendors and researchers: disputes over severity. exploitability. and what should be disclosed when.. The source describes how. amid increasing volumes of reports. even open-source maintainers have complained that AI-assisted submissions can overwhelm triage systems. making legitimate findings harder to act on quickly.. The same source adds that cases where big tech ignores patching valid flaws after repeated contact have become “not uncommon. ” underscoring the difficulty of responsible disclosure when incentives don’t align.
In O’Leary’s view. without a framework that realigns incentives for all parties. disclosure can turn into a bureaucratic exercise that serves neither researchers nor the organizations that remain exposed.. For defenders trying to map risk to concrete identifiers and timelines. the lack of a CVE or advisory keeps the gap between “fixed” and “known” wide—leaving security teams to piece together what changed after the fact.
Microsoft Azure Azure Backup for AKS Trusted Access Kubernetes privilege escalation CVE CERT/CC CNA hierarchy CVE rejection cybersecurity disclosure