Wiz Research uncovered CosmosEscape, a critical vulnerability in Azure’s flagship database service, Azure Cosmos DB, via its Gremlin API. The vulnerability could have been exploited to compromise every database in the service, including Microsoft's own internal databases - potentially enabling a cross-service attack.
Through CosmosEscape, attackers could have acquired what we’ve dubbed the Cosmos Master Key - a platform-wide secret that granted two incredibly powerful capabilities:
Takeover - retrieving the primary key of any Cosmos DB account on demand, resulting in full read & write access.
Enumeration - listing all databases on the service with the ability to filter by specific organization identifiers like subscription and tenant IDs.
Chained together, these capabilities could have enabled precision targeting at platform scale: from identifying a specific organization's databases to compromising them, all from publicly accessible endpoints.
Cosmos DB is used internally across Microsoft - services like Microsoft Entra ID, Microsoft Teams, and Microsoft Copilot all store data in Cosmos DB. Their databases were potentially accessible via this vulnerability.
Microsoft has now fully remediated the issue, including eliminating the Cosmos Master Key. Microsoft also introduced new guardrails to Cosmos DB to prevent similar attacks.
This research was assisted by an early version of Atlas, our AI vulnerability researcher. Expect more from Atlas soon.
Required Actions
Microsoft has fully remediated this issue. No customer action is required. Microsoft conducted a thorough investigation and found no evidence of exploitation of this vulnerability beyond the research described in this blog.
From a Single Query to Unlocking Every Database
Cosmos DB supports multiple query APIs, and among them is Gremlin, a popular graph query language:
// Find all users over 30 and return their friends' namesg.V().hasLabel('user').has('age', gt(30)).out('knows').values('name')
While running Gremlin queries against Cosmos DB, we noticed a suspicious .NET exception. Since most open-source Gremlin stacks are JVM-based, the exception suggested that Cosmos DB was using a custom Gremlin engine. This was interesting - unlike standard SQL, where the engine maps queries to a fixed set of built-in operations, Gremlin servers often compile queries into executable code and run it in a restricted environment. Historically, these sandboxes haven't held up well. We suspected Cosmos DB's Gremlin sandbox may be vulnerable as well.
And it was. Cosmos DB's engine translated Gremlin queries into .NET code, enforcing a set of restrictions designed to prevent queries from reaching beyond Gremlin operations. These restrictions, however, didn't sufficiently account for .NET reflection - allowing us to develop file read, write, and ultimately arbitrary code execution primitives, all through queries against our own database.
The following image shows the output of a specially crafted Gremlin query ran against our database, resulting in the hostname command being executed on the Cosmos DB backend:
By bypassing the Gremlin sandbox, we’ve gained code execution on the DB Gateway, a service that executes customer queries on their behalf, running on multi-tenant Service Fabric clusters.
Looking around, customer databases weren’t hosted on these clusters, but the DB Gateway still had to reach them somehow. It turned out that it did so like any Cosmos DB client would - using the target account’s primary key, which grants full read-write access to the account’s databases.
But how can the DB Gateway retrieve the primary key of our Cosmos DB account?
The Cosmos Master Key
Through credentials available on the cluster, the DB Gateway accessed a signing key that could retrieve the requested account’s primary key.
We soon discovered the signing key wasn't scoped to a single account. It worked across tenants, regions, and even API flavors - SQL, MongoDB, Cassandra, and Gremlin. It was a platform-wide key that could retrieve the primary key for any Cosmos DB account on the service, all through publicly accessible endpoints. We dubbed it the Cosmos Master Key.
The Config Store - Cosmos DB's Account Directory
The Master Key also unlocked the Config Store: a regional registry of every Cosmos DB account - containing account names, subscription IDs, tenant IDs, network settings, tags, and more. The DB Gateway relied on it for account settings, like which IPs were allowed to access a database.
The Config Store was itself a Cosmos DB database, meaning it could be queried with the full flexibility of CosmosDB's SQL engine. It also meant that the Cosmos Master Key could retrieve its primary key - enabling attackers that exploited CosmosEscape to list all accounts in a region, or query by specific tenant ID to identify a specific organization's databases.
Impact
Together, the Cosmos Master Key and the Config Store enabled a powerful attack chain:
Query the ConfigStore to enumerate all Cosmos DB accounts in a region, or filter by tenant or subscription to target specific organizations.
Use the Cosmos master key to retrieve the target’s primary key, granting full read and write access to all their databases.
This affected more than just customer databases. Cosmos DB serves as foundational infrastructure for numerous Microsoft and Azure services - meaning Microsoft's own internal databases were equally exposed.
CosmosEscape also impacted private and network-isolated Cosmos DB accounts. Since the DB Gateway is responsible for enforcing network isolation, compromising it allows direct access to private databases. Furthermore, write access to the Config Store suggested that an attacker could potentially overwrite network isolation settings.
Conclusion
Cloud platforms are built in layers. Services like Cosmos DB sit in the infrastructure tier - powering higher-level offerings such as Microsoft Teams, Microsoft Entra ID, and Microsoft Copilot. A vulnerability at this layer can cascade upward and threaten the services built on top of it.
Multi-tenant cloud services require at least one strong isolation boundary around tenant-controlled execution - one that exposes only a small, heavily audited attack surface. Everything inside that boundary should be treated as tenant-controlled and untrusted. Ideally, the boundary should be drawn tightly around the tenant’s environment: the fewer resources it contains, the easier it is to ensure that privileged credentials, internal APIs, and cross-tenant paths remain out of reach.
We responsibly disclosed this vulnerability to Microsoft, who fully remediated it. Microsoft deployed a hot fix quickly, and since then the Cosmos DB team worked around the clock on a major migration to a better, hardened architecture. We’d like to thank the MSRC and Cosmos DB teams for their collaboration on this issue and continued partnership.
Microsoft appreciates the opportunity to investigate the findings reported by Wiz under Coordinated Vulnerability Disclosure (CVD). Microsoft conducted extensive reviews of access logs and found no evidence of unauthorized activity outside of the researcher’s testing activity, and no customer data was accessed. There is no customer action required.
Once the issue was reported, Microsoft engineering and security response teams promptly investigated and developed an immediate mitigation for this vulnerability in the Gremlin API of Azure Cosmos DB, and within 48 hours, the mitigation was deployed to block the entry point for this attack vector. Microsoft performed extensive penetration testing to look for similar attack vectors with none identified.
Microsoft implemented additional platform hardening designed to enhance the underlying authentication architecture and further improve overall security posture. These enhancements strengthened service-to-service authentication and introduced further network protections, monitoring, and detection capabilities to improve the security posture of Azure Cosmos DB, while maintaining reliability, availability, and performance.
Microsoft will continue to harden the platform, reinforcing our commitment to resolving these issues and strengthening protections for customers
Responsible Disclosure Timeline
Nov 20th, 2025 - Wiz Research reports the vulnerability to Microsoft.
Nov 20th, 2025 - Microsoft acknowledges receipt.
Nov 22nd, 2025 - Microsoft deploys a hot fix and starts work on a long-term architectural fix.
July 2026 - Microsoft completes long-term fix rollout across all regions.
July 30th, 2026 - Public disclosure.
Stay in touch!
Hi there! We are Yuval Avrahami (@yuvalavra), Sagi Tzadik (@sagitz_), Nir Ohfeld (@nirohfeld), Ronen Shustin (@ronenshh), Hillai Ben-Sasson (@hillai), and Noam Malron (@noamsec) from the Wiz Research Team (@wiz_io). We are a group of veteran white-hat hackers with a single goal: to make the cloud a safer place for everyone. We primarily focus on finding new attack vectors in the cloud and uncovering isolation issues in cloud vendors and service providers. We would love to hear from you! Feel free to contact us on X (Twitter) or via research@wiz.io.