# One Key, Every Database: How a Gremlin Query Could Have Unraveled Azure Cosmos DB
Microsoft's cloud databases got a lot more interesting last November when researchers at Wiz discovered they could escape Cosmos DB's query sandbox, land code execution on a shared gateway, and then retrieve the primary key for *any customer account on the platform* — across all tenants, all regions, and all APIs.
The chain, which Wiz codenamed CosmosEscape, didn't require targeting a specific victim's credentials. It required owning one Cosmos DB account — your own — and knowing that somewhere in the DB Gateway lurked a signing key with the blast radius of a skeleton key.
## How the Sandbox Broke
Cosmos DB supports multiple wire protocols: SQL, MongoDB, Cassandra, and Gremlin. The last one — Gremlin, a graph query language — became the attack's entry point because of how Microsoft implemented it.
Under the hood, Cosmos DB's Gremlin engine translates graph queries into .NET code and executes them inside a restricted runtime. The restriction was supposed to limit what that code could do. The problem was that the restriction didn't account for .NET reflection — the mechanism that lets code inspect and invoke types at runtime without going through normal access controls.
Wiz used reflection to build file-read and file-write primitives inside the sandbox, then parlayed those into arbitrary code execution on the backend host. Their public disclosure includes the output of a command — hostname — running on the Cosmos DB infrastructure. The query itself won't be published until August 6, when Wiz presents the full chain at Black Hat USA.
That code execution landed on what Wiz calls the DB Gateway: a multi-tenant service running on Azure Service Fabric clusters, responsible for executing customer queries. Customer data wasn't stored there. But the gateway could do something nearly as valuable — it could retrieve the primary account key for any Cosmos DB account it was asked about.
## The Master Key Problem
Cosmos DB primary keys are not granular. Microsoft's own documentation is blunt about this: a primary key grants full control over all resources in an account — data, settings, everything. Hand that key to an attacker and the account is forfeit.
The gateway's access to individual account keys was, on its own, alarming. But Wiz found something worse.
The gateway held a signing secret they called the Cosmos Master Key — a platform-wide credential capable of retrieving the primary key for any Cosmos DB account across all customer tenants, all Azure regions, and every supported API: SQL, MongoDB, Cassandra, and Gremlin. The same signing key also opened a Config Store: a regional directory containing account names, subscription and tenant identifiers, network configurations, and resource tags. An attacker could use the Config Store to enumerate a target's accounts and then request their keys.
The scope is worth sitting with. One crafted Gremlin query from an attacker-owned account — a starting position that requires only legitimate Cosmos DB credentials — could theoretically lead to full read/write access to any other customer's database on the platform.
## "Network-Isolated" Meant Nothing Here
Cosmos DB offers private endpoint and network-isolated configurations — features customers use specifically because they're managing sensitive data. Wiz found that those protections didn't apply in this scenario.
Network isolation in Cosmos DB enforces restrictions at the network boundary *outside* the service. The compromised gateway operated *inside* that boundary, meaning it could reach private accounts regardless of what network rules had been configured. An attacker with gateway-level access could retrieve keys for accounts their own traffic would never normally touch.
Wiz also noted that write access to the Config Store theoretically allowed modification of network settings, though they say they didn't demonstrate that against real customer accounts.
## What Was Actually at Risk
Microsoft says its review found no evidence of unauthorized access outside Wiz's own testing, and customers have been told no action is required.
But the disclosure quietly names some high-profile tenant applications: Teams stores message data in Cosmos DB; Copilot stores user queries and conversation histories there. Wiz says those databases were *potentially accessible* via CosmosEscape. They didn't access that data — but the attack path existed, at platform scale, for the period between when the vulnerability was introduced and when the fix was finalized.
The full remediation timeline: Wiz reported the issue in November 2025, Microsoft blocked the Gremlin entry point within 48 hours, and the longer-term fix — which included eliminating the platform-wide key architecture itself — rolled out across all regions in July 2026. That's roughly eight months from report to complete structural fix.
## HackWire Analysis
CosmosEscape fits an uncomfortable pattern in cloud security: platform-wide signing secrets that function as skeleton keys. This is the same architectural category as the 2023 Storm-0558 incident, where a Microsoft signing key was used to forge authentication tokens across multiple Azure services, and Wiz's own 2021 ChaosDB finding in Cosmos DB, where a misconfiguration gave access to other customers' databases. In each case, the blast radius wasn't bounded by normal tenant isolation — it was bounded only by how many customers happened to be on the same platform.
The eight-month remediation window for the structural fix deserves more scrutiny than it's gotten. Blocking the Gremlin entry point in 48 hours is responsive. But if the underlying architecture — a single signing secret with cross-tenant key-retrieval authority — persisted for eight months after the report, the question isn't just "was it exploited?" The question is: who else might have found this path independently? Novel exploit chains discovered by well-resourced security firms are occasionally discovered by threat actors first or concurrently. Microsoft's log review found nothing, but platform-level attacks against cloud infrastructure are notoriously difficult to detect retroactively, particularly if an attacker understood what they were looking at and stayed quiet.
The Teams and Copilot data angle is also being underreported. Most coverage frames this as a database vulnerability story. It is also, if the attack had been weaponized, a corporate communications surveillance story and an AI-conversation-history exfiltration story. Those are different risk categories, and the enterprises running regulated workloads on Cosmos DB should factor the full exposure window into their own incident documentation — even if Microsoft found nothing.
For defenders: the immediate risk is patched. The lasting lesson is to audit which platform-level components in your cloud environment have cross-tenant reach, and what logging exists if those components behave abnormally. Cloud providers rarely publish the architecture of their internal service credentials, which means customers can't independently assess this exposure class — they have to trust vendor disclosure. That asymmetry is a governance problem the industry hasn't solved.
Full technical details drop at Black Hat USA on August 6. Security teams should plan to review Wiz's presentation for the complete Gremlin query logic and any prerequisites the public disclosure hasn't addressed.
— *HackWire Editorial*
---
## Related Coverage