News Date: 2026-07-31
A critical vulnerability in Microsoft Azure Cosmos DB could have allowed an attacker to obtain powerful account keys and gain full read and write access to databases belonging to other customers. Researchers at Wiz named the vulnerability CosmosEscape and demonstrated how a sandbox escape could lead to the discovery of a platform-level signing key.
From Query Sandbox to Master Key
The attack path began in the Gremlin application programming interface, which enables graph database queries. Cosmos DB processed these queries through a custom engine that compiled them into .NET code and executed them inside a sandbox.
Researchers found that the sandbox restrictions did not adequately account for .NET reflection. By abusing this capability, they built code execution primitives and escaped the intended Gremlin environment, reaching a database gateway operating within Microsoft's multi-tenant infrastructure.
The gateway used a signing key to retrieve primary keys for customer accounts. Critically, the signing key reportedly worked across tenants, regions, and multiple interfaces. Researchers could then access a configuration database containing Cosmos DB account names, subscription identifiers, tenant identifiers, and other metadata. This created a path for locating a specific organization's databases and retrieving the keys needed for complete access.
The attack could also have affected private or network-isolated Cosmos DB accounts because the vulnerable operations occurred inside Microsoft's service infrastructure. Microsoft uses Cosmos DB within services including Entra ID, Teams, and Copilot, making the architectural implications particularly significant.
Microsoft's Response
Wiz reported CosmosEscape to Microsoft in November 2025. Microsoft deployed a hotfix within two days and completed a long-term architectural correction across all regions in July 2026. The company reviewed access logs and reported no evidence of unauthorized activity outside the researchers' testing. It also said that no customer action was required.
What Cloud Customers Should Learn
- Monitor data access independently instead of relying exclusively on cloud perimeter controls.
- Use separate accounts and databases for workloads with different risk profiles.
- Minimize the amount of sensitive information stored under any single service identity.
- Export audit logs to a separate security environment that attackers cannot easily alter.
- Maintain response plans for cloud provider vulnerabilities that customers cannot patch themselves.
In my view, CosmosEscape demonstrates the systemic risk created by shared control-plane credentials. Cloud isolation can fail above the customer-configurable network layer, where tenants have limited visibility. Microsoft responded quickly, but cloud customers should still design systems on the assumption that provider-managed boundaries and keys may eventually be tested by an unexpected vulnerability.