One Key, Every Database
When I picked this up I thought, "surely this is a mock-up of the older 2021 disclosure on ChaosDB...?"
I was wrong, and below is my best research-put into a new topic that has the breath of life reviving it's 5 year old predecessor.
A researcher found a master key to all of Azure Cosmos DB. Then a second researcher added one line that nobody can verify, and that line is the reason the story travelled.
On 30 July, the cloud security firm Wiz published research describing something that should not be able to exist.
A single cryptographic key, held inside Microsoft's own infrastructure, that could retrieve the credentials of any Azure Cosmos DB account. Not one customer's. Not one region's. Any account, in any tenant, in any region, across every API the service supports.
Wiz named it the Cosmos Master Key. The vulnerability that reached it, they called CosmosEscape.
Microsoft has fixed it. No customer needs to do anything. That is genuinely the end of the operational story, and if you run Cosmos DB you can stop reading with a clear conscience.
The interesting part is what happened next, on Mastodon, about eighteen hours after publication.
What Wiz actually found
Cosmos DB is Microsoft's flagship distributed database. It runs a large amount of Azure, and it runs a large amount of Microsoft: Entra ID, Teams, and Copilot are all documented as sitting on it.
One of the query languages it supports is Gremlin, used for graph databases. When Wiz researchers ran Gremlin queries against their own account, they noticed something odd: a .NET exception in an error message. That told them Microsoft compiles Gremlin queries into .NET code and runs them inside a restricted sandbox.
Sandboxes are only as good as the things they remember to block. This one had not accounted for .NET reflection, a language feature that lets code inspect and manipulate other code at runtime. Wiz used it to build a file read, then a file write, then arbitrary code execution. They demonstrated it by running the hostname command on Microsoft's backend through a database query.
That put them on the DB Gateway: a shared, multi-tenant component that executes customer queries. Because it serves every customer, it needs to reach every customer's database, and it does that using each account's primary key. It obtains those keys using a signing key held on the cluster.
Wiz checked whether that signing key was scoped to their account.
It was not. It was not scoped to anything.
They also found the Config Store, a regional registry listing every Cosmos DB account with its subscription and tenant identifiers and network settings. The Config Store is itself a Cosmos DB database, which meant it could be queried with the full flexibility of the SQL engine.
So the chain was: query the Config Store to find a target, use the master key to pull its primary key, read and write at will. All from a standard Azure account with a Gremlin database on it, which takes a few minutes to create. No insider access, no prior foothold, no special permissions.
There was nothing a customer could have configured to prevent it, including network isolation, because the DB Gateway is the component that enforces network isolation.
Microsoft's response, and the gap in it
The disclosure timeline is a good one and worth saying so.
Wiz reported it on 20 November 2025. Microsoft acknowledged it the same day and shipped a hotfix blocking the Gremlin entry point within 48 hours. It then spent until July 2026 on the architectural fix that eliminated the platform-wide key entirely, added stronger service-to-service authentication, and put monitoring in place. Wiz published only after that work completed. Both parties describe the process as functioning well.
Microsoft says it reviewed access logs, found no evidence of unauthorised activity beyond Wiz's own testing, and that no customer data was accessed.
Here is the gap, and it is the only thing about Microsoft's handling I would push on.
"No evidence of exploitation" is bounded by the period reviewed, and Microsoft has not said when the vulnerable Gremlin engine and the unscoped signing key entered production. Without that date, nobody outside Microsoft can say whether the exposure window was months or years. The reassurance is real. Its scope is unstated.
There is also no CVE and no CVSS score, which is normal for cloud vulnerabilities and not a criticism, but it does mean there is no independent severity rating to point at. Every characterisation of how bad this was comes from either Wiz or Microsoft.
This is not ChaosDB
A lot of people will see "Wiz", "Cosmos DB" and "master key" and file this as the 2021 story coming round again. It is not, and the distinction matters.
ChaosDB, August 2021, also Wiz. It abused the Jupyter Notebook feature, which was enabled by default on new accounts from February 2021, to escalate into other customers' notebooks and harvest their primary keys. Microsoft confirmed several thousand customers were affected, notified roughly 30% of Cosmos DB customers, and Wiz recommended every customer regenerate their keys regardless. Microsoft paid a $40,000 bounty.
CosMiss, 2022, also Wiz, also the Notebook feature. A separate authentication flaw.
CosmosEscape, 2026. Gremlin engine, sandbox escape, platform-wide signing key. Nothing to do with notebooks. No customer action required, because the fix was entirely server-side.
Same firm, same service, entirely different attack path. Both Wiz and Microsoft state plainly that the findings are technically distinct.
What that sequence does tell you is that Cosmos DB has now produced two critical cross-tenant failures five years apart, and Wiz has a documented run of these: ChaosDB in 2021, ExtraReplica against Azure PostgreSQL in 2022, CosMiss in 2022, BingBang against Azure AD app configuration in 2023. Multi-tenant isolation is where cloud keeps breaking, and the same firm keeps being the one to say so.
The line that made it travel
Will Dormann, a well-known vulnerability analyst formerly of CERT/CC, posted the finding with a pointed addendum: think about why such a key exists at all. Fair question, well put, and entirely supported by what Wiz published.
Kevin Beaumont then quote-posted it and added one sentence:
All the customer Microsoft Defender for Endpoint telemetry is in CosmoDB.
If that is true, the story changes completely. Defender for Endpoint is the sensor layer inside a very large number of corporate networks. It is what security teams query when they are working out whether they have been broken into. A master key over that data would mean an attacker could read the defenders' own detection telemetry, and with write access, potentially alter it.
That is a materially worse story than the one Wiz told, and it is the version that spread.
I went looking for the documentation. Here is what I found, and here is what I did not.
Documented: Microsoft Teams message data is stored in Cosmos DB. Microsoft's own eDiscovery documentation states it plainly. Copilot conversation history is in Cosmos DB, per Microsoft's own engineering blog. Wiz cites Entra ID, Teams and Copilot as Cosmos DB-backed.
Not documented: Defender for Endpoint. Everything public points the other way. MDE's advanced hunting runs on Kusto Query Language, and Microsoft explicitly lists Defender among the services built on Azure Data Explorer, which is the Kusto engine. The only place Microsoft's documentation puts Defender and Cosmos DB in the same sentence is Microsoft Defender for Azure Cosmos DB, which is a threat protection product that guards customers' own Cosmos DB accounts. That is a different thing entirely, and it is an easy conflation to make.
So the claim is not publicly verifiable, and the available evidence points elsewhere.
What I am not saying
I am not saying Beaumont is wrong.
He worked at Microsoft. He may know something about how MDE telemetry is stored that has never been published, and the absence of public documentation is not proof of anything. Microsoft does not document its internal data architecture comprehensively, and plenty of true things about it are not on Microsoft Learn.
What I can say is narrower, and it is the only thing the evidence supports: the claim cannot currently be verified from public sources, the public sources that do exist point at Kusto rather than Cosmos DB, and nobody outside Microsoft can presently resolve it.
That distinction is not pedantry. Promoting "no public evidence" into "false" is the same error as promoting "sounds right" into "true", just pointed the other way. If I published a correction here I would be doing the exact thing I am writing about.
Why this is the story
Look at the shape of what happened over eighteen hours.
Wiz published a real, serious, fully remediated vulnerability with a complete technical account and a functioning disclosure timeline. Dormann amplified it accurately with a good question attached. Beaumont added one unverified sentence that made the implications enormous.
Nothing dishonest occurred anywhere in that chain. Beaumont was not inflating a story for engagement; he is not that kind of account, and the sentence reads exactly like someone recalling a fact rather than inventing one.
But the unverified sentence is the one that gave the story its weight. And this is the recurring problem with technical claims moving through social platforms: the detail that makes something land hardest is often the one detail with the least documentation behind it, because verified facts have been through a process that files their edges off, and half-remembered ones have not.
I have watched the same construction four times in the last week: a true core, an unverified addition, and the addition doing all the work of propagation. Usually the addition is careless. This time it came from someone with real standing and it may well be correct.
Which makes it the better example, not the worse one. If the pattern only showed up in low-quality accounts it would be easy to filter. It does not.
What would settle it
Two things, and neither requires anyone to be embarrassed.
Microsoft could state when the vulnerable architecture entered production. That converts "no evidence of exploitation" from a reassurance into a measurement, and customers could then judge their own exposure rather than accepting a period of unstated length.
And someone could establish, one way or the other, whether Defender for Endpoint telemetry ever touched Cosmos DB. If it did, the CosmosEscape story is considerably larger than currently reported. If it did not, a widely shared claim quietly stops circulating.
Wiz presents this research at Black Hat USA on 6 August, and has said there are further details to come. That may answer the first question. The second one sits with Microsoft.
Primary sources: Wiz Research, "CosmosEscape: Taking Over Every Database in Azure Cosmos DB", 30 July 2026. Microsoft's vendor statement as published in that disclosure. Microsoft Learn documentation on Teams eDiscovery, advanced hunting, and Azure Data Explorer. Wiz, "ChaosDB", August 2021.
Clayton Bax Published under ONYX Digital Intelligence Following the #OnyxAudit methodology. x: @onyxaudit Email: onyxdigitalintelligence85@protonmail.com
"Adjacent to true is not true. The side of truth doesn't have a flag, only a standard."