A security researcher claims Microsoft quietly fixed an Azure Backup for AKS vulnerability after rejecting his report, and blocking a CVE from being issued.
The researcher’s report describes a critical privilege escalation flaw that allowed cluster-admin access from the low-privileged “Backup Contributor” role.
Microsoft disputes the claim, telling BleepingComputer the behavior was expected and that “no product changes were made,” despite the researcher documenting new permission checks and failed exploit attempts after disclosure, suggestive of a silent patch.
CERT agrees it’s a bug, but Microsoft blocks CVE
Security researcher Justin O’Leary discovered the security flaw this March, and reported it to Microsoft on March 17.
Microsoft Security Response Center (MSRC) rejected the report on April 13, claiming the issue only involved obtaining cluster-admin on a cluster where “the attacker already held administrator access,” a characterization O’Leary says misrepresents the attack entirely.
“This is factually incorrect,” states the researcher.
“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 says that Microsoft described the submission to MITRE as “AI-generated content,” something he says did not address the technical merits of the report.
After the rejection, O’Leary escalated the issue to CERT Coordination Center, which independently validated the vulnerability on April 16 and, according to the researcher, assigned it an identifier, VU#284781:
(Justin O’Leary)
CERT/CC had initially scheduled public disclosure for June 1, 2026, but that disclosure never happened.
On May 4, Microsoft staff reportedly contacted MITRE recommending 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 allowed anyone with only the Backup Contributor role on a backup vault to trigger that Trusted Access relationship without already having 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 classified the issue as a Confused Deputy vulnerability (CWE-441), where Azure RBAC and Kubernetes RBAC trust boundaries interacted in a manner that bypassed expected authorization controls.
Microsoft says no changes made, behavior says otherwise
BleepingComputer reached out to Microsoft to understand if 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 observed that the original attack path no longer works.
“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 little 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,” writes the researcher.
“Without a CVE, security teams cannot track this exposure. Silent patching protects vendors, not customers.”
The case highlights a structural problem with no easy fix.
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.
