Critical CosmosEscape Vulnerability Exposes Azure Cosmos DB Instances

Key Takeaways

• A critical vulnerability, dubbed CosmosEscape (CVE-2023-38177), was discovered in Microsoft Azure Cosmos DB’s Gremlin API.
• The flaw could have allowed attackers to achieve arbitrary code execution, gain access to a “Cosmos Master Key,” and ultimately take control of any database in the service, including Microsoft’s own internal systems.
• The vulnerability posed a significant cross-tenant risk, potentially affecting millions of customer workloads across various API formats and regions.
• Microsoft rapidly patched the issue after responsible disclosure by Wiz researchers and found no evidence of exploitation in the wild.
• No action is required from Azure Cosmos DB customers, as the fix was applied server-side.

CosmosEscape: A Critical Flaw in Azure Cosmos DB

A severe vulnerability, named CosmosEscape, was recently uncovered within Microsoft Azure Cosmos DB, presenting a potential pathway for attackers to compromise virtually every database hosted on the platform. This critical flaw, tracked as CVE-2023-38177, could have provided unauthorized access to customer data and even Microsoft’s internal infrastructure.

The vulnerability specifically targeted Cosmos DB’s Gremlin API. Successful exploitation would have enabled a sophisticated cross-tenant attack, impacting a vast number of customer workloads and potentially exposing sensitive information across the multi-tenant cloud environment.

Unveiling the CosmosEscape Vulnerability

The discovery of CosmosEscape began when researchers at Wiz were examining Gremlin, a popular graph query language supported by Cosmos DB. During their analysis, they observed an unusual .NET exception, which immediately raised suspicion. Given that most open-source Gremlin implementations rely on the Java Virtual Machine (JVM), this exception indicated that Cosmos DB utilized a custom .NET-based Gremlin engine.

This distinction was crucial because Gremlin servers typically compile queries into executable code within a restricted sandbox. Such sandboxes, historically, have shown vulnerabilities when faced with determined attackers. The Wiz team’s suspicion proved well-founded.

Further investigation revealed that Cosmos DB’s custom engine, while translating Gremlin queries into .NET code, failed to adequately restrict .NET reflection. Reflection is a powerful feature that allows code to inspect and manipulate other code at runtime. By leveraging this oversight, the researchers developed capabilities for file reading, file writing, and eventually, arbitrary code execution, all by crafting specialized queries against their own database.

As a compelling proof of concept, the researchers demonstrated the execution of the hostname command directly on Cosmos DB’s backend infrastructure using a specially designed Gremlin query.

From Sandbox Escape to Master Key Access

This initial code execution provided the researchers with a foothold on the DB Gateway, a multi-tenant component responsible for processing customer queries. Although customer databases are not stored on the same clusters as the Gateway, the Gateway requires a mechanism to access them. It achieved this using a signing key designed to retrieve any account’s primary key.

Crucially, this signing key was not restricted to a single customer or geographical region. It operated across various tenants, regions, and all supported API formats, including SQL, MongoDB, Cassandra, and Gremlin. Wiz aptly named this powerful secret the “Cosmos Master Key.”

The Cosmos Master Key also granted access to the Config Store, which functions as Cosmos DB’s central directory. This store contains comprehensive information about every account on the platform, including subscription IDs, tenant IDs, network rules, and tags.

Because the Config Store itself is a queryable Cosmos DB database, an attacker could have used it to enumerate every account within a region or filter results by tenant ID to precisely target specific organizations. As highlighted in the Wiz Research Blog, chaining sandbox escapes with unscoped signing keys fundamentally bypasses cloud isolation boundaries.

This architectural vulnerability aligns with broader trends observed in Microsoft cloud security, where overprivileged machine accounts and underlying service permissions can significantly expand the potential impact of a single flaw.

The combination of these two capabilities created a devastating attack chain: enumerate targets via the Config Store, then utilize the Cosmos Master Key to obtain their primary key, thereby gaining full read-write access to their data. The implications extended beyond typical enterprise customers, reaching into Microsoft’s own backend systems, as Cosmos DB underpins critical services like Microsoft Entra ID, Microsoft Teams, and Microsoft Copilot.

Even private, network-isolated databases were at risk, as the compromised DB Gateway itself was responsible for enforcing that isolation. This scenario underscores the importance for security teams to continuously audit for cloud logging threats and unexpected access patterns across critical data stores.

Microsoft’s Rapid Remediation

Wiz responsibly disclosed the CosmosEscape vulnerability to Microsoft. In response, Microsoft promptly deployed a hotfix and has since fully remediated the issue. This remediation involved the complete elimination of the Cosmos Master Key and the implementation of new architectural safeguards to prevent similar vulnerabilities.

Microsoft’s internal investigation found no evidence that the vulnerability was maliciously exploited prior to the disclosure. Consequently, no action is required from Azure Cosmos DB customers.

What You Should Do

• While no direct action is needed from Azure Cosmos DB customers for this specific vulnerability, organizations should regularly review their cloud security posture.
• Implement robust logging and monitoring for anomalous activities within your Azure Cosmos DB instances and related services.
• Adhere to the principle of least privilege for all cloud resources, ensuring that accounts and services only have the permissions necessary for their operations.
• Stay informed about cloud vendor security advisories and promptly apply any recommended patches or configuration changes.
• Consider engaging in regular security audits or penetration testing of your cloud infrastructure to identify and address potential vulnerabilities proactively.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.