Some vulnerability disclosures describe a door that was left unlocked. CosmosEscape describes a master key to every room in the building, sitting in a drawer that turned out to be reachable from outside. Wiz researchers found a weakness in the custom Gremlin query engine underneath Azure Cosmos DB, where the engine’s sandboxing did not adequately block .NET reflection techniques. A crafted Gremlin query against a database the researchers controlled achieved code execution on Cosmos DB’s shared, multi-tenant gateway, the layer that sits in front of every customer’s database on the service.
What a platform-wide key actually means
From that foothold, Wiz extracted what they named the Cosmos Master Key: a signing secret with two capabilities that should never sit behind a single point of failure. The first was takeover, retrieving the primary key of any Cosmos DB account on demand, which grants full read and write access to that account’s data. The second was enumeration, listing every database on the service and filtering by subscription or tenant identifier to find specific targets. Because Cosmos DB underpins core Microsoft infrastructure including Entra ID, Teams and Copilot, the theoretical blast radius extended well past customer application databases. Notably, even customers running network-isolated, private Cosmos DB deployments were not protected, because the vulnerable gateway enforces those network restrictions itself rather than sitting behind them.
An eight-month gap between report and fix
Wiz reported the flaw to Microsoft on 20 November 2025. Microsoft acknowledged it the same day and deployed a hotfix within 48 hours that blocked the specific Gremlin entry point Wiz had used. That closed the exact path demonstrated in the research, but it did not eliminate the underlying platform-wide key or restructure how the gateway handles credentials. That deeper architectural work continued for another eight months, concluding in July 2026 with a fix rolled out across all Azure regions, followed by public disclosure on 30 July.
Microsoft’s position is that no evidence of exploitation exists and no customer action is required. Both statements are almost certainly accurate as far as Microsoft’s own visibility extends. But that visibility is also the entire basis for the assurance. A platform-wide secret existed, in a form capable of granting cross-tenant access, for at least eight months before the architectural fix eliminated it. Whether anyone else found the same path during that window is a question only Microsoft’s own logging can answer, and customers have no independent way to verify it.
What this means under GDPR
For organisations storing personal data in Cosmos DB, GDPR Article 33’s 72-hour breach notification clock starts when a controller becomes aware of a breach, not when one theoretically could have occurred. A vulnerability at the cloud provider’s shared infrastructure layer that predates its own detection puts every customer relying on that provider’s telemetry, rather than their own, to know whether they were affected. That is not a reason to distrust Microsoft’s disclosure. It is a reason to have your own answer ready for a regulator or auditor who asks what your organisation did to independently verify exposure once CosmosEscape became public, rather than pointing back to a vendor statement.
If your organisation runs regulated workloads on Azure Cosmos DB and wants help reviewing what a shared-infrastructure vulnerability like this means for your own compliance posture, auditing your data residency and access architecture, or building an incident response process that does not depend entirely on a cloud vendor telling you something happened, contact Excello Digital. We help European organisations ask cloud providers the right follow-up questions.