A security researcher says Microsoft quietly fixed the Azure Backup AKS vulnerability after rejecting his report, preventing the CVE from being released.
The researcher’s report describes a critical privilege escalation bug that allowed cluster administrator access from the “Backup Contributor” role.
Microsoft denies the claim, telling BleepingComputer the behavior was expected and that “no product changes were made,” despite the researcher writing new permission checks and failed exploit attempts after the disclosure, suggesting a silent patch.
CERT admits it’s a bug, but Microsoft blocks the CVE
Security researcher Justin O’Leary discovered the security flaw in March, and reported it to Microsoft on March 17.
The Microsoft Security Response Center (MSRC) denied the report on April 13, saying the problem only involved getting cluster-admin to a cluster where “an attacker already holds an administrator,” a character O’Leary says misrepresents the attack.
“This is really wrong,” said the researcher.
“The vulnerability allows a user with zero Kubernetes permissions to gain cluster-admin. The attack does not require existing cluster access – it does.”
O’Leary went on to say that Microsoft described submissions to MITER as “AI-generated content,” something he said did not address the merits of the report.
After being rejected, O’Leary referred the matter to the CERT Coordination Center, which independently verified the vulnerability on April 16 and, according to the researcher, assigned it an identifier, VU#284781:
.(Justin O’Leary)
CERT/CC originally planned a public disclosure on June 1, 2026, but that disclosure never happened.
On May 4, Microsoft employees reportedly contacted MITER to recommend against the CVE share, and argued the issue required pre-existing administrative access:
(Justin O’Leary)
CERT/CC later closed the case under CNA rules, effectively leaving Microsoft (which is CNA) the final authority on CVE releases for its products.
How the attack worked
Azure Backup for AKS uses Trusted Access to grant backup cluster-admin privileges within Kubernetes clusters.
According to O’Leary, the flaw allowed anyone with only the Backup Contributor role on the backup environment to initiate that Trusted Access relationship without having Kubernetes permissions.
An attacker can enable backup on a targeted AKS cluster, causing Azure to automatically configure Trusted Access with cluster-admin privileges. From there, an attacker can extract secrets by backing up or restoring malicious payloads to the collection.
O’Leary classified the issue as a Pin Confused vulnerability (CWE-441), where Azure RBAC and Kubernetes RBAC parameters interact in a way that overrides expected authorization controls.
Microsoft says no changes have been made, the behavior says otherwise
BleepingComputer reached out to Microsoft to understand if the tech giant considers these findings a valid security risk.
A Microsoft spokesperson told BleepingComputer:
“Our evaluation concluded that this is not a security vulnerability, but an expected behavior that requires administrative privileges already present within the customer’s environment. Therefore, no product changes have been made to address this report and no CVE or CVSS effect has been issued.”
However, after his report was released this month, O’Leary noted that the original attack method no longer worked.
“Current behavior returns errors that were not present in March 2026,” he says:
ERROR: UserErrorTrustedAccessGatewayReturnedForbidden
“The Trusted Access binding role does not exist/has been removed”
According to O’Leary, Azure Backup for AKS now requires Trusted Access to be manually configured before backup is enabled, reverting to previous behavior where Azure configured it automatically.
He also ran additional permit checks that were missing during his original inspection in March. Vault MSI now requires Reader permissions on both the AKS cluster and the 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 not issued a public advisory or notified customers.
Defender visibility problem
Without a CVE or advisory, defenders have little visibility into the exposure window or remediation timeline.
“Organizations that provided a Reserve Donor between an unknown start date and May 2026 were exposed to increased rights,” the researcher wrote.
“Without CVE, security teams can’t track these exposures. Silent patching protects vendors, not customers.”
The case highlights a structural problem that has no easy fix.
Disputes between security researchers and major vendors over the extent, exploitation, and disclosure have become common in recent years, especially as vulnerability disclosure programs face an increasing number of reports.
Some open source guardians have also publicly complained that AI-assisted reports are a huge boon for bugs and security testing programs, making it difficult for legitimate findings to receive timely attention. Cases where great technology ignores valid errors despite repeated communication by different researchers are also rare.
Without a framework that redirects compensation for all parties, responsible disclosure risks becoming a useless bureaucratic exercise—the least of which organizations are left in the dark.
Automated testing tools deliver real value, but they’re designed to answer one question: can an attacker deploy on a network? They are not designed to check that your controls are blocking threats, your firewall detection, or your cloud configs.
This guide covers the 6 areas you really need to verify.
Download Now
