Microsoft fixes Cosmos DB flaw after data access risk

Wiz Research has disclosed a vulnerability chain in Microsoft Azure Cosmos DB that it said could have enabled cross-tenant access to customer databases. Microsoft said it has fully remediated the issue and found no evidence of customer impact.

The flaw, named CosmosEscape by the researchers, could have allowed full read and write access to Azure Cosmos DB accounts, including private and network-isolated databases, according to Wiz.

Azure Cosmos DB is Microsoft's managed database service for cloud applications. The reported weakness drew attention because it raised the prospect of one customer gaining access to another's data in a multi-tenant environment. That is among the most sensitive risks in public cloud infrastructure, where provider controls are meant to keep tenants separate.

Microsoft said no customer action is required and that it found no evidence the vulnerability was exploited.

Shared risk

Security specialists said the reported chain stands out because it appeared to affect the underlying trust model of a shared cloud platform, rather than a single customer deployment or configuration error.

"A cross-tenant flaw in a shared cloud database is significant even after it is patched, because it breaks the core promise cloud infrastructure is built on: that customers on the same platform stay isolated from each other. Wiz assessed this one could have reached any customer's data across the Cosmos DB service, which sits under thousands of Microsoft customers and the data behind their applications, chatbots, and AI features. When one flaw can touch everyone's data at once, the blast radius is the whole platform. That is why this is news, not a footnote.

"The reason it is not a catastrophe is timing. A security firm found it before attackers did, and Microsoft says it is fully fixed with no evidence of exploitation. Serious potential, contained outcome.

"Microsoft fixed this on its side, and unlike some past Cosmos DB incidents, there is nothing for customers to install or rotate. But nothing to patch is not the same as nothing to learn.

"Cloud-side flaws like this typically receive no CVE and are fixed quietly, which means customers often cannot determine whether they were exposed. That is why researcher disclosure matters. It is also why assuming the next one gets caught before attackers do is not a security strategy.

"If you hold sensitive data in Cosmos DB, review your access logs and treat this as a prompt toward real defence in depth, private endpoints, least-privilege access controls, and application-layer encryption, rather than relying entirely on the provider's perimeter. The patch closes this door. It does not tell you what posture you should have had while it was open."

Waseem Ahmed, Head of Engineering at Secure.com, said providers can fix infrastructure flaws centrally, but customers often have limited visibility into whether they were exposed before the repair was made.

That issue has become more prominent as more companies place sensitive application data, identity records, and internal tools in managed cloud services they do not directly control. In such cases, customers remain responsible for data governance and access policies, even if they cannot patch the platform itself.

Control plane

Beau Bullock of Black Hills Information Security said the reported weakness went beyond a conventional software bug because it could have opened a route into the control mechanisms behind multiple tenants.

"The researchers here identified a critical vulnerability that would have allowed an attacker to access virtually any Microsoft Cosmos DB account belonging to Microsoft's customers, including Microsoft's own Cosmos databases used by services like Entra ID, Teams, and more. What the researchers found was essentially a 'master key' that could have been used to retrieve access keys across customers and tenants, providing full read and write access. The researchers also demonstrated how it was possible to query Cosmos DB's internal account directory to enumerate databases and precisely target organizations by tenant or subscription ID, making it much easier for an attacker to find and access data belonging to specific customers.

"This issue is related to something many people fear when they think about the shared nature of cloud services and just how segmented they actually are. This is not the first time a lack of boundaries between cloud provider customers has been demonstrated, and it likely will not be the last. Microsoft patched the issue and stated that it found no evidence of unauthorized exploitation, but the biggest takeaway is that organizations using cloud services cannot completely protect themselves from vulnerabilities in the underlying provider infrastructure that could allow cross-customer access."

Beau Bullock, Director of Emerging Threats and Advanced Testing at Black Hills Information Security, said organizations can reduce risk through monitoring and access controls, but they cannot remove their dependence on a provider's internal architecture and operational discipline.

Architecture questions

John Carberry of Xcape said the disclosure has drawn notice because the attack path was described as short and because the weakness was linked to the kind of boundary failure that can affect entire multi-tenant systems.

"While it is true that no action is required by customers, this story has gained attention because a short attack path led to a multi-tenant compromise. This is alarming because it means internal security boundaries were ineffective and the broader architecture is lacking.

"The issue is very serious because a relatively simple attack path led to the compromise of the control plane in that multi-tenant environment.

"This was a sandbox escape facilitated by AI. Such attacks will continue and are likely to become less novel over time as LLMs and AI evolve. It is an opportunity to recognize a case where transparency in disclosure can benefit the entire industry. Lessons learned can be applied to other cloud environments and distributed multi-tenant architectures. The severity of this issue has more to do with fundamental flaws in the architecture of this fabric. When security depends on an unscoped, god-mode key for all tenants, we can expect these attack chains to become common. This is cause for alarm.

"Customers have nothing to do in terms of incident response, but they should remain aware that even when data is stored in the cloud, they still have a responsibility to understand the risks involved in such hosting."

John Carberry, Solution Sleuth at Xcape, said the incident is likely to renew scrutiny of how cloud providers handle internal privilege boundaries, researcher disclosures, and customer transparency when vulnerabilities are found in shared services.

It also highlights the limits of the shared responsibility model when the weakness sits inside the provider's environment rather than in a customer's settings or code.

Microsoft's position remains that the issue has been fixed and that customers do not need to take action, while the broader debate now centres on how much assurance users can expect when critical security controls depend on systems they cannot inspect for themselves.