Microsoft Rejects Azure Vulnerability, Blocks CVE Assignment

Key Takeaways

• A researcher discovered a privilege escalation flaw in Azure Backup for AKS that granted cluster-admin access from a low-privilege role
• CERT validated the vulnerability, but Microsoft blocked CVE assignment and denied making any product changes
• The researcher documented new permission checks after disclosure, suggesting Microsoft silently patched the issue

Security researcher Justin O'Leary discovered what he describes as a critical privilege escalation vulnerability in Azure Backup for AKS. Microsoft rejected his report, called his submission "AI-generated content," and successfully blocked a CVE from being issued.

The catch? CERT Coordination Center independently validated the bug. And O'Leary says the vulnerability stopped working after he reported it, suggesting Microsoft quietly fixed the issue while publicly denying it existed.

What the Vulnerability Did

Azure Backup for AKS uses a feature called Trusted Access to grant backup extensions cluster-admin privileges inside Kubernetes clusters. According to O'Leary, anyone with only the "Backup Contributor" role on a backup vault could exploit this relationship without already having Kubernetes permissions.

The attack path worked like this: an attacker enables backup on a target AKS cluster. Azure then automatically configures Trusted Access with cluster-admin privileges. From there, the attacker could extract secrets through backup operations or restore malicious workloads into the cluster.

"The vulnerability allows a user with zero Kubernetes permissions to gain cluster-admin," O'Leary stated. "The attack does not require existing cluster access. It grants it."

Microsoft's Response

O'Leary reported the flaw to Microsoft Security Response Center on March 17, 2026. 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."

O'Leary says this characterization completely misrepresents the attack. The whole point of the vulnerability was that it granted admin access to users who didn't have it.

Microsoft also described the submission to MITRE as "AI-generated content." O'Leary says this didn't address the technical merits of his report.

“This is factually incorrect. The vulnerability allows a user with zero Kubernetes permissions to gain cluster-admin. The attack does not require existing cluster access — it grants it.”

— Justin O'Leary, security researcher

CERT Validates the Bug

After MSRC's rejection, O'Leary escalated to CERT Coordination Center. CERT independently validated the vulnerability on April 16 and assigned it tracking identifier VU#284781.

CERT initially scheduled public disclosure for June 1, 2026. That disclosure never happened.

On May 4, Microsoft staff contacted MITRE and recommended against CVE assignment. Microsoft again argued the issue required pre-existing administrative access.

CERT/CC later closed the case under CNA hierarchy rules. Because Microsoft is a CVE Numbering Authority, it has final authority over CVE issuance for its own products.

The Silent Patch Question

Microsoft told BleepingComputer the behavior was expected and that "no product changes were made." O'Leary disputes this.

He documented new permission checks appearing after his disclosure. His exploit attempts that previously succeeded now failed. This pattern, he says, suggests Microsoft silently patched the issue while publicly denying it was a vulnerability.

Silent patches create a problem for defenders. Without a CVE or public acknowledgment, security teams have no way to verify they're protected. They can't prioritize the fix in their patch management processes. They don't know the vulnerability existed.

The CNA Conflict of Interest

This case highlights a structural issue in vulnerability disclosure. Major vendors like Microsoft act as their own CVE Numbering Authorities. When a researcher and a vendor disagree about whether something is a vulnerability, the vendor often has final say over whether a CVE gets issued.

CERT validated O'Leary's findings. But under CNA hierarchy rules, Microsoft's rejection ended the process. The vulnerability gets no official tracking number, no formal documentation, and no entry in vulnerability databases that security tools rely on.

What This Means for Azure Users

If you use Azure Backup for AKS, you likely can't verify whether you were affected. Microsoft hasn't published details about the issue or any fix. O'Leary's evidence suggests the vulnerability is patched, but without official confirmation, that's an assumption.

• Review who has Backup Contributor role access to your backup vaults
• Audit Trusted Access relationships on your AKS clusters
• Monitor backup operations for unexpected activity
• Consider implementing additional RBAC restrictions around backup permissions

Frequently Asked Questions

What is the Azure Backup for AKS vulnerability?

A privilege escalation flaw that allegedly allowed users with only the Backup Contributor role to gain cluster-admin access in Kubernetes clusters, without having any prior Kubernetes permissions.

Why was no CVE issued for this vulnerability?

Microsoft, acting as a CVE Numbering Authority for its own products, blocked the CVE assignment. Microsoft claims the behavior was expected and did not constitute a vulnerability.

Did Microsoft patch the vulnerability?

Microsoft says no product changes were made. The researcher documented new permission checks and failed exploit attempts after disclosure, suggesting a silent patch occurred.

What is a CVE Numbering Authority?

A CNA is an organization authorized to assign CVE identification numbers to vulnerabilities. Microsoft is a CNA for its own products, giving it authority over CVE issuance for Azure and other Microsoft services.

How can Azure users protect themselves?

Review Backup Contributor role assignments, audit Trusted Access relationships on AKS clusters, and monitor backup operations for unusual activity.

Source: BleepingComputer