Wiz disclosed CosmosEscape, a Cosmos DB flaw that could expose a platform-wide key and let attackers take over accounts; Microsoft says it has fully
CosmosEscape, disclosed by Wiz Research, is a major vulnerability chain targeting Azure Cosmos DB. The core risk was that an attacker could submit a specially crafted query through a Gremlin database they created, bypass the service's built-in isolation, and ultimately obtain the primary access key for any Cosmos DB account, enabling full read and write access to data.[2][5]
The impact was not limited to a single tenant. According to the research, the vulnerability chain could ultimately reach a platform-level signing key, which Wiz called the Cosmos Master Key, meaning an attacker would not need prior access to a target account in order to enumerate and then target specific organizations' Cosmos DB accounts and access their databases.[1][2][5]
Wiz reported the issue to Microsoft on November 20, 2025. Microsoft then blocked the Gremlin query attack path within 48 hours; the longer-term architectural fix was completed in July 2026 and rolled out to all Azure regions.[1][3][5] Microsoft said its review of access logs found no unauthorized activity beyond the researchers' tests, and no customer data was read, so customers do not need to take additional action.[1][3][5]
The key issue in CosmosEscape lay in the handling of Gremlin querys. Cosmos DB first translated queries into .NET code and then executed them, and the researchers found that the restriction mechanisms did not fully block .NET reflection, allowing the controlled execution environment to unexpectedly gain the ability to read and write files and trigger arbitrary code behavior.[2][4]
Once an attacker gained execution capability inside the isolation boundary, they could enter the database gateway that executes queries on behalf of customers. The gateway runs in a multi-tenant cluster and can obtain a signing key through cluster credentials; Wiz later confirmed that this key was not limited to a single account but applied across the service, and it was therefore named the Cosmos Master Key.[2][5]
According to the public description, this key was not constrained by a single account, tenant, region, or database interface, and it could be used through a public endpoint to obtain the primary access key for any Cosmos DB account.[1][2][5] Because the primary key itself grants full read and write permissions, anyone who obtained it could directly read, modify, or delete the contents of the target database.[2][5]
The researchers also noted that an attacker could query Cosmos DB's account configuration directory, which includes account names, Azure subscription IDs, tenant IDs, network restrictions, and tags.[2][5] This meant attackers could not only obtain keys, but also identify and filter targets in advance, making the attack more precise rather than a simple random scan.[2][5]
Notably, accounts using a private endpoint or restricting external network access could also have been affected. The reason is that the database gateway itself enforces network restrictions; if the gateway is compromised, attackers may be able to connect from within Microsoft services to databases that were previously closed off, and existing network rules could also be altered after account settings are changed.[2][5]
From a risk-model perspective, CosmosEscape is a cross-tenant and platform-wide threat, because the attack surface is not a single customer's application but a shared service mechanism hosted within the cloud platform.[1][3][5]
If successful, the affected scope could include all customer workloads using Azure Cosmos DB.[4][5] A design-level failure like this means a much larger blast radius than a typical application vulnerability, because it directly touches the trust boundary of a cloud database.[3][4]
On the data side, the main risk is complete takeover of any database account, leading to possible data exfiltration, tampering, deletion, and lateral discovery.[2][5] On the control plane side, attackers could also use directory information to identify assets with specific tenant or subscription characteristics, improving the success rate against high-value targets.[2][5]
Although Microsoft said it found no evidence of unauthorized exploitation, the severity of this type of vulnerability should not be underestimated, because it shows that once the internal isolation and key model of a cloud-hosted service fail, even multiple logical defenses on the customer side can be bypassed.[1][3][5]
In this case, Microsoft has already completed remediation, and the company states that no additional customer action is required.[1][3][5] However, from a defensive engineering perspective, organizations should still treat this incident as a warning about the cloud trust model, especially for highly sensitive databases and multi-region active-active architectures, and re-examine permissions, network controls, and detection design.[2][5]
In addition, organizations should treat private endpoints, network restrictions, and account-level access controls as complementary rather than single points of reliance, because this case shows that if the gateway layer is compromised, boundary controls that depend on internal service execution may no longer work as intended.[2][5] For critical databases, teams should also regularly review asset metadata such as subscriptions, tenants, and tags to avoid giving attackers an easier search path through overly complete directory information.[2][5]
Finally, security teams should include cloud-native services in threat modeling and incident exercises, including scenarios such as sandbox escape, service-to-service authentication, and gateway compromise.[4][5] These risks are often not reflected in a scan of a single application flaw and require a combination of cloud-vendor advisories, access auditing, and anomaly detection to identify problems early.[1][3][7]
Five-Step Remediation Checklist