One Key Could Read Every Database in Azure Cosmos DB. Blocking the Way In Took 48 Hours. Removing the Key Took Eight Months.
- Patrick Duggan
- 2 hours ago
- 5 min read
Wiz Research published CosmosEscape this week — tracked as CVE-2026-66803. Starting from an ordinary Azure Cosmos DB account, the chain reaches a single platform-wide signing key capable of reading or overwriting data in every customer database on the service.
Microsoft has fixed it and says it found no evidence of customer impact. The interesting part is not the exploit. It is the two timelines sitting inside the remediation.
The chain, briefly
Cosmos DB's Gremlin API runs a custom graph-query engine that compiles queries into .NET and executes them in a sandbox. The engine did not sufficiently account for .NET reflection, and reflection is a general-purpose escape hatch — given it, you can assemble arbitrary code execution out of parts the sandbox considers legitimate.
So: a crafted Gremlin query against a graph database the attacker owns, executed on a multi-tenant gateway, yields code execution on that gateway. From there the researchers recovered a platform-wide signing secret and a regional account directory. The directory tells you where a target lives; the signing secret mints access to it. Together they produce the primary account key of any Cosmos DB account on the service, and a primary account key is full read and write.
Worth naming what sits in Cosmos DB, because it is not only customer workloads. Microsoft uses it to store data behind Entra ID, Teams, and Copilot.
Credit where it belongs: this is Wiz's research, disclosed to Microsoft and published by Wiz. We had no part in it and hold no indicators from it.
The two clocks
Wiz reported it in November 2025. Microsoft blocked the vulnerable Gremlin entry point within 48 hours. The longer-term fix — completed across all regions and eliminating the platform-wide key — landed in July 2026.
Both of those numbers are worth taking seriously, and most coverage will only quote one of them.
Forty-eight hours to close the door is genuinely fast for a service of this size, and it is the number that matters for exposure: from that point, the published path in was shut.
Eight months to remove the key is the number that matters for architecture. Because the door was never really the bug.
The key was the bug
A sandbox escape in a query engine is a defect. Defects happen; you patch them. But the escape only became a cross-tenant catastrophe because there was a single platform-wide signing secret, reachable from a multi-tenant gateway, that could produce credentials for every account on the service.
That is a design property, not a coding error, and it is why the second fix took eight months and the first took two days. Blocking one Gremlin entry point is a patch. Removing the master key means re-architecting how the service authenticates itself to itself, region by region, without breaking anything running on it. Microsoft did that, and finishing it is the substantive part of this disclosure.
The generalisable lesson for anyone building multi-tenant anything: the blast radius of a sandbox escape is decided long before the escape, by whether there is something worth reaching on the other side. Every remaining platform-wide credential in your estate is a bet that no sandbox in front of it will ever fail. Reflection in a .NET sandbox is not an exotic bet to lose.
"No evidence of customer impact"
This is the sentence to think carefully about, and we want to be fair to Microsoft while doing it.
It is very likely true, and it is not the same sentence as "no customer was impacted."
Ask what evidence of impact would look like. The abuse path here is a legitimately-signed credential. A request authenticated with a valid primary account key, arriving at the correct regional endpoint for that account, is not anomalous — it is the normal operation of the service. There is no malformed packet, no failed auth, no privilege escalation event, no signature mismatch. It is indistinguishable from the customer's own traffic unless you can tell that this particular valid key was minted by something that had no business minting it.
So "no evidence" is a statement about detection capability as much as about attacker behaviour, and Microsoft is the only party positioned to say even that much. Customers cannot check this themselves. There is no log on your side that distinguishes your key being used by you from your key being used by someone who derived it, which is precisely the property that makes a platform-wide signing key a bad thing to have.
We are not suggesting anyone was compromised. We have no reason to think so, and Wiz reported this privately rather than dropping it. We are saying that "no evidence of impact" is a weaker claim than it reads as, that the weakness is structural rather than anyone's fault, and that a defender should file it as unknown and unknowable from my side rather than as cleared. If you want the stronger version of this argument in our own words, it is the same one we make about our own metrics: absence of a finding is only meaningful if you can say what a finding would have looked like.
What a Cosmos DB customer should actually do
Nothing urgent, and we would rather say that plainly than manufacture an action list. The entry point has been closed since November 2025 and the underlying key is gone as of this month. There is no patch for you to apply; this was fixed underneath you, which is the deal you bought.
Two things are still worth doing this week, because they are cheap and this is a good prompt for them:
Rotate your Cosmos DB primary keys if you have never rotated them, and set a cadence. Not because we think yours leaked, but because an account key that has never changed is a credential whose exposure window is its entire lifetime, and this disclosure is a reasonable moment to shorten it.
Move off account keys where you can. Entra ID authentication with role-based access control replaces a long-lived bearer secret with identity-scoped, revocable, auditable access. That change would not have prevented CosmosEscape, and we are not going to claim it would. What it does is make the next one survivable, and it converts "your key is valid, therefore this request is you" into a question your logs can actually answer.
The honest position
We did not find this, we are not ahead of it, and our feed holds nothing on it. Wiz found it, Microsoft fixed it, and both handled it in a way that deserves saying out loud.
What we are adding is the reading of the two clocks — that 48 hours and eight months are measuring different things, that the second number is the one describing the actual defect, and that the difference between them is where the architectural lesson lives. Plus one honest caveat about a reassuring sentence that is doing less work than it appears to.
Confidence capped at 95%. The technical chain, disclosure date, and remediation timeline are from Wiz's published research and Microsoft's statements; we have not reproduced any of it and have no independent visibility into Cosmos DB's internals or Microsoft's telemetry.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.