A database query that was never supposed to reach this far
Security researchers at Wiz have disclosed a vulnerability chain in Microsoft Azure Cosmos DB, Microsoft's cloud database service, that they named CosmosEscape. In its worst form, the chain could have let an attacker who controlled nothing more than an ordinary Azure account read and write data in any Cosmos DB database on the platform, not just their own. Microsoft has already fixed it, and says it found no evidence anyone exploited it before the researchers, but the mechanics are worth understanding because of how far a single entry point reached.
The starting point was mundane by design: a standard Azure account, running a crafted query against a Cosmos DB database the attacker already owned. Cosmos DB supports Gremlin, a graph query language, and Microsoft built a custom .NET-based engine to run those queries inside a sandbox, so that a query touching one customer's data could never reach anyone else's. Wiz's researchers found a way to use .NET's own reflection capabilities, a language feature that lets code inspect and manipulate other code at runtime, to step outside that sandbox from within a query the attacker was fully entitled to run.
From a sandbox escape to a master key
Escaping the query sandbox alone would have been a serious bug. What made CosmosEscape unusually severe is where the escape landed: arbitrary code execution on Cosmos DB's "DB Gateway," a service shared across many customers rather than dedicated to any one of them. From there, the researchers found they could reach a signing secret they dubbed the "Cosmos Master Key," a single credential capable of retrieving the primary access key for any Cosmos DB account, in any region, on any of the service's application programming interfaces (APIs, the interfaces different applications use to talk to a service).
A second internal system, the "Config Store," compounded the exposure. It functions as Cosmos DB's account registry, and reaching it gave the researchers account names, subscription identifiers, tenant identifiers, and configuration details for every account in a region, enough to identify and target specific organizations rather than attack blindly. Because the flaw sat inside Cosmos DB's own infrastructure rather than in a customer's configuration, it did not matter whether a given database was private or network-isolated: those protections lived at a layer the bug had already bypassed. Wiz notes that write access to the Config Store could reportedly have gone further still, letting an attacker overwrite an account's network isolation settings directly.
The exposure was not limited to Microsoft's customers. Wiz found that Microsoft's own internal services, including systems that support Entra ID (Microsoft's identity platform), Teams, and Copilot, run on Cosmos DB and would have fallen within the same blast radius.
Fixed months before anyone outside Microsoft knew
Wiz reported CosmosEscape to Microsoft on 20 November 2025. Microsoft's first response was fast: a hotfix blocking the vulnerable Gremlin entry point was live within roughly 48 hours, by 22 November. That bought time for a deeper fix. Microsoft says it completed a full architectural change that eliminates the master key model entirely, and rolled it out across all Azure regions in July 2026, ahead of Wiz's public disclosure on 30 July. No CVE (Common Vulnerabilities and Exposures) identifier or CVSS (Common Vulnerability Scoring System) score has been assigned to CosmosEscape, which is unusual for a flaw of this severity and likely reflects that it was fixed at the infrastructure level before any customer-facing patch was needed. Microsoft says it reviewed its access logs and found no evidence of unauthorized use beyond the researchers' own testing, and states that no action is required from customers.
What it means in practice
For any organization running production data on Azure Cosmos DB, including the fintech and enterprise SaaS shops that use it as a backing store in Sri Lanka and elsewhere, there is genuinely nothing to patch here: the fix was architectural and applied by Microsoft across the whole service before disclosure. The more durable lesson is about how multi-tenant cloud services fail. The isolation customers pay for is enforced by the provider's internal code, not by anything a customer configures, and a single flaw in a shared component, in this case a query sandbox, can undo isolation guarantees for every tenant at once regardless of how carefully any individual customer has locked down their own account. Teams evaluating or renewing cloud database contracts have reason to ask vendors directly how sandboxing and tenant isolation are implemented and tested, and to treat a vendor's silence on that question as itself informative. It is also a reminder to read vendor security disclosures even when they say "no action required": knowing what kind of failure was possible, and for how long, is useful context the next time an incident report lands with less reassuring news attached.
