Picture one clever trick that could crack open millions of locked rooms at the same time. That’s roughly what a team of security researchers stumbled into inside Azure Cosmos DB, one of Microsoft’s flagship cloud databases. Nothing bad actually happened with it — but it very easily could have, and that’s exactly why the story is worth telling.
| The quick version:
Researchers found a way to break out of Cosmos DB’s query sandbox and reach a single secret key that could unlock any customer’s database on the entire platform. Microsoft patched it before anyone else found it. No data was taken. Here’s how it happened. |
So, What Exactly Is Cosmos DB?
Think of Cosmos DB as a massive self-storage facility that Microsoft rents out to thousands of businesses. Every customer gets their own private unit for their data, and — this is the whole point of the system — nobody’s supposed to be able to wander into someone else’s unit.
Here’s the part that makes this story bigger than “one company’s bug,” though: Microsoft doesn’t just rent this storage out to others. It uses Cosmos DB for itself, too. Pieces of Microsoft Teams, Microsoft Copilot, and Entra ID (the identity system behind a lot of Microsoft sign-ins) all lean on it behind the scenes. So a weak spot here isn’t just a customer problem. It’s a foundation problem, and foundations tend to hold up everything built on top of them.
How Researchers Stumbled Onto the Problem
The team behind the discovery works at Wiz, a cybersecurity research outfit that’s made a habit of poking at cloud platforms most of us just trust blindly. They started simply: sending a specially worded request, written in a query language called Gremlin, into a database they owned. Nothing sneaky yet — just their own account, their own data.
Normally, Cosmos DB handles a request like that inside a sandbox — a contained little bubble built so code can run without ever touching anything outside its own lane.
What tipped researchers off was almost an accident. They noticed an error message that didn’t quite look right for Gremlin — not the behavior you’d expect from the standard, well-worn version of that engine everyone else uses. That small oddity was the clue: Microsoft had quietly built its own custom version instead. And custom-built systems, however carefully engineered, sometimes carry blind spots that older, battle-tested tools already had ironed out years ago.
Pulling on that thread, the researchers found an actual gap in the sandbox’s wall. A clever bit of coding later, they were out completely — free to read and write files on Microsoft’s real backend systems. One more detail worth knowing: Wiz says this research was partly assisted by an early, internal version of their own AI vulnerability-research tool, nicknamed Atlas.
Figure 1 — the four-step chain that turned one query into full database access.
From a Tiny Gap to a Master Key for Everything
This is where it stops being a curiosity and starts being a genuine problem. Once the researchers were out of the sandbox, they landed on a shared piece of Microsoft’s infrastructure — something that processes requests for a huge number of customers at once, not just one account. Researchers nicknamed this shared piece the “DB Gateway.”
And sitting right there on that shared system was something enormous: a secret key capable of unlocking the private key of any customer’s account, anywhere on the platform. They called it the Cosmos Master Key.
“It’s like finding a master key in a hotel that opens every single room — not just the one you booked.”
Except here, the “hotel” isn’t one building. It stretches across every region Microsoft operates in, and every flavor of database Cosmos DB supports — SQL, MongoDB, Cassandra, Gremlin, all of it.
Figure 2 — one platform-wide secret, reachable across every tenant, region, and API.
With that master key in hand, there were two very different but equally powerful moves available:
- Takeover — pull the primary access key for any Cosmos DB account on demand, which hands over full read-and-write control instantly.
- Enumeration — search a built-in directory of every database on the service, filtering by subscription or tenant ID, to zero in on one specific company.
Even accounts that were locked down with extra network isolation weren’t safe from this, because the trick operated from inside Microsoft’s own infrastructure — quietly sidestepping the very walls those settings were supposed to guarantee. The researchers also had write access to that directory, which raises an uncomfortable possibility: that network settings themselves could have been altered. To be clear, they say they never actually tried that against a real target — they just noticed the door wasn’t locked.
Could This Have Touched Your Data?
Given that Teams messages and Copilot conversations both live in Cosmos DB, the honest answer is: theoretically, yes. Because Microsoft’s own internal services share the same infrastructure as everyday customer accounts, a flaw at this level opens the door to what researchers call a cross-service attack — one weak point rippling sideways into a whole lineup of products at once.
But — and this matters — the researchers say they never opened, read, or touched anyone else’s real data. Every test ran against their own accounts, purely to prove the door actually opened.
What Did Microsoft Actually Do?
To Microsoft’s credit, the response was fast. Wiz reported the issue on November 20, 2025, and Microsoft acknowledged it that same day.
- Within 48 hours (November 22, 2025), Microsoft blocked the specific entry point that allowed the sandbox escape.
- By July 2026, Microsoft had rolled out a full fix across every region and retired the master key completely, along with new architectural safeguards. The vulnerability itself was only made public on July 30, 2026, once that fix was fully in place.
Worth noting: that fast 48-hour patch only closed the one door the researchers walked through — it didn’t remove the master key itself or rebuild how the gateway handled credentials underneath. That deeper, structural fix is the one that took the following months.
Figure 3 — the timeline from disclosure to full remediation.
Microsoft says its internal review turned up no unauthorized activity beyond the researchers’ own testing, and no customer data was ever accessed. In its official statement, Microsoft said it appreciated the opportunity to investigate the findings Wiz reported through coordinated disclosure — and for its part, Wiz publicly thanked Microsoft’s security response and Cosmos DB teams for their collaboration in fixing it. For everyday customers, there’s genuinely nothing to do here — no keys to rotate, no settings to change.
What’s Still a Little Fuzzy
A few loose threads remain, and it’s worth being upfront about them rather than pretending the story is fully closed:
- Nobody’s said publicly how long this weakness existed in production before Wiz found it.
- The exact crafted query that triggered the whole chain hasn’t been published yet — Wiz is saving that for a Black Hat USA talk titled “One Key to Rule Them All: Taking Over a Flagship Cloud Service,” scheduled for August 6, 2026.
- There’s no CVE number or severity score attached to this one, at least not yet.
This Isn’t Cosmos DB’s First Rodeo
If this all sounds a little familiar, that’s because it is. Back in August 2021, the same research team at Wiz disclosed a different flaw nicknamed ChaosDB — also full admin access to other customers’ databases, but that time through Cosmos DB’s Jupyter Notebook feature. It was serious enough that Microsoft ended up directly notifying more than 30% of its Cosmos DB customer base. A related issue, CosMiss, turned up again in 2022.
CosmosEscape is a genuinely different bug, though. ChaosDB exploited something customer-facing. CosmosEscape reached deeper, into the shared control-plane infrastructure running underneath every account — the kind of thing no customer setting could ever have prevented on their own.
Why This Actually Matters
Zoom out, and the real lesson here isn’t about one company’s mistake. It’s about what happens when millions of customers share the same cloud “building.” A single hidden flaw in the shared plumbing can turn into everyone’s problem at once, which is exactly why independent researchers keep leaning on these systems, looking for cracks before someone with worse intentions finds them first.
The reassuring part is how this one ended: found by the good guys, reported responsibly, and closed quietly before it ever became a headline about stolen data. The less reassuring part is the reminder underneath it — even the biggest, most trusted cloud platforms are built in layers, and a weakness deep in the foundation can quietly threaten everything stacked on top of it.