A critical security flaw, termed ‘CosmosEscape,’ has been identified in Microsoft Azure’s Cosmos DB, potentially allowing attackers to gain control over numerous databases hosted on the platform, including Microsoft’s internal systems. This vulnerability resides within Cosmos DB’s Gremlin API and, if exploited, could facilitate cross-tenant attacks affecting millions of customer workloads and Microsoft’s infrastructure.
Researchers from Wiz discovered the issue while experimenting with Gremlin, a graph query language supported by Cosmos DB. They observed an unusual .NET exception, indicating that Cosmos DB employs a custom .NET-based Gremlin engine, diverging from the typical Java Virtual Machine (JVM) implementations. This distinction is significant because Gremlin servers compile queries into executable code within a restricted sandbox, which has historically been susceptible to breaches.
The researchers found that Cosmos DB’s engine translates Gremlin queries into .NET code but inadequately restricts .NET reflection—a feature allowing code to inspect and manipulate other code at runtime. By exploiting this oversight, they achieved file read, file write, and ultimately, arbitrary code execution capabilities through crafted queries executed against their own database. In a proof of concept, a specially designed Gremlin query executed the ‘hostname’ command directly on Cosmos DB’s backend infrastructure.
This code execution provided a foothold on the DB Gateway, the multi-tenant component responsible for running customer queries. Although customer databases are stored on separate clusters, the Gateway accesses them using a signing key capable of retrieving any account’s primary key. Notably, this signing key is not limited to a single customer or region; it functions across tenants, regions, and API formats, including SQL, MongoDB, Cassandra, and Gremlin. Wiz referred to this powerful secret as the ‘Cosmos Master Key.’
The Master Key also grants access to the Config Store, Cosmos DB’s master directory listing every account on the platform, along with subscription IDs, tenant IDs, network rules, and tags. Since the Config Store is itself a queryable Cosmos DB database, attackers could use it to enumerate every account in a region or filter results by tenant ID to target specific organizations precisely.
By combining sandbox escapes with unscoped signing keys, attackers can bypass fundamental cloud isolation boundaries. These architectural risks align with broader Microsoft vulnerability trends, where overprivileged machine accounts and underlying service permissions amplify the potential impact of a single flaw.
Chaining these capabilities creates a devastating attack path: enumerate targets through the Config Store, then use the Master Key to obtain their primary key and gain full read-write access to their data. Given that Cosmos DB underpins major Microsoft services such as Microsoft Entra ID, Microsoft Teams, and Microsoft Copilot, the exposure extends beyond enterprise customers to Microsoft’s own backend systems. Even private, network-isolated databases are at risk, as the compromised DB Gateway enforces that isolation.
This incident underscores the critical importance of robust sandboxing and strict access controls in cloud services. Organizations relying on multi-tenant cloud platforms must remain vigilant, ensuring that vulnerabilities in shared components do not compromise their data. Regular security audits, prompt patching, and comprehensive monitoring are essential to mitigate such risks.
