Summary
- CosmosEscape began with code execution through the Azure Cosmos DB Gremlin query interface.
- Researchers reached a platform-wide signing key capable of retrieving database-account primary keys across tenants and regions.
- Microsoft found no unauthorised activity beyond the research and completed a long-term architectural fix in July.
A vulnerability chain in Azure Cosmos DB could have crossed tenant, regional, and network-isolation boundaries by reaching a platform-wide credential inside Microsoft’s managed database infrastructure.
The issue, named CosmosEscape by researchers at Wiz, affected Azure Cosmos DB. Microsoft has remediated the weakness and said its investigation found no unauthorised activity beyond the researchers’ testing and no access to customer data.
The chain began in the Gremlin application programming interface, which supports graph-database queries. Researchers found that the service’s custom .NET query engine did not sufficiently restrict reflection capabilities.
That weakness allowed code execution on a database gateway running in multi-tenant infrastructure. The gateway did not host customer databases directly, but it required credentials capable of obtaining the keys used to reach them.
Wiz found that credentials available to the gateway provided access to a signing key that could retrieve a requested Cosmos DB account’s primary key. The signing key was not limited to the researchers’ account.
According to the research, it worked across tenants, regions, and several interfaces, including SQL, MongoDB, Cassandra, and Gremlin. Wiz called it the Cosmos Master Key.
The researchers also accessed a configuration store containing account names, subscription and tenant identifiers, network settings, tags, and other information. Combined with the signing key, the data could have allowed an attacker to identify a specific organisation’s databases and obtain full read and write access.
The chain also affected accounts configured with private or network-isolated access. The compromised gateway was responsible for enforcing parts of that isolation and operated on the trusted side of customer-configured controls.
The finding does not make private endpoints or firewall rules ineffective against ordinary threats. It demonstrates that controls managed by the customer cannot contain a compromise occurring inside a privileged provider service that is trusted to enforce them.
Microsoft deployed an immediate mitigation within 48 hours of receiving the report on 20 November 2025. It then completed a wider architectural fix across all regions in July 2026, removing the platform-wide key and strengthening service-to-service authentication, network protections, monitoring, and detection.
No customer action is required. Microsoft said further penetration testing did not identify similar attack paths, and the provider’s review found no evidence that the vulnerability was exploited outside the authorised research.
The absence of known exploitation limits the immediate incident impact, but the architecture exposed by the research has broader implications for cloud assurance. Managed services place some of the most important isolation boundaries inside systems that customers cannot inspect or configure.
Customers remain responsible for identity policies, application design, logging, and data governance. The provider controls the internal sandbox, service identities, management paths, and credentials used between platform components. CosmosEscape sat predominantly on the provider side of that division.
The platform-wide signing key increased the potential blast radius. Once the Gremlin sandbox was crossed, the credential turned a flaw in one query interface into a path capable of reaching accounts and service variants beyond the original database.
Traditional cloud reviews concentrate heavily on public endpoints, customer permissions, and configuration errors. Those controls remain necessary, but they cannot reveal whether a managed platform contains a privileged cross-tenant path behind the customer boundary.
Assurance must therefore include the provider’s architecture, logging, disclosure practices, and ability to determine whether a platform vulnerability was exploited. CosmosEscape did not become a confirmed customer breach, but it showed how a narrow query-engine flaw could reach the trust structure of a major managed database service.
