"This is factually incorrect," states the researcher.
Justin O'Leary's discovery and the contested report
Security researcher Justin O'Leary says he discovered a critical privilege-escalation flaw in Azure Backup for AKS in March 2026 and reported it to Microsoft on March 17. According to O'Leary, the flaw allowed a principal with the low-privileged Backup Contributor role on a backup vault to obtain cluster-admin privileges inside a Kubernetes cluster — in his characterization, a case where "a user with zero Kubernetes permissions" could gain full cluster administration.
Microsoft's Security Response Center (MSRC) rejected O'Leary's submission on April 13, telling BleepingComputer the behavior was "expected" and that the issue "requires pre-existing administrative privileges within the customer's environment." O'Leary disputes that framing and says Microsoft additionally described his submission to MITRE as "AI-generated content," which he says failed to address the technical merits of the report.
How the reported attack path worked
O'Leary detailed a confused-deputy style attack (CWE-441) that exploited an interaction between Azure RBAC and Kubernetes RBAC. Azure Backup for AKS uses a Trusted Access relationship to grant backup extensions cluster-admin privileges inside clusters. O'Leary's account asserts that anyone holding only Backup Contributor on a backup vault could enable backup on a target AKS cluster and thereby trigger Azure to automatically establish Trusted Access with cluster-admin privileges.
Once Trusted Access was established, the attacker could — according to O'Leary's report — extract secrets via backup operations or restore malicious workloads into the cluster. In his assessment, the vulnerability did not require prior Kubernetes access; it granted administrative access as part of the backup enablement flow.
CERT/CC validation, CVE routing, and CNA authority
After MSRC's rejection, O'Leary escalated the finding to the CERT Coordination Center (CERT/CC). CERT/CC independently validated the vulnerability on April 16 and assigned it an identifier, VU#284781. CERT/CC scheduled a public disclosure for June 1, 2026, but that disclosure never occurred.
On May 4, Microsoft staff reportedly contacted MITRE recommending against CVE assignment, reiterating the position that the issue required pre-existing administrative access. CERT/CC later closed the case under CNA hierarchy rules, which left Microsoft — identified in the report as a CNA — with final authority over whether a CVE would be issued for its own products.
Microsoft's public stance and changes observed after disclosure
When BleepingComputer asked whether Microsoft considered the finding a security vulnerability, 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."
Yet O'Leary reports a different reality in the field. After his disclosure, he says the original attack path no longer works and that "current behavior returns errors that did not exist in March 2026." He documents that Azure Backup for AKS now requires Trusted Access to be manually configured before backup can be enabled — reversing the earlier, allegedly automatic configuration. He also observed added permission checks: the 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.
Those changes, as described by O'Leary, indicate remediation actions occurred despite Microsoft's public statement that "no product changes were made."
What this means for security teams, enterprises, and customers
- Technologists and security teams: Without a CVE or advisory, defenders lack a standardized tracking identifier and clear disclosure timeline. O'Leary warns organizations that granted Backup Contributor "between an unknown start date and May 2026 were exposed to privilege escalation."
- Affected enterprises and procurement leaders: Silent or undocumented changes create blind spots. According to the researcher, "Silent patching protects vendors, not customers," because remediation without advisory notice denies organizations the ability to measure exposure windows or audit past configurations.
- CERTs and vulnerability coordination bodies: The case illustrates how CNA hierarchy and dispute over exploitability can leave final decisions about public disclosure and CVE assignment in the hands of the vendor, even after independent validation by CERT/CC.
The incident lays bare a procedural friction point: a researcher says a privilege-escalation path existed and was validated by CERT/CC; the vendor says the behavior was expected and that no product changes were made; and post-disclosure behavior in customers' environments appears different from the state the researcher observed in March. For defenders, the practical result is the same — uncertainty about when and how exposure occurred, and limited ability to quantify affected inventories.
For the record and for action, the original BleepingComputer story is here: https://www.bleepingcomputer.com/news/security/microsoft-rejects-critical-azure-vulnerability-report-no-cve-issued/
