Wiz Research has disclosed CosmosEscape, a vulnerability chain in Azure Cosmos DB that let an attacker escape the service’s query sandbox, execute code on Microsoft’s shared multi-tenant gateway, and pull a platform-wide secret capable of retrieving the primary key for any Cosmos DB account on the service — across SQL, MongoDB, Cassandra, and Gremlin API surfaces, regardless of tenant or region. No CVE was assigned and no CVSS score published; Microsoft treated it as a cloud-service-side fix rather than a customer-patchable vulnerability, since the flaw lived entirely in Microsoft’s infrastructure. It was reported in November 2025, the immediate entry point was blocked within 48 hours, and Microsoft completed the full remediation — removing the platform-wide key outright — across all regions by July 2026.

How the sandbox broke

Cosmos DB’s Gremlin API accepts graph traversal queries and translates them into .NET code that executes inside the DB Gateway, a service that runs customer queries on shared, multi-tenant Service Fabric clusters. To keep that execution contained, Microsoft restricted which Gremlin operations a query could invoke — blocking the obvious paths to file access or arbitrary method calls.

What the restrictions didn’t account for was .NET reflection: a runtime feature that lets code look up and invoke essentially any type or method available in the .NET runtime by name, at execution time, rather than at compile time. Static allow-lists on Gremlin operations don’t stop a query that uses reflection to reach outside the intended API surface entirely. Wiz used this gap to build a chain of primitives — first file read, then file write, and ultimately arbitrary code execution — running inside the Gremlin query engine’s process on the gateway.

From code execution to every customer’s keys

Code execution on the DB Gateway isn’t itself the end state — that gateway is shared infrastructure serving many tenants at once, so the interesting question is what an attacker reachable from a single Gremlin query can see from inside it. Wiz found a Cosmos Master Key: a platform-wide signing secret that was not scoped to any individual customer, account, or region. With it, an attacker could query internal endpoints to look up and retrieve the primary key for any Cosmos DB account on the platform, then authenticate directly against that account with full read/write access — no relationship to the victim account required beyond knowing (or enumerating) its identifier.

Because the master key worked across API formats, the blast radius wasn’t limited to Gremlin customers. Any Cosmos DB account — SQL API, MongoDB API, Cassandra API — was exposed once an attacker held that key, since retrieval of the primary key was the only barrier and the key wasn’t per-tenant.

Impact

This is a full cross-tenant data-plane compromise scenario for one of Azure’s flagship managed database services: reads, writes, and deletes against arbitrary customer Cosmos DB accounts, limited only by an attacker’s ability to identify target account names — which, as with the Vertex AI staging-bucket bug disclosed earlier this year, are often guessable or simply public. Wiz found no evidence the technique was exploited in the wild before their report, and Microsoft’s initial containment (blocking the vulnerable Gremlin entry point) landed within two days of disclosure, well before the July 2026 public write-up.

There is nothing for Cosmos DB customers to patch — the vulnerable components (Gremlin sandbox, gateway, and master key architecture) are entirely Microsoft-operated. The fix shipped platform-side.

What to do now

  • If you run Gremlin-API workloads on Cosmos DB, confirm with Microsoft support or your account team that the region(s) you use received the July 2026 remediation.
  • Review Cosmos DB audit logs and diagnostic settings for unusual authentication activity on your account around the disclosure window (November 2025–July 2026), particularly key-based auth from unfamiliar source ranges.
  • More broadly, treat any managed-service “master key” or platform-wide credential architecture as a systemic single point of failure. CosmosEscape is the second major Azure cross-tenant disclosure this year to trace back to a shared secret or predictable identifier bridging tenant boundaries that should never have touched each other. Ask your cloud vendors directly whether platform-wide signing keys exist behind services you depend on, and how they’re scoped.
  • Rotate Cosmos DB primary/secondary keys periodically regardless of this disclosure, and prefer Azure AD (Entra ID) authentication with fine-grained RBAC over key-based auth where your workload supports it — a leaked or recovered key is a full-account compromise, while a compromised AAD identity can be scoped and revoked.

References: Wiz Research, “CosmosEscape: Taking Over Every Database in Azure Cosmos DB”; The Hacker News coverage; SecurityWeek coverage.