Wiz Research disclosed Wednesday that a chain of vulnerabilities in Azure Cosmos DB’s Gremlin query engine — which the firm named CosmosEscape — allowed any attacker with a standard Cosmos DB account to break out of the service’s query sandbox and retrieve a single platform-wide signing key capable of reading or overwriting data in every customer database on the service. That key — which Wiz called the Cosmos Master Key — was not scoped to a tenant, a region, or an API type. It covered all of them. Microsoft has fully patched the vulnerability and told The Hacker News no customer data was accessed outside the researchers’ own testing. What Microsoft has not said is when the vulnerable architecture first entered production — and that gap in the public record is the one piece of information enterprises running critical workloads on Cosmos DB cannot yet resolve on their own.
What CosmosEscape Did and What It Could Have Reached
Azure Cosmos DB is Microsoft’s flagship managed NoSQL database service, used by enterprise customers globally and by Microsoft’s own internal infrastructure. Teams message data remains in Cosmos DB, according to Microsoft Purview documentation. Microsoft Copilot stores users’ queries and conversation histories there. Microsoft Entra ID runs on Cosmos DB at scale. Wiz confirmed that the databases backing all three products were within reach via CosmosEscape, though the researchers did not access them.
The scope also included every network-isolated and private-endpoint Cosmos DB account on the service. Per-account network isolation in Cosmos DB is enforced by the same DB Gateway layer that CosmosEscape compromised — meaning the isolation boundary was bypassed from the inside.
From a Single Query to a Platform-Wide Key
Cosmos DB supports the Gremlin graph query language, which its backend processes using a custom .NET-based Gremlin execution engine rather than the JVM-based open-source implementations most Gremlin servers use. The engine compiles Gremlin queries into .NET code and runs them inside a restricted sandbox.
That sandbox enforced restrictions on which Gremlin operations queries could invoke — but it did not restrict .NET reflection, a runtime capability that allows code to dynamically inspect and invoke arbitrary types and methods at runtime, bypassing the type-system checks the sandbox relied on. By crafting queries that exploited this gap, Wiz researchers built file-read and file-write primitives and ultimately achieved arbitrary code execution via crafted queries on the Cosmos DB backend — all from queries submitted against their own database, with no access to any victim account.
Code execution landed on the DB Gateway, a Microsoft service component that runs on multi-tenant Azure Service Fabric clusters and executes customer queries on their behalf. The gateway did not store customer databases, but it did hold the credentials needed to reach them: specifically, a signing key that could retrieve the primary account key for any Cosmos DB account on the service.
The Cosmos Master Key: One Credential, Unlimited Scope
Primary keys in Cosmos DB grant full read, write, and delete access to every database, container, and document in the associated account. Microsoft’s Cosmos DB access control documentation describes the master key token as the all-access key token that allows users to have full control of Cosmos DB resources. The Cosmos Master Key retrieved from the gateway could request the primary key for any account — regardless of tenant, region, or whether the account used the SQL, MongoDB, Cassandra, or Gremlin API.
The same credentials also unlocked what Wiz called the Config Store — a regional Cosmos DB database serving as a directory of every Cosmos DB account on the service. The Config Store was itself queryable using the Cosmos DB SQL engine, which meant an attacker could enumerate every account in a region, or filter by Azure tenant ID or subscription ID to precisely locate a specific organization’s databases, and then use the Cosmos Master Key to retrieve their primary key. Two steps, from public endpoints, with only an attacker’s own Cosmos DB account required as a starting point, Wiz told HackRead.
Robert Costello, Chief Digital and Information Officer at Merlin Group, described the structural significance of the finding: the flaw’s potential to expose every Cosmos DB instance simultaneously is a reminder that even the largest cloud providers must continuously test their own environments. Costello made the remarks to HackRead.
How No Customer Setting Could Have Helped
This is the detail that distinguishes CosmosEscape from a typical cloud vulnerability: there was nothing an Azure customer could have configured, enabled, or disabled to prevent it. No firewall rule, no private endpoint, no customer-managed key setting, no role-based access control. The vulnerability lived in Microsoft’s shared infrastructure — in the gateway layer that the service runs on behalf of all tenants — not in any customer’s account settings.
That is the architecture Wiz’s conclusion addresses: cloud platforms are built in layers, and a vulnerability in the infrastructure tier can cascade upward to threaten every service built on top of it. The full analysis of the attack chain makes clear that the only remediation path was architectural, and only Microsoft could execute it.
Disclosure Timeline and What Microsoft Changed
Wiz reported CosmosEscape to Microsoft on November 20, 2025. Microsoft acknowledged receipt that same day. Within 48 hours — by November 22 — Microsoft deployed a hotfix that blocked the vulnerable Gremlin API entry point. That action prevented further exploitation of the specific query path Wiz discovered, but did not eliminate the Cosmos Master Key or restructure the gateway’s credential model.
That longer-term architectural work concluded in July 2026, when Microsoft completed a full architectural fix rolled out across all Azure regions. The Cosmos Master Key no longer exists in Cosmos DB’s architecture. Microsoft also introduced stronger service-to-service authentication, new network protections, and additional monitoring and detection capabilities.
The full exploitation chain — including the crafted Gremlin query that initiated the sandbox escape — will be presented at Black Hat USA in a briefing titled "One Key to Rule Them All: Taking Over a Flagship Cloud Service," scheduled for August 6. The talk is listed on the Black Hat USA 2026 briefings schedule.
CosmosEscape carries no CVE identifier and no CVSS severity score. Wiz and Microsoft confirm it is technically distinct from prior Cosmos DB flaws ChaosDB (2021) and CosMiss (2022), both of which involved Cosmos DB’s Jupyter Notebook feature rather than the Gremlin execution engine.
How AI Helped Find It
CosmosEscape was partly discovered using Atlas, Wiz’s autonomous AI vulnerability research system, which the company publicly launched on July 27, 2026. Atlas operates as a collaborative system of specialized AI agents rather than a single model; Wiz says it ranked first on the CyberGym benchmark with a 90.9% success rate and has found more than 200 previously unknown vulnerabilities in heavily audited open-source code. The CosmosEscape disclosure represents the first publicly confirmed instance of Atlas assisting in the discovery of a critical cloud infrastructure vulnerability.
What Enterprises Cannot Yet Know
Microsoft’s public statement confirms that its log review found no unauthorized activity outside of Wiz’s testing. What it does not confirm is the period that review covered, nor when the vulnerable Gremlin execution engine and the Cosmos Master Key architecture first entered Cosmos DB’s production environment. If those components have existed since Gremlin API support launched, or since Cosmos DB itself launched in 2017, the theoretical exposure window extends beyond what the November 2025 report date implies.
This mirrors a disclosure pattern Wiz observed with ChaosDB in 2021, where TechTarget reporting noted that the Jupyter Notebook flaw had potentially existed anywhere from several months to years before discovery. Microsoft has not offered an equivalent clarification for CosmosEscape.
For enterprises with significant Cosmos DB workloads, the practical implication is narrow but meaningful: Microsoft has said no unauthorized access occurred, based on a log review it conducted. Customers who want to reach their own conclusion can review their own Cosmos DB audit logs for anomalous access patterns — unexpected primary key retrievals, unusual database enumeration queries, access from unfamiliar source IPs — predating November 2025. Microsoft has not specified what patterns in those logs would constitute a red flag, nor stated what period its own review of access logs covered.
Frequently Asked Questions
Do I need to take any action to secure my Azure Cosmos DB account after CosmosEscape?
No. Microsoft has fully patched the vulnerability, including eliminating the Cosmos Master Key from Cosmos DB’s architecture and deploying additional monitoring. There is no customer-side action required. If you want to conduct your own due diligence, you can review your Cosmos DB audit logs for unusual access patterns predating November 2025, particularly unexpected primary key retrievals or database enumeration activity from unfamiliar sources.
How did the Gremlin sandbox escape actually work, and why couldn’t Microsoft’s restrictions stop it?
Cosmos DB’s Gremlin engine compiled graph queries into .NET code and ran that code inside a restricted environment. The restrictions targeted which Gremlin operations the code could invoke, but they did not account for .NET reflection — a runtime feature that allows code to dynamically call any type or method available in the .NET runtime, bypassing compile-time restrictions. Wiz built file-read and file-write capabilities entirely through crafted Gremlin queries, then escalated to arbitrary code execution. The sandbox was insufficient because it restricted what the code said it would do, not what the underlying runtime could be instructed to do, as Wiz’s technical write-up explains.
Why were Microsoft Teams, Copilot, and Entra ID potentially within reach?
Those products store data in Azure Cosmos DB as part of Microsoft’s internal infrastructure. Because CosmosEscape’s attack chain accessed the shared DB Gateway — which holds credentials to reach any Cosmos DB account on the service — and because the Config Store gave attackers a queryable directory of every account, databases backing Microsoft’s own internal products were theoretically reachable through the same chain used to reach any other customer’s databases. Microsoft has confirmed that no data from those products was accessed outside of Wiz’s research.
Why was the exposure window unknown, and should that concern enterprises?
Microsoft and Wiz have disclosed when the vulnerability was reported (November 2025) and when it was patched (November 22, 2025 for the Gremlin entry point; July 2026 for the architectural fix). What neither has disclosed is when the vulnerable Gremlin execution engine and the Cosmos Master Key architecture first entered production. Microsoft’s log review found no unauthorized activity, but the period covered by that review is also unstated. Enterprises with sensitive Cosmos DB workloads who want to reach their own conclusion should review their audit logs for the period before November 2025 for unusual access patterns, while recognizing that Microsoft has found no evidence of actual exploitation, as The Hacker News reported.
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.