How a Single Azure Cosmos DB Flaw Could Have Exposed Every Database on the Platform

A Flaw With Platform-Wide Consequences

A critical security vulnerability in Microsoft's Azure Cosmos DB — one of the world's most widely used cloud database services — could have allowed malicious actors to access every database hosted on the platform, according to a detailed disclosure from cloud security firm Wiz. The Azure Cosmos DB vulnerability, which researchers named CosmosEscape, was serious enough that it potentially exposed not only customer databases, but also Microsoft's own internal data infrastructure, including systems underpinning Entra ID (formerly Azure Active Directory), Microsoft Teams, and the company's AI assistant, Copilot.

For developers, privacy professionals, and IT decision-makers relying on Azure cloud infrastructure, the findings represent a stark reminder of how deeply interconnected modern cloud platforms are — and how a single architectural flaw can cascade into a catastrophic, platform-wide security event. The fact that no customer data was confirmed to have been accessed does not diminish the severity of what was possible.

How CosmosEscape Worked: From Sandbox Bypass to Master Key

The attack chain began with the Gremlin API, a graph query language supported by Azure Cosmos DB. According to Wiz's findings, as reported by SecurityWeek, the Gremlin engine compiled queries into .NET code and executed them inside a sandboxed environment. While the sandbox enforced restrictions designed to limit operations to Gremlin functions only, it failed to account for .NET reflection — a powerful programming mechanism that allows code to inspect and invoke other code dynamically at runtime.

Wiz researchers exploited this oversight to build arbitrary code execution primitives, effectively breaking out of the sandbox. This gave them code execution on the DB Gateway — a service responsible for executing customer queries on multi-tenant Service Fabric clusters. In a multi-tenant cloud environment, this is an exceptionally dangerous foothold: it means a single compromised component can potentially interact with the data of many different organisations simultaneously.

Once inside the gateway, researchers made a more alarming discovery. The gateway was using a signing key to retrieve primary keys from customer accounts and access their databases. Critically, this signing key was not scoped to a single tenant, region, or API — it worked universally across the entire platform. Wiz named this the Cosmos Master Key.

With the Cosmos Master Key in hand, an attacker could query a configuration store — itself a Cosmos DB database — containing details of every account on the service: names, subscription IDs, tenant IDs, and a wealth of additional configuration data. Armed with this, an attacker could enumerate all Cosmos DB accounts across an entire region, filter by organisation, and retrieve the primary key of any target account, gaining full read and write access to all their databases. Crucially, Wiz confirmed the attack would also have worked against private and network-isolated Cosmos DB accounts, as well as Microsoft's own databases.

Why the Scope of This Azure Cloud Security Risk Matters

To understand why this finding is particularly significant for European businesses, privacy professionals, and GDPR-conscious organisations, it helps to appreciate the scale at which Azure Cosmos DB operates. According to Microsoft's official Azure documentation, Cosmos DB is a globally distributed, multi-model database service used by thousands of enterprises worldwide for mission-critical applications — from financial services to healthcare to e-commerce. It is not a niche product; it is core infrastructure for a significant portion of the global cloud computing ecosystem.

What makes CosmosEscape particularly sobering from a data sovereignty and GDPR compliance standpoint is the nature of the data at risk. Microsoft itself stores data across Cosmos DB for core products including Entra ID (the backbone of corporate identity management across millions of organisations), Microsoft Teams (used by hundreds of millions of workers), and Copilot (Microsoft's AI platform increasingly embedded in enterprise workflows). A successful exploitation of this vulnerability would not have been a breach of one company's data — it could have been a breach of the underlying infrastructure that many organisations trust to manage their identities, communications, and AI-driven operations.

For organisations operating under GDPR or other data protection frameworks, the implications of a theoretical breach of this nature would be severe. Under GDPR, a personal data breach must be reported to the relevant supervisory authority within 72 hours of becoming aware of it. A breach affecting identity infrastructure like Entra ID across multiple EU-based tenants could trigger regulatory obligations for thousands of organisations simultaneously — none of whom would have had any visibility into the attack or control over the underlying infrastructure. This is the core tension of shared responsibility models in cloud computing, a topic the European Union Agency for Cybersecurity (ENISA) has repeatedly flagged as a growing risk for European enterprises.

Breaking Down the CosmosEscape Attack Chain Step by Step

What makes this attack chain particularly concerning for security architects is the use of publicly accessible endpoints at every stage. Unlike many advanced persistent threat scenarios that require internal network access or physical proximity, CosmosEscape could have been executed entirely from the public internet. This significantly lowers the barrier for exploitation and expands the pool of potential attackers beyond nation-state actors to include well-resourced criminal organisations.

Microsoft's Response and the Limits of Cloud Transparency

Wiz reported the Azure Cosmos DB vulnerability to Microsoft in November 2025. Microsoft's incident response was notably swift: within two days, the company deployed a hotfix to block the primary attack vector. By July, Microsoft had completed the rollout of a long-term architectural fix across all regions — a more thorough remediation designed to prevent similar issues from arising in future.

Microsoft's official statement confirmed that the company conducted extensive reviews of access logs and found no evidence of unauthorised activity outside of Wiz's own testing. "No customer data was accessed," the company stated, adding that no action is required from customers. This is reassuring, but it also highlights a structural issue that privacy advocates and cloud security researchers have long flagged: customers have no independent way to verify these assertions. They are entirely reliant on the cloud provider's own internal audit processes.

This tension between cloud provider assurances and independently verifiable security is at the heart of ongoing debates around digital sovereignty and data protection, particularly in Europe. The EU's European Cloud Strategy and initiatives like Gaia-X are partly motivated by exactly these concerns: that organisations storing sensitive data on hyperscale public clouds must trust that provider's security controls without meaningful independent oversight.

The CosmosEscape case also raises important questions about responsible disclosure and the security of AI infrastructure. Microsoft's Copilot — a product that has seen rapid enterprise adoption — relies on Cosmos DB as part of its backend. As organisations increasingly integrate AI tools into their workflows, the security of the underlying database and identity infrastructure becomes a critical dependency that deserves explicit scrutiny, particularly in regulated industries subject to frameworks like GDPR, HIPAA, or the EU AI Act.

What the Azure Cosmos DB Flaw Reveals About Multi-Tenant Cloud Security

The broader lesson from CosmosEscape is not unique to Microsoft. Multi-tenant cloud architectures — where many customers share the same underlying infrastructure — are inherently complex, and that complexity creates attack surface. According to research published by Gartner, cloud security misconfigurations and architectural vulnerabilities continue to be among the leading causes of data exposure in cloud environments. The distinction between a misconfiguration and a design flaw — as seen here — is sometimes academic from a risk perspective; the outcome can be identical.

The use of a single, platform-wide signing key — one that could unlock any customer's primary database credentials — represents a failure of the principle of least privilege, one of the most fundamental tenets of secure system design. If such keys must exist

Originally reported by Security Week. Summarised and curated by European Purpose.