A vulnerability that Microsoft has now closed shows what happens when a multi-tenant cloud platform relies on one signing key to protect thousands of customers at once. Security firm Wiz disclosed that a flaw in Azure Cosmos DB’s Gremlin query engine could have let an attacker with an ordinary Azure account retrieve a platform-wide master key and, from there, reach primary account credentials across every Cosmos DB tenant, region, and API, including databases their owners had deliberately isolated from the public network.
A shared key, not a shared responsibility model
Cosmos DB is Microsoft’s flagship multi-model database, used across the SQL, MongoDB, Cassandra, and Gremlin APIs, and it also underpins internal Microsoft services including Entra ID, Teams, and Copilot. According to Wiz’s technical writeup, the weakness sat in the custom .NET engine that Cosmos DB uses to run Gremlin graph queries. Gremlin servers typically compile submitted queries into executable code and run it inside a restricted sandbox. Wiz researchers found that Cosmos DB’s sandbox did not adequately restrict .NET reflection, the mechanism a program uses to inspect and invoke its own code at runtime. A specially crafted query against an attacker’s own Gremlin database could use that gap to break out of the sandbox and execute arbitrary code on the shared database gateway infrastructure.
From code execution to every tenant’s keys
Escaping the sandbox was only the first step. From the compromised gateway, Wiz found a path to the Cosmos Master Key, a platform-wide signing credential that was not scoped to any individual customer account. With that key in hand, an attacker could retrieve the primary keys for any Cosmos DB account on the platform. Wiz went further and showed that the gateway also had access to Cosmos DB’s internal Config Store, itself built on Cosmos DB, which let an attacker enumerate every account by tenant and subscription ID and, Wiz said, would have allowed write access capable of altering network configuration.
The practical result, per Wiz: an attacker starting from a standard Azure subscription, the kind anyone can create with a credit card, could have obtained credentials granting what the firm described as full control over other customers’ Cosmos DB resources, including accounts their owners believed were network-isolated. Because the master key spanned APIs, the exposure was not confined to Gremlin users; SQL, MongoDB, and Cassandra API customers who never touched the graph engine were still reachable through the shared key architecture underneath.
An eight-month path from report to full fix
Wiz reported the flaw to Microsoft on November 20, 2025, through coordinated disclosure. Microsoft blocked the vulnerable Gremlin entry point within 48 hours and began longer-term architectural work, which it says it completed across all regions in July 2026. Microsoft states it reviewed access logs and found no evidence of unauthorized activity beyond Wiz’s own testing, and no customer data was accessed; it says no customer action is required. The company’s remediation eliminated the platform-wide Cosmos Master Key entirely, added service-to-service authentication guardrails, and introduced new network protections and detection capabilities aimed at preventing a similar sandbox-to-credential chain. Wiz plans to present the research, which it calls CosmosEscape, at Black Hat USA in August 2026.
The gap between the interim mitigation and the full architectural fix, roughly eight months, illustrates a problem that outlasts this specific bug: replacing a foundational, platform-wide credential inside a live multi-tenant service cannot happen overnight, even once the vendor knows exactly what is wrong.
What CosmosEscape means for the security leader
For CISOs running workloads on Cosmos DB or any comparably architected multi-tenant PaaS database, the lesson is less about this single bug than about the blast radius that a shared signing key creates. Network isolation, private endpoints, and per-account access controls, the tools most security teams reach for first, did nothing here, because the compromise path ran underneath the tenant boundary, through infrastructure the customer never sees or controls. That is a shared-responsibility gap: the customer manages access to their data, but the cloud provider alone manages the gateway and key architecture that sat between every tenant and every other tenant’s data.
This also raises the bar for how security teams should evaluate managed cloud data services during procurement and architecture review. Questions worth asking a cloud database vendor now include whether any single credential or service component has visibility across tenant boundaries, how quickly a platform-wide credential could be rotated or eliminated if compromised, and what independent verification exists that the sandbox isolating one customer’s queries actually holds under adversarial testing, since Wiz noted plainly that “these sandboxes haven’t held up well” as a class of defense.
What to do now
Microsoft says the fix is fully deployed and no customer action is required, and organizations should not expect to find remediation steps of their own to take for this specific flaw. Security teams should instead use CosmosEscape as a trigger to review their own exposure to platform-level shared credentials more broadly: inventory which managed cloud services your organization relies on for multi-tenant isolation rather than customer-controlled encryption or network boundaries, ask cloud vendors directly whether platform-wide keys exist anywhere in their architecture, and prioritize monitoring for anomalous cross-account access patterns in cloud database logs, since a compromise at this layer would not necessarily trip the alerts your team built around network and identity controls.
Cosmos DB’s role underneath Microsoft’s own identity and collaboration stack is also a reminder that cloud security review can’t stop at the services an organization directly provisions. As CyberTech has covered in the context of zero trust reaching the workload layer, perimeter and network controls increasingly cannot see or stop compromises that occur inside the cloud provider’s own shared infrastructure, which is exactly where CosmosEscape lived.
Source: Wiz
