CosmosEscape: The Azure Cosmos DB Flaw That Handed Over Every Account's Primary Key

The critical Azure Cosmos DB weakness that surfaced this week now has a name — CosmosEscape — and, in the full technical writeup from cloud-security firm Wiz, a sharp answer to the question defenders actually care about: what got exposed. The answer is the single credential that matters most to any Cosmos DB customer — each account's primary key, the long-lived master token that grants full read and write access to every database under that account.

The CyberSignal covered the disclosure as it broke, when the headline detail was the platform-wide "Cosmos Master Key" that reportedly reached across tenants, regions, and API flavors. This follow-up narrows the lens to the customer-side asset — the primary key — because that is the piece defenders can actually act on. Microsoft has already closed the flaw on its side, so there is nothing to patch. The work that remains is credential hygiene, and the disclosure is a good reason to do it now.

What CosmosEscape Actually Exposed

Per Wiz, its researchers began with a crafted query against the Cosmos DB Gremlin graph API, escaped the query sandbox, and gained code execution on the multi-tenant "DB Gateway" that runs customer queries. From there they reached a signing key that turned out not to be scoped to a single account — Wiz reports it worked across tenants, regions, and the SQL, MongoDB, Cassandra, and Gremlin APIs, and could retrieve the primary key for any Cosmos DB account on the service. Wiz dubbed that signing secret the Cosmos Master Key.

SecurityWeek's reporting frames the outcome in the same terms: the flaw "exposed the primary key for Cosmos DB accounts, granting full read and write access." That is the load-bearing fact for a defender. Microsoft's own documentation describes a primary key as a master token over an account's resources — so retrieving one is equivalent to holding the keys to that customer's data. The master-key-to-primary-key chain is what turned a clever sandbox escape into an "any database" problem, and Wiz says it could reach even private, network-isolated accounts because the gateway it compromised is what enforces those network boundaries.

Why the Primary Key Is the Detail That Matters

The following is The CyberSignal's assessment, not new reported fact. Microsoft eliminated the platform-wide Cosmos Master Key as part of its fix, which removes the mechanism CosmosEscape abused. But it does not remove the underlying object that made the flaw so damaging: the primary key itself. Primary keys are long-lived, broadly scoped shared secrets. Unlike a Microsoft Entra ID token, a primary key cannot be narrowed to a single container or operation, cannot be tied to a specific identity, and does not expire on its own. Any application that authenticates to Cosmos DB with a primary key is holding a credential whose blast radius is the entire account.

That is the durable lesson to carry out of CosmosEscape. The provider-layer bug is Microsoft's to fix and, by its account, fixed. The customer-layer exposure — a standing account-wide secret sitting in application configuration, secret stores, and developer laptops — is yours, and it persists whether or not a gateway is ever compromised again. A disclosure like this is a low-cost prompt to shrink that exposure before the next one.

What Defenders Should Do Now

None of this is an emergency response — Microsoft says the path is closed and its log review found no unauthorized activity beyond the researchers' testing. Treat the items below as scheduled hygiene, not incident response:

• Rotate primary keys. Cosmos DB accounts carry primary and secondary keys precisely so you can rotate without downtime: repoint applications to the secondary key, regenerate the primary, then repeat. If you have never exercised that path, this is the week to prove it works.
• Move to Entra ID and role-based access control where you can. Cosmos DB supports Entra ID authentication with RBAC data-plane roles, which replace a standing shared secret with short-lived, identity-scoped tokens that fail closed. Prefer that over key-based auth for any application that can adopt it.
• Inventory where keys live. Find every app, pipeline, and config store that still authenticates with a primary or secondary key, and confirm who and what can read those values.
• Make rotation routine, not a project. If regenerating an account key requires a change window and a war room, that friction is itself a risk. Automate it and schedule it.

That posture mirrors the takeaway from other server-side fixes with no customer patch — Microsoft's quiet remediation of the Copilot flaw researchers named "SearchLeak" called for a configuration-and-audit review rather than a deployment cycle. And the standing risk of long-lived cloud keys is the same one that turned a single leaked file into a federal incident when a contractor left AWS GovCloud admin keys on public GitHub. Scoped, revocable identity beats a broad shared secret every time the platform gives you the choice.

What Is Still Unconfirmed

Several specifics remain open, and this piece is not filling them in. Wiz and SecurityWeek both report that no CVE identifier has been assigned — consistent with a server-side fix that requires no customer action, but worth flagging for teams that track vulnerabilities by CVE. Microsoft states there is no customer action required and that it found no evidence of exploitation beyond the research. The public record does not establish when the vulnerable signing-key path first entered production or what window Microsoft's log review covered, so the duration of any theoretical exposure is unknown even though the path is now closed. Wiz says it will present the complete exploitation chain at a Black Hat USA briefing titled "One Key to Rule Them All," so the fullest technical account is still to come.

Primary Documents

• Wiz Research — CosmosEscape: Taking Over Every Database in Azure Cosmos DB (primary)
• SecurityWeek — Critical Flaw Led to Azure Cosmos DB Pwnage