A vulnerability chain in Microsoft Azure Cosmos DB could have allowed an attacker to read or modify customer databases across the service, according to research published by Wiz.
Dubbed CosmosEscape, the chain began with a sandbox escape in the Cosmos DB Gremlin query engine and led to code execution on shared backend infrastructure, opening a path to credentials trusted across the service.
Microsoft blocked the initial attack vector within 48 hours of receiving Wiz’s report in November 2025 and completed a longer-term architectural fix across all Azure regions in July 2026. According to a statement included in Wiz’s report, Microsoft’s investigation uncovered no activity beyond the researchers’ authorized testing and no evidence that customer data had been accessed. The company said customers do not need to take any action.
How the CosmosEscape Chain Worked
CosmosEscape began when Wiz researchers received an unexpected .NET exception while running Gremlin graph queries against their own Cosmos DB account.
Most open-source Gremlin systems run on the Java Virtual Machine, so the error suggested that Microsoft had built a custom .NET query engine. Gremlin servers often translate queries into executable code and run it inside a restricted environment, making the sandbox a critical security boundary.
Wiz found that Cosmos DB converted submitted Gremlin queries into .NET code. The researchers said restrictions intended to limit that code did not sufficiently account for .NET reflection, a capability that can expose information about classes, methods, and other program elements while software is running.
They used that weakness to read and write files and eventually execute arbitrary commands through a specially crafted query.
The commands ran on the DB Gateway, a backend service that processes customer queries and connects them to Cosmos DB accounts. Because the gateway operated on multitenant Service Fabric clusters, escaping the sandbox gave the researchers a foothold inside shared Azure infrastructure rather than access only to their own database.
Why the Potential Blast Radius Was So Large
Using credentials available on the compromised cluster, the Wiz researchers accessed a platform-wide signing key capable of retrieving a Cosmos DB account’s primary key. A primary key provides full read-and-write access to the databases within that account.
Wiz found that the signing key worked across tenants and regions and affected accounts using the SQL, MongoDB, Cassandra, and Gremlin APIs. The researchers dubbed it the Cosmos Master Key because it could retrieve the primary key for any Cosmos DB account on the service.
That reach turned a query-engine vulnerability into a failure of tenant isolation: Code submitted through one customer-controlled environment opened a path to credentials trusted across the platform.
The signing key also gave the researchers access to what Wiz called the Config Store, a regional directory containing account names, tenant and subscription IDs, network settings, and other details.
Because the Config Store was itself a Cosmos DB database, the researchers could use it to list accounts within a region or search for accounts associated with a particular organization. An attacker could potentially identify a target, then retrieve the primary key needed to access its databases.
According to Wiz, the vulnerability also affected private and network-isolated accounts. Because the compromised DB Gateway enforced those restrictions, gaining control of it placed the researchers inside the account-level network boundary.
Wiz said the Config Store could also be modified, suggesting that an attacker might have been able to alter network-isolation settings. Wiz’s demonstrated takeover chain did not rely on changing those settings.
The potential reach extended beyond organizations that use Cosmos DB directly. Wiz said the service supports Microsoft products including Teams, Entra ID, and Copilot, potentially placing databases used by those services within reach.
Microsoft’s Response and the Limits of Customer Control
Beyond blocking the Gremlin API attack vector, Microsoft said it strengthened service-to-service authentication, added network protections, and expanded monitoring and detection capabilities.
Cosmos DB customers could not patch the underlying flaw themselves. The affected query engine, DB Gateway, and platform credentials were all part of Microsoft-managed infrastructure.
Because the vulnerable systems were managed by Microsoft, customers had to rely largely on the company’s review of its platform logs to determine whether the flaw had been exploited and confirm that it had been remediated.
“The right question for CISOs isn’t ‘are we patched,’ it’s ‘how much of our risk model rests on someone else’s homework,’” said Trey Ford, chief strategy and trust officer at Bugcrowd.
Ford’s comment highlights a broader challenge with managed cloud services: Customers gain infrastructure they do not have to maintain but may have limited visibility into provider-side security failures and the evidence used to assess them.
What IT and Security Teams Should Take Away
“While Microsoft fixed the underlying vulnerability on the platform side—meaning customers do not need to install a patch—security teams should not treat this as a ‘zero-action’ event,” said John Gallagher, vice president at Viakoo.
The disclosure gives IT and security teams an opportunity to identify which applications, data stores, and business processes depend on Cosmos DB or other provider-managed services. Mapping those dependencies can help organizations assess the consequences of a vulnerability in shared infrastructure.
Teams can also review protections that would remain useful during a provider-side incident, including independently maintained backups, logs stored outside the affected service, and response plans that account for limited access to the provider’s systems and forensic evidence.
Organizations evaluating cloud vendors can ask how broadly backend credentials are scoped, what prevents tenant-controlled activity from reaching shared systems, how privileged services are monitored, and what evidence customers receive after a provider-side incident.
Such measures would not have prevented CosmosEscape. They can, however, help organizations understand their exposure and prepare for incidents in which investigation and remediation depend heavily on the service provider.
