CosmosEscape: Wiz Research Extracted a Single Key That Could Read and Write Every Azure Cosmos DB Database — Platform-Wide Master Key, Config Store Enumeration, Entra ID and Teams in Scope, No Customer Action Required

Sources: Wiz Research — “CosmosEscape: Taking Over Every Azure Cosmos DB” (primary blog, full technical disclosure, July 30, 2026) · The Hacker News — “Azure Cosmos DB Flaw Exposed Platform-Wide Key That Could Access Any Database” · TechTimes — “CosmosEscape: Wiz Research Breached Azure Cosmos DB Gateway, Extracted Key to Every Database” · CybersecurityNews — “New CosmosEscape Vulnerability Lets Attackers Take Over Azure Cosmos DB Instances” · SecurityWeek — “Critical Flaw Led to Azure Cosmos DB Pwnage” · GBHackers — “CosmosEscape Vulnerability Enables Full Takeover of Azure Cosmos DB Databases” · Windows News · CXO Digital Pulse | Vulnerability name: CosmosEscape | Discovered by: Wiz Research | Reported to Microsoft: November 20, 2025 | Hotfix deployed: November 22, 2025 (48 hours — Gremlin entry point blocked) | Full architectural fix: July 2026 (Cosmos Master Key eliminated) | Public disclosure: July 30, 2026 | CVE: None assigned | Severity score: None assigned | Customer action required: None — server-side fix | Microsoft internal databases affected: Yes — Wiz confirmed access to Microsoft-internal Cosmos DB records including Entra ID, Teams, and Copilot data | No customer data accessed: Microsoft confirmed, outside Wiz’s own testing | Prior Wiz Cosmos DB disclosures: ChaosDB (August 2021) · CosMiss (2022) | Black Hat USA 2026 briefing: “One Key to Rule Them All: Taking Over a Flagship Cloud Service”

One query. One .NET reflection trick. One platform-wide key. Every customer database on Azure Cosmos DB. “The Cosmos Master Key wasn’t scoped to a tenant, a region, or an API type. It covered all of them.” — Wiz Research

On July 30, 2026, Wiz Research published the technical disclosure for CosmosEscape — a chain of vulnerabilities in Azure Cosmos DB’s Gremlin API that, when exploited, allowed any attacker with a standard Cosmos DB account to break out of the service’s query sandbox, execute arbitrary code on Microsoft’s multi-tenant database gateway, and retrieve a single platform-wide signing key capable of reading or overwriting data in every customer database on the service. Wiz Research uncovered CosmosEscape, a critical vulnerability in Azure’s flagship database service, Azure Cosmos DB, via its Gremlin API. The vulnerability could have been exploited to compromise every database in the service, including Microsoft’s own internal databases — potentially enabling a cross-service attack.

The key Wiz retrieved — which they named the Cosmos Master Key — was not scoped to any individual customer, region, or API type. Unlike keys limited to individual customer accounts, this master key could access the primary key for any Azure Cosmos DB account across different tenants, geographic regions, and supported API types, including SQL, MongoDB, Cassandra, and Gremlin. Possession of an account’s primary key grants full administrative data-plane access — read, modify, or delete any data in that account. The Cosmos Master Key was the key to every lock on the platform, all at once.

Microsoft received Wiz’s report on November 20, 2025, deployed a hotfix blocking the vulnerable Gremlin entry point within 48 hours, and completed a full architectural fix eliminating the Cosmos Master Key across all Azure regions in July 2026. 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.”

The exploit chain — how a graph query became a master key to every database

Stage 1 — The .NET anomaly that broke the investigation open

Wiz researchers were experimenting with Gremlin, a popular graph query language supported by Cosmos DB, when they noticed an unusual .NET exception. Since most open-source Gremlin implementations run on the Java Virtual Machine (JVM), this suggested that Cosmos DB used a custom .NET-based Gremlin engine instead. This observation was the crack in the door. Gremlin query sandbox implementations on the JVM have a well-studied attack surface. Custom .NET-based Gremlin implementations are much rarer, less battle-tested, and potentially subject to attack vectors that JVM-based implementations would never encounter.

That distinction mattered because Gremlin servers typically compile queries into executable code and run them inside a restricted sandbox, and such sandboxes have historically proven fragile against determined attackers. Wiz’s hypothesis — that the .NET-based custom engine might have exploitable sandbox restrictions — proved correct.

Stage 2 — .NET reflection bypasses sandbox restrictions

The Cosmos DB Gremlin engine compiled customer-submitted graph queries into executable .NET code and ran that code inside a restricted sandbox intended to confine execution to Gremlin operations only. While the engine enforced restrictions to prevent access beyond Gremlin operations, it did not account for .NET reflection. .NET reflection is a language feature that allows code to inspect and invoke type members at runtime — it is used legitimately for serialization, dependency injection, and dynamic method invocation throughout the .NET ecosystem. In a sandbox context, reflection provides a mechanism to access types and methods that are not directly visible from the restricted execution environment.

Wiz used .NET reflection to build arbitrary code execution primitives — the ability to run arbitrary code, not just Gremlin operations, within the sandbox environment. From arbitrary code execution inside the sandbox, the next step was breaking out entirely.

Stage 3 — Code execution on the multi-tenant DB Gateway

“By bypassing the Gremlin sandbox, we’ve gained code execution on the DB Gateway, a service that executes customer queries on their behalf, running on multi-tenant Service Fabric clusters.” The DB Gateway is the shared infrastructure layer that sits between Cosmos DB customers and the underlying database storage — it processes queries from multiple customers simultaneously on shared Service Fabric clusters. This is the point at which tenant isolation is supposed to be enforced. An attacker with code execution on the DB Gateway is outside their own tenant boundary and has access to the shared infrastructure that serves all customers.

Stage 4 — The Cosmos Master Key

With code execution on the multi-tenant DB Gateway, Wiz discovered credentials in the environment that provided access to the Cosmos Master Key — the platform-wide signing secret. Researchers discovered credentials within the environment that provided access to a platform-wide signing key, which Wiz referred to as the “Cosmos Master Key.” Unlike keys limited to individual customer accounts, this master key could access the primary key for any Azure Cosmos DB account across different tenants, geographic regions, and supported API types, including SQL, MongoDB, Cassandra, and Gremlin.

The primary key of a Cosmos DB account is the highest-privilege credential in Cosmos DB’s access model — it grants full administrative data-plane access: read any data, modify any data, delete any data, manage collections and databases. The Cosmos Master Key could retrieve the primary key for any account. One key, retrieved by exploiting one customer’s Gremlin sandbox, gave access to every other customer’s database on the platform.

Stage 5 — The Config Store: a directory of every database on the platform

The Cosmos Master Key also unlocked access to the Config Store — essentially Cosmos DB’s master directory listing every account on the platform along with subscription IDs, tenant IDs, network rules, and tags. Because the Config Store was itself a Cosmos DB database, attackers could query it directly. Because the Config Store was itself a queryable Cosmos DB database, attackers could have used it to enumerate every account in a region or filter results by tenant ID to precisely target a specific organization. An attacker who wanted to target a specific enterprise customer could query the Config Store for that organization’s tenant ID, identify their Cosmos DB accounts, and retrieve the primary key for each. The enumeration capability combined with the key retrieval capability made targeted cross-tenant attacks precise and efficient.

Microsoft’s own databases were in scope — Entra ID, Teams, and Copilot

The detail that elevates CosmosEscape from a severe customer-data vulnerability to a potential cross-service attack against Microsoft itself: Because Microsoft uses Cosmos DB to store data across Entra ID, Teams, and Copilot, the vulnerability potentially exposed the tech giant’s databases to unauthorized access. The Cosmos Master Key did not distinguish between customer databases and Microsoft’s own internal service databases. If Microsoft’s Entra ID, Teams, and Copilot infrastructure stored data in Azure Cosmos DB — which Wiz’s investigation confirmed they do — then those databases were also accessible via the Cosmos Master Key.

The potential downstream implications of access to Microsoft’s Entra ID Cosmos DB data are significant: Entra ID is the identity plane for Microsoft 365, Azure, and every service that uses Microsoft’s cloud identity. Wiz’s disclosure does not claim to have accessed Entra ID data or to have confirmed that such access would have yielded exploitable identity material — they flag the theoretical exposure path, not a confirmed compromise. Microsoft has stated no customer data was accessed outside Wiz’s own testing environment.

Why CosmosEscape is different from ChaosDB — and why it matters more

Wiz has disclosed two prior Azure Cosmos DB vulnerabilities: ChaosDB in August 2021 and CosMiss in 2022. CosmosEscape is technically separate from both — and structurally more severe. While ChaosDB exploited a weakness in a customer-facing feature, CosmosEscape cut to the heart of Azure’s multi-tenant architecture.

ChaosDB exploited a vulnerability in the Jupyter Notebook feature that Cosmos DB offered — it required that feature to be enabled and accessed the Cosmos DB account of the victim. The blast radius was one customer at a time. CosmosEscape exploited the shared gateway infrastructure that every Cosmos DB account passes through and retrieved a key that worked across every account simultaneously. The blast radius was the entire platform.

The architectural lesson Wiz draws in their primary blog: chaining sandbox escapes with unscoped signing keys bypasses fundamental cloud isolation boundaries. These architectural risks align with broader Microsoft vulnerability trends, in which overprivileged machine accounts and underlying service permissions amplify the potential blast radius of a single exploit. This is the structural pattern that CosmosEscape shares with prior Microsoft cloud vulnerabilities: a credential that should be scoped narrowly (to one customer, one region, one API type) is instead scoped broadly (to everything), and when that credential is reachable from a customer-exploitable attack path, the blast radius is the entire service.

The remediation timeline — eight months from report to architectural fix

The timeline of Microsoft’s response is worth examining precisely because it illustrates the difference between a tactical fix and an architectural fix:

• November 20, 2025: Wiz reports CosmosEscape to Microsoft. Microsoft acknowledges receipt same day.
• November 22, 2025 (48 hours): Microsoft deploys a hotfix blocking the specific Gremlin API entry point Wiz used. This prevents the specific exploit chain from working. It does not eliminate the Cosmos Master Key or restructure the gateway’s credential model.
• November 2025 – July 2026 (8 months): Microsoft works on the full architectural fix — eliminating the Cosmos Master Key entirely, restructuring service-to-service authentication so that no single credential can access data across all tenants, deploying new network protections and monitoring capabilities.
• July 2026: Microsoft completes the architectural fix rollout across all Azure regions. The Cosmos Master Key no longer exists in Cosmos DB’s architecture.
• July 30, 2026: Wiz publishes coordinated public disclosure. Microsoft provides statement confirming full remediation and no confirmed customer data access.

The eight-month gap between tactical fix and architectural fix is not a criticism of Microsoft’s response — it reflects the genuine complexity of eliminating a platform-wide shared credential from the architecture of a flagship cloud service running across every Azure region globally. Migrating from a Cosmos Master Key model to properly scoped service-to-service authentication across a multi-region, multi-tenant, multi-API-type database service is a major infrastructure project. The 48-hour tactical fix closed the specific attack path. The eight-month architectural fix closed the underlying structural vulnerability that made the specific attack path so dangerous.

What enterprises need to understand — the cloud tenant isolation threat model

CosmosEscape requires no customer action. But it requires a threat model update. The fundamental assumption CosmosEscape challenges is that cloud-native managed services enforce tenant isolation as an absolute guarantee. The risk is particularly sobering because it wasn’t a user misconfiguration; it was a break in the service’s own multitenant isolation, threatening the fundamental boundary between cloud tenants.

Wiz’s three consecutive Cosmos DB disclosures — ChaosDB (2021), CosMiss (2022), CosmosEscape (disclosed 2026) — demonstrate that cloud service tenant isolation has been broken multiple times in the same flagship service, by the same research team, over a five-year window. This is not an indictment of Azure specifically — similar isolation vulnerabilities have been found in AWS and GCP services. It is a structural observation about the threat model for managed cloud services generally: the service provider’s shared infrastructure is an attack surface that customers cannot audit, patch, or control. When a vulnerability exists in that shared infrastructure, no amount of customer-side security controls prevents the exposure.

The operational implication for enterprises: build your cloud data security posture assuming that cloud service tenant isolation may, at any given time, be imperfect. Data that must not be accessible to any other entity — not other tenants, not cloud provider employees, not researchers with a Gremlin query — should be encrypted with customer-managed keys (CMK) before storage in any cloud-native managed database service. CMK encryption means that even an attacker who obtains the Cosmos DB primary key for your account cannot read your data without also obtaining your customer-managed encryption key, which is stored separately in Azure Key Vault or equivalent.

Sources and further reading

• Wiz Research — “CosmosEscape: Taking Over Every Azure Cosmos DB” (Primary Technical Disclosure)
• The Hacker News — “Azure Cosmos DB Flaw Exposed Platform-Wide Key That Could Access Any Database”
• TechTimes — “CosmosEscape: Wiz Research Breached Azure Cosmos DB Gateway, Extracted Key to Every Database”
• CybersecurityNews — “New CosmosEscape Vulnerability Lets Attackers Take Over Azure Cosmos DB Instances”
• SecurityWeek — “Critical Flaw Led to Azure Cosmos DB Pwnage” (Microsoft Internal Database Scope Confirmed)
• GBHackers — “CosmosEscape Vulnerability Enables Full Takeover of Azure Cosmos DB Databases”
• Windows News — “CosmosEscape Flaw Fixed: What Azure Cosmos DB Users Need to Know Despite ‘No Action Required'”

DataWater publishes daily cybersecurity intelligence for enterprise and government security leaders. Article #51 — July 31, 2026. Previous: Copilot for Word AI Worm (July 30) · ExploitGym Expansion (July 29) · Arista VeloCloud CVSS 10.0 (July 28). Full archive →