SURIQ
The most repeated line from this week's Azure Cosmos DB disclosure is that no customer action is required. For the specific flaw Wiz reported, that is accurate. It is also the wrong thing for anyone running production data on a managed cloud database to take away.
On July 30, 2026, Wiz published CosmosEscape, a chain that let an ordinary Azure tenant reach a single key capable of reading and writing every other customer's Cosmos DB account. Microsoft finished removing that key in July 2026, roughly eight months after Wiz first reported it. The gap between those two dates is the part worth your attention.
What CosmosEscape actually reached
The entry point was the Gremlin API, Cosmos DB's graph-query interface. Cosmos compiles Gremlin queries into .NET code inside a sandbox meant to keep a query doing nothing but graph work. Wiz found the sandbox did not account for .NET reflection, and used that to build file read and write primitives and then run arbitrary code. The only setup required was a normal Azure account with a Gremlin database the attacker controlled, which takes minutes to stand up.
That code ran on a multi-tenant database gateway, the shared component sitting in front of every customer account. From there Wiz recovered a signing secret they named the Cosmos Master Key. It was not scoped to one account, one region, or one interface. The same secret returned any customer's account key on request, listed every database on the service filtered by subscription or tenant, and read the Config Store, a registry holding account names, subscription and tenant IDs, network settings, and tags. It worked across the SQL, MongoDB, Cassandra, and Gremlin APIs alike.
Wiz reported that private and network-isolated accounts were in scope too, because the gateway that was compromised is the same component that enforces network isolation, which places code running on it above that control rather than behind it. Microsoft stated it found no evidence any customer data was accessed and that no customer action is required.
The eight-month window nobody is quoting
Wiz reported the chain on November 20, 2025. Within 48 hours Microsoft shipped a hotfix that blocked the vulnerable Gremlin entry point, which shut the specific door Wiz walked through. The platform-wide key behind that door, the thing that actually made the flaw catastrophic, was a deeper architectural problem. According to Wiz's disclosure timeline, Microsoft did not finish removing the Cosmos Master Key across all regions until July 2026.
Read that sequence carefully. The fast hotfix closed one path to the key. For the roughly eight months until the architectural work landed, the key itself still existed as a single secret that could reach every account on the service. Another path to the same gateway, found by someone less cooperative than a disclosure-minded research firm, would have reached the same key. The point is not that Microsoft was slow, because a 48-hour hotfix is fast. It is that a platform-wide bearer credential is a systemic single point of failure that takes far longer to unwind than the bug that first exposes it.
Why "no action required" is not "no lesson"
Everything the attacker would have walked away with is a primary account key. A Cosmos DB primary key is a bearer credential: whoever holds it gets full read and write access, with no second factor and no per-request identity tied to a user or app. That property is exactly what turned one leaked secret into access to the whole service, and it does not change because this particular leak is now closed.
It also inverts the usual detection advice. For a flaw in software you run, the standard move is patch, then hunt for signs you were hit during the exposure window. Here there is nothing on your side to hunt. The compromise would have happened on a shared gateway you have no logs for, using a key issued above your telemetry. You could not have seen it in flight, and you cannot prove after the fact that it did not touch you. When the vulnerable layer is the managed fabric itself, detection is not a lever a tenant holds. Blast-radius reduction is the only one. This is the same theme we flagged in an Azure login path that slipped past MFA: the surprises tend to live in how identity and keys are handled in the layer you do not run.
There is a quieter gap on top of that. No CVE was assigned, which is normal for a cloud flaw fixed entirely on the provider side. It means nothing in a scanner, the CISA KEV catalog, or a vulnerability-management queue would ever have listed this. The tooling defenders rely on to know what to worry about does not watch the managed layer at all, so a flaw there can be found, fixed, and disclosed without ever passing through your patch pipeline.
What to change on your own Cosmos DB accounts
You cannot patch the fabric, but you can decide how much a stolen key is worth. Concrete steps, in order:
-
Turn key-based authentication off where your API supports it. The NoSQL API can disable local auth entirely and require Microsoft Entra ID with role-based access, so a stolen primary key is simply refused. The MongoDB, Cassandra, Gremlin, and Table APIs still depend on shared keys for data-plane access today, so an account on one of those had no mechanism to reject the Cosmos Master Key even in principle. If your sensitive data sits on one of them, that is a real argument for planning a move to the NoSQL API, or for accepting that the key is your entire security boundary.
-
Rotate your account keys. Microsoft reports no impact, and rotation cannot undo a past read. But keys are long-lived bearer credentials, and rotating them is cheap. Do it, and put it on a schedule instead of treating it as a one-time reaction to this story.
-
Segment so a single key is survivable. Separate accounts per trust boundary, least data per account, and scoped roles mean one compromised key exposes a slice rather than everything. This is the only control that would have limited the damage in a scenario where the fabric itself was turned against you.
-
Do not treat private endpoints as isolation from the provider. They isolate you from the public network, which is worth having. They also route through the same gateway CosmosEscape compromised, so they are not a boundary against a flaw in that gateway. Value them for what they defend against, not for what they cannot.
The managed-service bargain
This is the second time Wiz has pulled a cross-tenant break out of Azure Cosmos DB. In 2021, their ChaosDB research reached other customers' accounts through the Jupyter notebook feature that had been added to the data plane. CosmosEscape came through the Gremlin graph engine. Different feature, same shape: a rich compute capability bolted onto a shared data service becomes the path off the tenant boundary and into the fabric everyone shares. It is the same failure mode as a read-only role that let one tenant reach another's workloads, just one layer deeper, in the provider's own plumbing.
The trade you make with a managed database is real and usually worth it. You hand the provider operational control and get their scale and patch speed back. What you also inherit is their blast radius. CosmosEscape is a reminder to build for that: assume the key can leak and the fabric can fail, and make sure that when it does, you lose a room and not the building. That is the customer action, whatever the advisory says.