A security expert alleges that Microsoft silently resolved an Azure Backup for AKS vulnerability after dismissing his report and preventing a CVE from being assigned.
The researcher’s submission outlines a critical privilege escalation flaw that enabled cluster-admin access from the low-privileged “Backup Contributor” role.
Microsoft contests the claim, informing BleepingComputer the behavior was intended and that “no product changes were made,” even though the researcher documented new permission checks and failed exploit attempts following disclosure, indicating a quiet fix.
CERT confirms it’s a bug, but Microsoft blocks CVE
Security researcher Justin O’Leary identified the security flaw this March and submitted it to Microsoft on March 17.
Microsoft Security Response Center (MSRC) dismissed the report on April 13, asserting the issue only concerned obtaining cluster-admin on a cluster where “the attacker already held administrator access,” a characterization O’Leary says completely misrepresents the attack.
“This is factually incorrect,” the researcher states.
“The vulnerability allows a user with zero Kubernetes permissions to gain cluster-admin. The attack does not require existing cluster access — it grants it.”
O’Leary further claims that Microsoft labeled the submission to MITRE as “AI-generated content,” which he says failed to address the technical substance of the report.
After the rejection, O’Leary escalated the issue to CERT Coordination Center, which independently confirmed the vulnerability on April 16 and, according to the researcher, assigned it an identifier, VU#284781:
(Justin O’Leary)
CERT/CC had originally planned public disclosure for June 1, 2026, but that disclosure never occurred.
On May 4, Microsoft staff reportedly contacted MITRE advising against CVE assignment, again arguing the issue required pre-existing administrative access:
(Justin O’Leary)
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.
How the attack worked
Azure Backup for AKS uses Trusted Access to grant backup extensions cluster-admin privileges inside Kubernetes clusters.
According to O’Leary, the flaw permitted anyone with only the Backup Contributor role on a backup vault to activate that Trusted Access relationship without already possessing Kubernetes permissions.
An attacker could enable backup on a target AKS cluster, causing Azure to automatically configure Trusted Access with cluster-admin privileges. From there, an attacker could extract secrets through backup operations or restore malicious workloads into the cluster.
O’Leary categorized 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.
Microsoft says no changes made, behavior says otherwise
BleepingComputer contacted Microsoft to determine whether the tech giant considered this finding to be a valid security vulnerability.
A Microsoft spokesperson told BleepingComputer:
“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.”
However, following the disclosure of his report this month, O’Leary noticed that the original attack path no longer functions.
“Current behavior returns errors that did not exist in March 2026,” he states:
ERROR: UserErrorTrustedAccessGatewayReturnedForbidden
“The Trusted Access role binding is missing/has gotten removed”
According to O’Leary, 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.
He also observed additional permission checks that were absent during his original testing in March. 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 other words, the vulnerability appears to have been fixed, but Microsoft has neither issued a public advisory nor notified customers.
The visibility problem for defenders
Without a CVE or advisory, defenders have limited 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,” the researcher writes.
“Without a CVE, security teams cannot track this exposure. Silent patching protects vendors, not customers.”
The case highlights a structural problem with no easy solution.
Disputes between security researchers and major vendors over severity, exploitability, and disclosure have become common in recent years, especially as vulnerability disclosure programs face increasing volumes of reports.
Some open-source maintainers have also publicly complained that AI-assisted reports are overwhelming bug bounty and security triage systems, making it harder for legitimate findings to receive timely attention. Cases where big tech ignored patching valid flaws despite repeated contact by different researchers are not uncommon either.
Without a framework that realigns incentives for all parties, responsible disclosure risks becoming a bureaucratic exercise that serves no one—least of all the organizations left exposed in the dark.
Automated pentesting tools deliver real value, but they were built to answer one question: can an attacker move through the network? They were not built to test whether your controls block threats, your detection rules fire, or your cloud configs hold.
This guide covers the 6 surfaces you actually need to validate.
Download Now
