A critical vulnerability in **Azure Cosmos DB**, codenamed **CosmosEscape** by cloud security firm **Wiz**, could have enabled attackers to break out of the service's Gremlin query sandbox. This escape would have granted full read and write access to databases across multiple customer tenants. ### The Attack Chain: From Query to Keys **Wiz** detailed that the exploit chain began with a specially crafted query targeting an attacker-controlled Gremlin database. This initial step led to code execution on a multi-tenant gateway component. Once compromised, the gateway exposed a crucial platform-wide signing secret and a regional account directory. This access would have allowed researchers to pinpoint a specific target organization and retrieve its primary account key, effectively granting full control over their **Cosmos DB** resources.  ### Swift Remediation by Microsoft **Microsoft** acted swiftly, blocking the vulnerable Gremlin entry point within 48 hours of **Wiz**'s report in November 2025. The full, long-term fix, which eliminated the platform-wide key, was rolled out across all regions by July 2026. "We appreciate Wiz's work in identifying and reporting this issue through coordinated vulnerability disclosure," a **Microsoft** spokesperson stated. "We have fully addressed the issue and found no evidence of customer impact based on our investigations. We continue to invest in additional security enhancements across the platform." **Microsoft**'s internal review corroborated that no unauthorized activity occurred outside of the researchers' testing, confirming no customer data was accessed, and no customer action is required. ### Technical Deep Dive: .NET Reflection Abuse According to **Wiz**'s technical write-up, **Cosmos DB**'s custom Gremlin engine translates queries into .NET code, executing them within a restricted environment. However, these restrictions failed to adequately account for .NET reflection. This oversight allowed **Wiz** researchers to establish file-read and file-write primitives, ultimately leading to arbitrary code execution. While the public disclosure showcased the output of a crafted query executing a `hostname` command on the **Cosmos DB** backend, the query itself was not fully published. **Wiz** plans to present the complete exploit chain at a **Black Hat USA** briefing on August 6.  ### Impact on Multi-Tenant Architecture The code execution occurred on a component **Wiz** termed the DB Gateway, responsible for executing customer queries on multi-tenant **Azure Service Fabric** clusters. Although customer databases weren't directly on these clusters, the gateway possessed the capability to retrieve primary keys for any requested **Cosmos DB** account. **Microsoft** documentation confirms that a primary key grants full control over all resources within an account. Crucially, credentials available to the gateway also provided access to a signing key, dubbed the **Cosmos Master Key** by **Wiz**. This key could retrieve the primary key for *any* account across various tenants, regions, and **Cosmos DB**'s SQL, MongoDB, Cassandra, and Gremlin APIs. Furthermore, the same secret unlocked a regional database known as the Config Store, which acts as a directory for **Cosmos DB** account names, subscription and tenant identifiers, network settings, and tags. An attacker could have leveraged this to locate specific organizational accounts and then request their primary keys. **Wiz** noted that the attack chain could even reach private and network-isolated accounts, as the compromised gateway enforced these network boundaries from within the service. While the report suggested the ability to alter network settings via write access to the Config Store, this was not demonstrated against another customer's account. ### Potential Data Exposure and Unknowns **Microsoft** documentation indicates that **Teams** message data resides in **Cosmos DB**, and a **Microsoft** engineering post confirms that **Copilot** stores user queries and conversation histories there. **Wiz** stated that databases supporting these products were potentially accessible, though they did not report accessing such data. Details regarding when the vulnerable engine and signing-key path were introduced into production, or the specific period covered by **Microsoft**'s log review, remain undisclosed. Consequently, the full duration of potential exposure before the fix is unknown. This incident is distinct from previous **Cosmos DB** vulnerabilities like **ChaosDB** (2021) and **CosMiss** (2022), which involved the service's Jupyter Notebook feature. No **CVE** identifier or severity score has been publicly assigned for **CosmosEscape**.