CosmosEscape: The Azure Cosmos DB Vulnerability That Could Have Unlocked Every Database on the Platform

Three headline options for reference (best marked ★):

1. ★ CosmosEscape: Azure Cosmos DB Flaw Exposed a Master Key
2. Azure Cosmos DB Vulnerability Could Access Any Database
3. Inside CosmosEscape: Microsoft’s Cosmos DB Master Key Flaw

For about eight months, a single cryptographic key sat behind a vulnerability chain that, if exploited maliciously, could have handed an attacker read and write access to any Azure Cosmos DB database on the planet, including ones belonging to Microsoft Teams, Microsoft Entra ID, and Microsoft Copilot. That’s the core of CosmosEscape, an Azure Cosmos DB vulnerability disclosed by Wiz Research on July 30, 2026. Nobody appears to have exploited it. But the mechanics of how close it came are worth every security team’s attention, whether or not you run a single line of Cosmos DB code.

What Actually Happened

Picture a bank vault where one master key opens every safe deposit box in every branch, not just the one belonging to the customer standing at the counter. That’s roughly the design flaw Wiz researchers Yuval Avrahami and Lior Maman found inside Azure Cosmos DB’s Gremlin API. They call it CosmosEscape, and according to Wiz’s own technical writeup, the chain could have granted two capabilities to an attacker: pulling the primary access key for any Cosmos DB account on demand, and enumerating every database on the service, filterable by subscription and tenant ID.

The scope is what makes this different from a typical cloud bug bounty writeup. Cosmos DB isn’t a niche product. Microsoft’s own internal services, including Entra ID, Teams, and Copilot, store data in it. If CosmosEscape had been found and used by someone other than a Wiz researcher operating under responsible disclosure, the practical blast radius would have extended well past any single customer’s environment.

How the Exploit Chain Worked

Cosmos DB runs a custom Gremlin engine that translates graph queries into .NET code behind the scenes. Wiz’s researchers noticed the sandbox restrictions around that engine didn’t fully account for .NET reflection, a language feature that lets code inspect and manipulate itself at runtime. That gap let them build, step by step, a file read primitive, then a file write primitive, then full arbitrary code execution inside the query environment.

From there, the execution landed on Microsoft’s DB Gateway, the service responsible for running customer queries across Cosmos DB’s multi-tenant Service Fabric clusters. That gateway held a signing key that wasn’t scoped to a single customer account. It worked across tenants, regions, and every API flavor Cosmos DB offers: SQL, MongoDB, Cassandra, and Gremlin.

“Multi-tenant cloud services require at least one strong isolation boundary around tenant-controlled execution.” Yuval Avrahami and Lior Maman, Security Researchers, Wiz Research · Wiz Research blog, July 30, 2026

Everything inside that boundary, the researchers argue, has to be treated as untrusted, even when it’s running on infrastructure the customer never sees. CosmosEscape is essentially proof of what happens when a shared-infrastructure component quietly becomes that missing boundary.

The Disclosure Timeline

Wiz followed a standard coordinated disclosure process, and the gap between “reported” and “fully fixed” is one of the more interesting data points in this story.

• November 20, 2025: Wiz reports the vulnerability to Microsoft. Microsoft acknowledges the same day.
• November 22, 2025: Microsoft deploys an emergency hotfix blocking the vulnerable Gremlin entry point, roughly 48 hours after the initial report, and begins work on a permanent architectural fix.
• July 2026: Microsoft finishes rolling out the long-term fix across all regions, eliminating the platform-wide key entirely.
• July 30, 2026: Public disclosure, coordinated between Wiz and Microsoft.

The Hacker News independently confirmed the same cadence: the entry point blocked within 48 hours, the full architectural fix landing across all regions roughly eight months later. That eight-month gap between hotfix and true closure is worth sitting with. A patched entry point isn’t the same thing as a rebuilt trust boundary, and for eight months, the underlying signing-key architecture that made CosmosEscape possible in the first place was still there, just harder to reach through the original path.

CosmosEscape vs. ChaosDB vs. CosMiss

This is the third publicly disclosed tenant-isolation failure tied to Cosmos DB since 2021. They’re technically unrelated, but the pattern is hard to ignore.

No CVE identifier or CVSS score has been published for CosmosEscape as of this writing, which is unusual for a vulnerability described in these terms. Prior Cosmos DB isolation failures, including ChaosDB, carried CVE tracking. Its absence here means CosmosEscape won’t automatically surface in standard vulnerability scanning or CVE-feed workflows, so compliance teams doing SOC 2 or ISO 27001 vendor risk reviews will need to document this one by hand.

What Microsoft Says, and What It Doesn’t

Microsoft’s position, published as part of Wiz’s coordinated disclosure, is that the issue is closed and no customers were harmed.

“No evidence of unauthorized activity outside of the researcher’s testing activity.” Microsoft, official statement via coordinated vulnerability disclosure · published on the Wiz Research blog, July 30, 2026

Microsoft says it reviewed access logs, found no customer data was touched, added service-to-service authentication hardening, and states no customer action is required. Fair enough, and there’s no public evidence contradicting that account. But a few things aren’t in the public record yet. Microsoft hasn’t stated how far back its log review actually reached, or when the vulnerable Gremlin engine and signing-key architecture first went into production. The Hacker News says it asked Microsoft and Wiz directly for that clarification and hadn’t received an answer at publication time. That’s not an accusation. It’s just a gap between “we found nothing” and “we know the full window this was exploitable,” and the two aren’t the same claim.

For a second data point on how researchers think about Azure’s multi-tenant history, look back to 2021’s Azurescape, a different vulnerability entirely, in Azure Container Instances rather than Cosmos DB.

“This is the first time that a complete takeover of a public cloud system has been demonstrated.” Ariel Zelivansky, Cloud Research Team Lead, Palo Alto Networks Unit 42 · commenting on Azurescape (2021), via Dark Reading. Not a statement about CosmosEscape.

Zelivansky’s quote is included here strictly as historical context. It’s not about CosmosEscape, and it shouldn’t be read as one. What it does establish is that Azure’s multi-tenant isolation boundary has been the subject of researcher scrutiny for years, across more than one product line.

On the more critical side, Corey Quinn, Chief Cloud Economist at The Duckbill Group, has written for years about Azure’s recurring tenant-isolation failures, ChaosDB, Azurescape, and the OMI vulnerability among them, arguing they reflect a pattern rather than isolated bugs. Quinn hasn’t commented publicly on CosmosEscape specifically as of this article’s publication, so his view here is a paraphrase of his documented general position, not a quote about this incident. It’s a fair question the industry hasn’t fully answered: is this an architectural pattern at Microsoft, or is it simply that Wiz keeps finding these things because Wiz is good at finding these things? Probably some of both.

What Security Teams Should Actually Do

If you’re running Cosmos DB workloads, here’s the honest answer: there’s no patch to apply, because Microsoft already applied it for you. That’s the nature of a platform-level fix. But “nothing to patch” isn’t the same as “nothing to do.”

• Document the disclosure manually. Because there’s no CVE, it won’t appear in automated vendor-risk or CVE-tracking tooling. Add it to your vendor risk file yourself.
• Consider a retrospective log review for sensitive Cosmos DB workloads that were active between November 2025 and July 2026, particularly if you handle regulated data, even though Microsoft’s own review found nothing.
• Revisit your multi-cloud risk model. Wiz’s finding that private, network-isolated accounts were still reachable is a reminder that customer-side controls like VNets and firewall rules can’t fully compensate for a platform-level trust boundary failure.
• Watch the Black Hat talk. Wiz will present the full exploitation chain at Black Hat USA on August 6, 2026, titled “One Key to Rule Them All: Taking Over a Flagship Cloud Service.” That’s where the deeper technical detail, including proof-of-concept specifics likely held back from the initial blog post, will surface.

There’s a broader angle here too. Wiz says an early version of its own AI vulnerability researcher, Atlas, assisted in the CosmosEscape investigation. Wiz’s 2026 Cloud Threats Retrospective found that roughly 80% of documented 2025 cloud intrusions traced back to known weaknesses, exposed secrets, and misconfigurations, not novel attack techniques. If AI tooling is now finding sandbox-escape chains like this one faster than isolation architectures are getting rebuilt, that gap is the story to watch through the rest of 2026, not just this single disclosure.

Frequently Asked Questions

Where This Goes Next

Here’s what’s actually new after CosmosEscape: the entry point changes each time (notebooks in 2021, Gremlin in 2026), but the underlying failure mode doesn’t. A shared-infrastructure component ends up with reach across tenant boundaries, and a well-resourced research team finds it before anyone with worse intentions does. That’s a reassuring pattern until the year it isn’t.

Three things worth watching over the next six to eighteen months. First, whether Wiz’s Black Hat talk on August 6 reveals proof-of-concept detail that changes the risk calculus. Second, whether Microsoft or an independent party ever publishes the actual exposure window, since that question remains open. Third, whether other hyperscalers face their own version of this story: AI-assisted vulnerability research is getting faster, and Cosmos DB is unlikely to be the last multi-tenant service where it finds something.

Our read: this isn’t a five-alarm fire for anyone running Cosmos DB today. The fix is real and it’s deployed. But treat the “no CVE, no action needed” framing as the floor of what you should do, not the ceiling. A retrospective log review costs you an afternoon. Skipping it costs you the ability to say, with confidence, that you checked.