A critical security flaw in Azure Cosmos DB could have enabled attackers to compromise databases at platform scale, according to cybersecurity firm Wiz. The key detail: a weakness that allowed a Cosmos Master Key to be obtained, which in turn could reveal primary keys across the service.
Wiz calls the issue CosmosEscape. The researchers describe how the flaw could be chained together to move from publicly reachable endpoints to full read and write access to targeted databases—potentially including data used by Microsoft services.
What the CosmosEscape vulnerability could do
At the heart of the report is the possibility of obtaining a platform-wide key for Cosmos DB. With this Cosmos Master Key, an attacker could retrieve the primary key of any Cosmos DB account hosted on the service.
Once an attacker had a specific primary key, the next step became straightforward: full access to that account’s data. Wiz further explains that the attacker could enumerate databases and refine the results by using organization identifiers, such as subscription and tenant IDs.
In practical terms, Wiz says the chained capabilities could enable “precision targeting at platform scale”—starting from identifying a particular organization’s databases and moving toward compromising them.
Why Microsoft services were potentially exposed
Wiz notes that Microsoft uses Cosmos DB to store data across multiple products and platforms, including Entra ID, Teams, and Copilot. Because the vulnerable database service underpins those systems, unauthorized access could have reached beyond a single application.
That impact hinges on the attacker’s ability to reach the right Cosmos DB accounts via the same service endpoints. Wiz emphasizes that the risky path relied on capabilities accessible through publicly reachable interfaces.
How the attack could start: Gremlin and query execution
The researchers describe an exploitation route involving the Gremlin API, a graph query interface that relies on a custom Gremlin engine. In this setup, Gremlin queries get compiled into .NET code, which is then executed within a sandbox.
The sandbox was intended to enforce restrictions so execution would remain within allowed Gremlin operations. However, Wiz reports that the sandbox did not properly account for .NET reflection, which the researchers used to create primitives that could lead to arbitrary code execution.
Bypassing the sandbox to reach the DB Gateway
Wiz explains that after bypassing the Gremlin sandbox, they gained code execution on the DB Gateway—a service that executes customer queries on their behalf. This gateway runs on multi-tenant Service Fabric clusters, meaning it serves requests for multiple customers and regions.
That detail matters, because a compromise at the gateway layer can potentially affect more than one tenant if keys or logic are reused across boundaries.
The Cosmos Master Key and why it is so dangerous
Wiz discovered that the DB Gateway uses a signing key. In the researchers’ testing, this signing key could be used to retrieve customer accounts’ primary keys.
Crucially, Wiz reports the signing key worked broadly: across tenants, regions, and even across APIs. As a result, the researchers describe a platform-wide secret that could retrieve the primary key for any Cosmos DB account accessible through publicly accessible endpoints.
This platform-wide key is what Wiz calls the Cosmos Master Key.
From the master key to an account inventory
Obtaining the Cosmos Master Key was only part of the story. Wiz also describes access to a configuration store containing information about Cosmos DB accounts.
In the researchers’ findings, the configuration store itself is implemented as a Cosmos DB database. Because of that, it could be queried using the full flexibility of Cosmos DB’s SQL engine. Additionally, since the configuration store was also tied into the keying mechanism, the Cosmos Master Key could retrieve its own primary key as well.
Querying configuration data with the SQL engine
Wiz explains what an attacker could potentially learn from that configuration store. The configuration data includes details such as account names, subscription IDs, tenant IDs, and other configuration-related attributes.
With both the master key and the ability to query this store, an attacker could enumerate Cosmos DB accounts, filter them by organization identifiers, and then obtain the primary key of a chosen target.
Once the target primary key was obtained, Wiz says the attacker could gain full read and write access across the victim’s databases.
Could the attack work against private or isolated accounts?
Wiz also indicates that the attack path was not limited to a single exposure model. According to the report, the scenario could be mounted against private and network-isolated Cosmos DB accounts.
Wiz further states the technique could potentially be used against Microsoft’s own Cosmos DB databases as well. That expands the threat model from third-party tenants to first-party systems that run on the same underlying service.
Patch timeline: hotfix first, then a long-term fix
Wiz reported the vulnerability to Microsoft in November 2025. Within two days, Microsoft deployed a hotfix designed to block the attack vector.
Later, in July, Microsoft completed the rollout of a long-term architectural fix across all regions.
In its response, Microsoft conducted extensive reviews of access logs and reported no evidence of unauthorized activity outside Wiz’s testing activity. Wiz also says there was no customer data accessed during the researcher’s evaluation.
Microsoft’s position was that no customer action was required.
What this case highlights for database platform security
This report underscores how quickly risks can escalate when multiple layers—API behavior, sandboxing assumptions, runtime capabilities, and key management—interact in unexpected ways.
The Cosmos Master Key concept matters because platform-wide secrets create high-impact blast radius. Even if an attacker only gains a foothold in one component, reuse of keys and cross-tenant effectiveness can transform a limited flaw into a broader compromise.
For defenders, the takeaway is clear: sandbox boundaries must consider all runtime features that can be leveraged to escape intended limitations, and key-handling mechanisms should minimize cross-tenant or cross-region effectiveness wherever possible.
Conclusion
Wiz’s analysis of CosmosEscape describes a critical flaw in Azure Cosmos DB that could have enabled attackers to obtain the Cosmos Master Key, retrieve primary keys for Cosmos DB accounts, and then list and access databases with full read/write capabilities. The chain involved Gremlin query processing, sandbox bypass via .NET reflection, and code execution on the DB Gateway.
Microsoft responded quickly with a hotfix and later shipped a long-term architectural fix across regions, reporting no unauthorized activity beyond the researchers’ testing. Still, the case remains a stark reminder of how platform-wide secrets can turn a single vulnerability into large-scale exposure.
Source: https://www.securityweek.com/critical-flaw-led-to-azure-cosmos-db-pwnage/
