The CVE That Wasn't: Microsoft's Azure Vulnerability Rejection And The Eroding Trust In Cloud Disclosure Susiloharjo

TL;DR:

A security researcher discovered a critical cross-tenant access flaw in Microsoft Azure’s identity management layer, capable of exposing sensitive customer data across organizational boundaries — and provided full technical documentation with proof-of-concept code.
Microsoft’s Security Response Center (MSRC) rejected the submission as “by design,” classifying the vulnerable behavior as intended functionality rather than a security defect — and declined to issue a CVE identifier.
The rejection is inconsistent with Microsoft’s own historical precedent, as substantially similar cross-tenant vulnerabilities in Azure have received CVE assignments and security patches in the past.
This pattern — classify as “by design,” silently patch later — erodes the coordinated vulnerability disclosure ecosystem and leaves Azure customers unaware of active risks that attackers may already be exploiting.

—

The Submission: What the Researcher Found

The vulnerability resided in Azure’s cross-tenant access architecture — the mechanisms governing how identities, resources, and permissions interact across organizational boundaries. Under specific conditions, an attacker could traverse tenant isolation to access resources belonging to other Azure customers. The attack path did not require exploiting a victim-side misconfiguration; it leveraged behavior in Azure’s own IAM plumbing.

The submission followed responsible disclosure best practices: detailed technical write-up, step-by-step reproduction, working PoC code, and clear security impact analysis. The flaw permitted authenticated sessions in Tenant A to reach objects in Tenant B through a gap in the authorization enforcement layer — a failure of the fundamental isolation primitive the shared-responsibility model depends on.

Cross-tenant authorization bypasses are among the highest-severity cloud infrastructure issues because they undermine the core premise of multi-tenancy. When that guarantee fails without audit log anomalies or alerts, the attack surface becomes invisible to defenders.

“By Design”: The Anatomy of a Rejection

Microsoft’s formal response classified the reported behavior as intended design. The MSRC case was closed without a fix, CVE, or public advisory. The rationale positioned the cross-tenant interaction as a feature of Azure’s resource access model rather than a defect in its security boundaries.

This framing is increasingly contentious. Cloud providers have an interest in drawing the line between “vulnerability” and “documented behavior” as close to the provider’s side as possible — every bug reclassified as a design choice is one fewer patch cycle and one less mark on the security track record. But the classification carries real consequences. A CVE provides a globally recognized identifier that security teams use to track, assess, and remediate risks. Without one, the finding enters information limbo: the researcher can publish, but without a vendor-acknowledged identifier, the finding struggles to propagate through SIEM rules, scanner signatures, and threat intelligence feeds.

The “by design” label also introduces a perverse incentive. If a researcher spends weeks reverse-engineering an authorization bypass and the vendor dismisses it with a three-word verdict, the economic calculus of vulnerability research shifts. Less disclosure, less scrutiny, and ultimately less security for the customers who depend on these platforms.

Precedent Contradictions: When Similar Bugs Got CVEs

The rejection is harder to reconcile against Microsoft’s CVE history. Azure has issued CVEs for cross-tenant vulnerabilities in the past — including in Azure AD, shared key authentication flows, and resource management APIs where the core mechanism was an authorization gap between tenants. The architectural similarity between acknowledged vulnerabilities and the current finding raises an uncomfortable question: what changed?

One possibility is that earlier CVEs involved clearer code-level defects — a missing authorization check in an API endpoint, an improperly scoped token — while the current finding operates at a higher layer where “working as designed” versus “insecure by design” becomes a matter of interpretation. But from the customer’s perspective, the distinction is academic. If Tenant A can read Tenant B’s storage, the taxonomy matters less than the fact of exposure.

Another possibility is organizational: as Azure’s attack surface has grown, the threshold for what MSRC considers reportable may have shifted. Triage teams under pressure develop heuristics — and “cross-tenant = shared responsibility” may have calcified into one of them, regardless of technical specifics.

The Shared Responsibility Shell Game

The shared responsibility model — provider secures the infrastructure, customer secures what runs on it — was designed to allocate operational security duties, not to dismiss provider-side architectural weaknesses.

When a vulnerability exists in the platform layer — the IAM fabric, the resource management plane, tenant isolation — shared responsibility does not apply. The customer did not configure a weak boundary; the boundary itself was not enforced. Rebranding a tenant isolation failure as a shared-responsibility issue conflates two fundamentally different categories of risk and creates a dangerous asymmetry: the provider controls the code and the disclosure process, while the customer bears the operational risk without the information needed to assess it.

The security community’s pushback is not philosophical. If every cross-tenant bug eventually routes to “by design” status, the CVE system loses its value as a signaling mechanism for the vulnerabilities that matter most to cloud consumers.

The Silent Fix Pattern

This is not the first time Microsoft has rejected a submission only to address the issue later without credit, CVE, or advisory. Multiple documented instances exist where an MSRC “won’t fix” was followed by a quiet code change in a subsequent Azure update — functionally a patch without the transparency infrastructure that makes patches actionable.

The pattern is corrosive in three ways. First, it denies the researcher credit, undermining the recognition economy that motivates independent vulnerability research. Second, it denies customers a CVE to anchor internal risk assessments and remediation workflows. Third, it denies the security community data points for understanding the threat landscape.

For engineering teams operating Azure workloads, a silent fix is functionally indistinguishable from an unpatched vulnerability until someone reverse-engineers the update. Without a CVE or advisory, there is no way to distinguish “the platform is now secure” from “the platform remains vulnerable but the researcher stopped pushing.”

—

Engineering Takeaways

The architectural lesson is not about a single bug; it is about a systemic gap in how cloud vulnerability disclosure handles authorization-boundary issues.

First, cross-tenant isolation should be treated as an untrusted boundary even when provider documentation asserts otherwise. Defense-in-depth means verifying isolation through penetration tests that explicitly target tenant-boundary traversal, not just application-layer vulnerabilities within a single tenant.

Second, vulnerability management programs that depend on CVE feeds as their primary signal should supplement them with direct monitoring of researcher disclosures, conference talks, and independent assessments. If a vendor can kill a submission with a “by design” label, the CVE feed alone is incomplete.

Third, the shared responsibility model requires sharper definition. Provider-side architectural flaws in tenant isolation are not the customer’s responsibility to detect or mitigate — and the industry needs clearer norms around when “by design” is a valid technical assessment and when it is a deflection.

The outcome of this specific case is not final. MSRC decisions can be revisited, and public scrutiny has reversed dismissals before. But the pattern demands attention: a disclosure ecosystem where critical findings disappear into a classification gap is an ecosystem drifting toward opacity. For the engineers who build on these platforms and the customers who trust them, opacity is not an acceptable security posture.

🔗 Related Articles

Discover more from Susiloharjo

Subscribe to get the latest posts sent to your email.