# The Key to Everything: How a Graph Query Bug Nearly Cracked Azure's Crown Jewels
When researchers at Wiz started poking at the Azure Cosmos DB Gremlin API last November, they expected to find something. They did not expect to find a key that unlocked *every database on the platform* — including Microsoft's own.
That's what CosmosEscape delivered.
## From Graph Queries to Code Execution
Gremlin is a graph query language — the kind of thing you'd use to traverse relationship data, model social networks, or map identity graphs. In Azure Cosmos DB, Microsoft implemented a custom Gremlin engine that compiles queries into .NET code and runs them inside a sandbox. The sandbox was supposed to prevent anything Gremlin-shaped from reaching anything it shouldn't touch.
The restriction held — for Gremlin operations. It did not account for .NET reflection.
Reflection is a .NET feature that lets code inspect and invoke other code at runtime, bypassing the usual access controls that a developer would expect to enforce a security boundary. Wiz used it to build arbitrary code execution primitives inside the Gremlin sandbox, then walked right out of the sandbox and onto the DB Gateway — the service that processes customer queries across multi-tenant Service Fabric clusters.
Here's where it gets genuinely alarming. The Gateway was using a signing key to retrieve customers' primary keys and access their databases on their behalf. Standard enough architecture, until you look at the scope of that key: it worked across tenants, across regions, and across APIs. One key. Platform-wide.
Wiz named it the Cosmos Master Key, which is either understated or perfectly accurate depending on your temperament.
## The Configuration Store Problem
With the master key in hand, Wiz's researchers found something worse than access to customer databases. They found the configuration store — a Cosmos DB database containing the account details for *every* Cosmos DB account on the service: names, subscription IDs, tenant IDs, and additional configuration data. The whole registry.
The configuration store was itself a Cosmos DB database, which meant it could be queried with full SQL flexibility. It also meant the master key could retrieve its primary key. An attacker who chained these steps could enumerate all accounts in a region, filter them by subscription or tenant ID, pull a target's primary key, and gain full read and write access to that organization's databases — all through publicly accessible endpoints.
Private accounts. Network-isolated accounts. Microsoft's own accounts.
Because Microsoft runs Cosmos DB as the backend for Entra ID, Teams, and Copilot, the vulnerability exposed the tech giant's own data infrastructure to the same attack path it exposed to every customer. An attacker targeting a specific enterprise wouldn't even need to be lucky — they could filter the config store by that organization's tenant ID and go straight to the target.
"Chained together, these capabilities could have enabled precision targeting at platform scale," Wiz noted in its writeup. That's a careful way of saying: this was close to catastrophic.
## The Disclosure and the Two Timelines
Wiz reported CosmosEscape to Microsoft in November 2025. Two days later, Microsoft had deployed a hotfix blocking the attack vector. That's a fast response for a platform of this scale, and credit is due.
The full story is longer. The hotfix patched the immediate vector. Microsoft didn't complete the rollout of a long-term architectural fix across all regions until July 2026 — eight months after disclosure. The company reviewed access logs and found no evidence of unauthorized activity beyond the researchers' own testing. No customer data was accessed.
That's the best possible outcome, and it's also exactly what you'd expect a vendor to report. Log forensics for cloud-scale infrastructure is genuinely hard, especially when an attacker who understood the blast radius of this key would know to avoid leaving obvious traces.
## HackWire Analysis
CosmosEscape deserves attention beyond the headline because it fits a pattern that keeps recurring in cloud security: platform-wide signing keys as catastrophic single points of failure.
In 2023, the Storm-0558 incident revealed that Chinese state actors had obtained a Microsoft signing key capable of forging authentication tokens for Azure Active Directory — effectively a skeleton key for cloud identity. Microsoft's post-incident review acknowledged that a series of failures had allowed the key to persist, circulate, and ultimately be stolen. The Cosmos Master Key is structurally similar: a single cryptographic credential with cross-tenant, cross-region scope, living inside a service that processed queries from millions of customers.
The uncomfortable question is how many more of these exist. Cloud platform architectures frequently use internal signing keys for service-to-service authentication — it's a practical necessity at scale. The problem is that when those keys are designed with platform-wide scope rather than least-privilege scope, a single compromise produces a blast radius that no individual customer can protect against. You can harden your own Cosmos DB account. You cannot protect it from a vulnerability in the signing infrastructure that underpins the entire service.
For defenders, the lesson here is limited in scope but important in framing: cloud security posture reviews need to account for risks that exist *above* the customer control plane. Reviewing your own access policies is necessary but not sufficient when the platform itself can be the attack vector. Organizations with serious data in Cosmos DB — and that's a lot of organizations — should be asking their cloud providers pointed questions about key scope, tenant isolation guarantees, and the architectural boundaries between internal and customer-facing access.
The eight months between hotfix and full architectural remediation is also worth watching. Quick patches address immediate vectors. Architectural debt, the kind that produces platform-wide keys in the first place, takes longer to unwind. That gap is the window threat actors would most want to know about.
Microsoft says no customer data was accessed. Let's take that at face value while also being honest about what "no evidence of unauthorized access" means: it's the best forensic answer available, not a guarantee. The Cosmos Master Key had scope broad enough that a sophisticated actor could have used it without announcing themselves.
CosmosEscape didn't explode. But it was loaded.
— HackWire Editorial
---