Wiz Research has disclosed CosmosEscape, a vulnerability chain in Azure Cosmos DB that yielded read and write access to every database on the service. Microsoft has completed remediation, and no customer action is required. The disclosure matters less for the flaw itself than for what it reveals about how long removing a global secret from a live multi-tenant system takes, and about how little customers can do while that happens.

The chain began with a crafted query against a Gremlin database the researcher controlled. Cosmos DB compiled Gremlin queries into .NET code under restrictions meant to keep them within Gremlin operations, but those restrictions did not sufficiently account for .NET reflection. Escaping the sandbox gave code execution on the DB Gateway, the multi-tenant service that processes customer queries, which in turn exposed what Wiz calls the Cosmos Master Key: a platform-wide secret that could retrieve the primary key of any Cosmos DB account and enumerate databases filtered by subscription and tenant identifiers. The blast radius extended to Microsoft's own backends, since Cosmos DB underpins services including Teams and Copilot.

CosmosEscape attack chain (Source: Wiz Research)

On Hacker News, commenter gtowey reacted to the reflection detail:

Wow, this is so unbelievably amateurish.

Wiz reported the issue on November 20, 2025, and Microsoft acknowledged it the same day, blocking the vulnerable Gremlin entry point with a hotfix two days later. Removing the platform-wide key took until July 2026, when Microsoft finished rolling out a new credential model across all regions.

Practitioner reaction split along several lines, none of them about the exploit itself. On Reddit, commenter TerrificAbsence captured what made the chain unsettling, calling it a brutal escalation and pointing to its economy:

RCE via a Gremlin query to full tenant key compromise is a brutal escalation chain and it's the simplicity that's like super scary because one query, no exotic tooling and straight to the master key

The first debate concerned the shared responsibility model. Commenter ConsequenceLast6569 stated:

This is the kind of vulnerability that doesn't show up in any shared responsibility model diagram. As a Cosmos DB customer, there is nothing we could have done differently to prevent this; it lives entirely in Microsoft's infrastructure

Commenter godofpumpkins reframed that, asking whether the absence of any customer-side mitigation places the flaw, by definition:

…squarely on the provider side of a shared responsibility model diagram

That exchange is the useful one. The model allocates the platform to the provider, so a break in tenant isolation falls precisely on the provider's half. What unsettles people is the corollary: the fix arrives invisibly, and customers must take the provider's word that it worked. Commenter dointheatl put that doubt directly in the HN thread:

Rejecting the premise: who says they fixed it properly?

The second debate concerned the six-month interval. Complaints that remediation moved slowly drew substantive pushback separating the hotfix from the rearchitecture. Commenter phatskat noted that the gateway had used the master key to fetch each account's private key before forwarding requests, so removing it meant rebuilding the credential model of a service Microsoft itself depends on. Another commenter, delfinom, made the same point about scale:

It's a major service for themselves and tens of thousands of customers; you don't vibe code yourself a new database query execution engine overnight.

A third thread revisited concentration risk. Commenter WantDebianThanks described years of unsuccessful arguments for backing up critical data to a second provider or on-premises. Commenter maceinjar countered that hypervisor code bases are no less buggy and that most organizations patch them worse than a hyperscaler would, while conceding the asymmetry:

The problem is, when it goes wrong, it really goes wrong with the hyperscalers.

Commenter LLMsMustUpvoteThis then narrowed the comparison further, noting that a typical on-premises estate does not expose its management APIs to the internet or carry cross-tenant pivot risk:

It's a different threat model though.

Three things the public record does not contain:

• No CVE identifier and no CVSS score, which is unusual for a finding described as critical.
• No MSRC advisory, unlike ChaosDB in 2021 and CosMiss in 2022 in the same service, leaving Microsoft's position in statements given to Wiz and to reporters.
• No stated exposure window, since neither Wiz nor Microsoft says when the vulnerable engine and signing-key path entered production, or what period the access-log review covered. The assurance of no evidence of customer impact therefore has an undefined denominator.

For platform teams, the practical takeaway is not a patch to apply but a question to ask of any managed multi-tenant service: where does the platform hold a credential that spans tenants, and what would removing it cost? Microsoft's answer in this case was six months of rearchitecture behind a two-day block. The full exploitation chain is scheduled for presentation at Black Hat USA.