CosmosEscape: One Key Unlocked Every Azure Cosmos DB

Wiz just broke Azure Cosmos DB again. Five years after ChaosDB handed the same research team the primary keys to other tenants' databases, a new flaw the team calls CosmosEscape did something worse: it exposed a single platform-wide secret that could unlock read-write access to every Cosmos DB account on the service — customer databases, network-isolated accounts, and Microsoft's own backend stores for Entra ID, Teams, and Copilot alike.

There's a temptation to file this under "another cloud CVE, patched, move on." Microsoft says there's no evidence of malicious exploitation and no customer action required, and both are probably true. But the interesting part isn't the bug. It's that the same class of mistake keeps surfacing in the same product, and that the trust model most Cosmos DB apps still rely on is exactly the thing this attack targeted.

The chain, in one breath

The entry point was the Gremlin API — Cosmos DB's graph-query surface. Cosmos DB compiles Gremlin traversals down to executable .NET on the backend, and the sandbox that was supposed to fence that code in didn't fully account for .NET reflection, the runtime's ability to inspect and invoke arbitrary types at execution time. Wiz crafted a Gremlin query that reflected its way out of the sandbox and ran hostname on the host. That host was the DB Gateway: a shared, multi-tenant Service Fabric cluster that fronts requests for many customers at once.

Code execution on the Gateway is bad on its own. What turned it into a service-wide compromise was what the Gateway could reach — a signing key Wiz dubbed the "Cosmos Master Key," scoped platform-wide instead of per-account. That key did two things. It minted the primary key for any Cosmos DB account on demand, across every API flavor (SQL, MongoDB, Cassandra, Gremlin) and every region. And it unlocked the Config Store, a regional metadata database, letting an attacker enumerate every account on the platform and filter by subscription or tenant ID to find a specific target.

The kicker is network isolation. Private endpoints and IP firewalls on Cosmos DB are enforced by the Gateway itself. Once you own the thing that enforces the boundary, the boundary is decorative. A locked-down, VNet-only Cosmos account was as reachable as a public one.

We have seen this movie

In 2021, the same Wiz researchers found ChaosDB: the Jupyter Notebook feature baked into Cosmos DB ran with enough privilege to pull other customers' primary keys. Different feature, same shape. A customer-facing convenience — notebooks then, graph queries now — runs code on shared infrastructure, and that infrastructure holds a credential far more powerful than the feature needs.

That pattern isn't unique to Azure, but Cosmos DB has now demonstrated it twice, which makes it worth naming plainly: the risk in a managed multi-tenant PaaS isn't usually the storage layer. It's the control plane that brokers access to it. Every one of these products has some privileged component that can vend credentials for any tenant, because that's how the service provisions and routes. The security of the whole thing rests on that component never running attacker-influenced code. Gremlin's compile-to-.NET design put attacker input one reflection trick away from exactly that.

To Microsoft's credit, the remediation went past a patch. Rather than just tightening the Gremlin sandbox — which would leave the master key sitting there for the next escape — the fix eliminated the Cosmos Master Key entirely, so no single secret can vend primary keys platform-wide anymore, plus added network hardening and detection. That's addressing the blast radius, not just the ignition source, and it's the right call. The timeline was tight where it counted: Wiz reported on November 20, 2025, a hotfix shipped November 22, and the architectural rework rolled out across regions by July 2026, with public disclosure on July 30. No CVE was assigned.

What this actually means if you run Cosmos DB

Take Microsoft at its word that nothing was stolen. The honest developer takeaway isn't "panic" — it's that this bug is the strongest argument yet against how most Cosmos apps still authenticate.

If your application talks to Cosmos DB with a primary or secondary key — the connection-string model in nearly every quickstart — you're using an account-wide, long-lived credential that grants full data-plane access and, historically, has been the exact thing these breaches hand out. CosmosEscape didn't leak your key; it demonstrated that a platform bug can mint it regardless of how carefully you store it. The mitigation you control is to stop relying on that key at all:

• Move to Entra ID data-plane auth. Cosmos DB supports RBAC role assignments for the data plane. Your app authenticates as a managed identity, gets short-lived tokens, and never holds a standing secret.
• Disable key-based auth once you've migrated. Setting disableLocalAuth on the account turns off primary/secondary keys entirely, so a leaked or vended key is inert.
• Rotate keys if you can't migrate yet, and treat the two-key design as intended — rotate one while the other serves traffic.
• Don't lean on network isolation as your last line. It's defense in depth, not a backstop. This attack walked straight through it because the enforcer was the thing that got owned.

Gremlin API users specifically should note their surface was the ignition point here; if you're on graph workloads, prioritize the identity migration.

None of that is a Cosmos-only lesson. The uncomfortable truth under CosmosEscape is that in a shared cloud database, your data's safety depends on the provider's control plane never executing hostile input — a guarantee you can't audit and can't enforce. You can, however, stop issuing yourself a credential that a control-plane bug can hand to someone else. Two Wiz disclosures in five years say that's no longer a paranoid default. It's the baseline.