What Happened
On April 13, Microsoft rejected a security researcher's vulnerability report for Azure Backup for AKS (Azure Kubernetes Service). The researcher, Justin O'Leary, identified a privilege escalation path allowing attackers to gain elevated permissions within the Azure environment. Microsoft claimed the behavior required pre-existing admin access and was not a vulnerability.
However, the CERT Coordination Center disagreed. They validated O'Leary's findings and assigned tracking identifier VU#284781, recognizing it as a legitimate security concern.
Then, unexpectedly, O'Leary found that the original attack path no longer worked. Microsoft appears to have modified the behavior without acknowledging a vulnerability, issuing a CVE, or notifying customers that their Azure environments had been at risk.
Timeline
Pre-April 13: O'Leary discovers privilege escalation path in Azure Backup for AKS.
April 13: Microsoft rejects the vulnerability report, claiming the behavior requires admin access and is expected.
Post-April 13: CERT Coordination Center validates the vulnerability and assigns VU#284781.
Subsequent weeks: O'Leary confirms the original attack path no longer functions.
Current state: No CVE issued, no public acknowledgment from Microsoft, no customer notification.
Which Controls Failed or Were Missing
The failure here is procedural, not technical. Three controls broke down:
Vulnerability disclosure program governance: Microsoft's security response team dismissed a valid finding without adequate review. When an independent party like CERT/CC validates a claim, your internal decision should be reconsidered. Dismissing an issue because it requires admin access misses the point: privilege escalation is critical, especially in cloud environments where role separation is vital.
Change management and security notification: If Microsoft modified Azure Backup's behavior, that change should have triggered customer notification. Your cloud provider's infrastructure changes can affect your threat model. You need to know when attack surfaces shift.
CVE assignment process: The CVE system helps security teams track vulnerabilities. When a vendor fixes an issue but doesn't assign a CVE, you lose visibility into whether your environment was exposed and when the risk was mitigated.
What the Standards Require
ISO/IEC 27001:2022 Annex A.5.23 requires organizations to understand their cloud provider's security practices, including how vulnerabilities are disclosed and remediated. Silent patching violates the transparency needed to meet this requirement.
NIST 800-53 Rev 5 SI-2 mandates that organizations identify, report, and correct system flaws. When your cloud provider is part of your system boundary, their refusal to document a flaw creates a compliance gap.
SOC 2 Type II CC7.3 requires organizations to identify and respond to risks associated with vendors. If your Azure environment is in scope for SOC 2, your auditor will ask how you track and respond to cloud provider vulnerabilities.
PCI DSS v4.0.1 Requirement 6.3.3 requires organizations to address common coding vulnerabilities during development. This principle applies to privilege escalation paths, regardless of the attacker's starting privileges.
Lessons and Action Items for Your Team
Build a cloud provider vulnerability tracking process: Don't rely solely on CVEs. Monitor CERT/CC advisories, cloud provider security bulletins, and researcher disclosures. Create a spreadsheet mapping cloud services you use to their security notification channels.
Document your threat model assumptions: Write down which Azure (or AWS, or GCP) behaviors your security controls depend on. When providers make undocumented changes, you need a reference point to assess impact.
Establish a vendor disclosure policy: Add language to your cloud provider contracts requiring notification of security-relevant changes. Enforce these terms when a provider makes an undocumented change that affects your security posture.
Treat "expected behavior" dismissals skeptically: When a vendor claims a security issue is "working as designed," ask if this design meets security principles. Challenge dismissals with your own threat model.
Implement defense in depth for cloud IAM: Don't assume Azure will prevent all privilege escalation paths. Use Azure Policy to restrict service principal access, enable Privileged Identity Management, and monitor Azure Activity Logs for unusual changes.
Create a "silent patch" response playbook: When you suspect a provider has fixed an undisclosed vulnerability, document the behavior change, assess your exposure window, and determine if you need to notify your customers or auditors.
The Microsoft-O'Leary dispute highlights a structural problem: when vendors control the CVE assignment process for their products, they can make security issues disappear from the public record. Your job is to make them visible again—in your risk register, your vendor reviews, and your audit evidence. The vulnerability may not have a CVE, but it still happened, and you need to account for it.
