CosmosEscape: A Platform-Wide Trust Boundary Failure

Key Takeaways

Security researchers at Wiz disclosed CosmosEscape, a vulnerability chain in Azure Cosmos DB that allowed any authenticated Azure customer to escape the service’s Gremlin query sandbox, execute arbitrary code on a shared gateway component, and ultimately retrieve a single signing key capable of unlocking every customer database on the platform [1][2]. The flaw required no special privileges beyond a standard Azure account and an attacker-controlled Cosmos DB instance, which meant that, in effect, the barrier between a low-trust tenant and the credentials of every other tenant on the service depended entirely on a single query engine’s isolation guarantees [1]. Microsoft deployed an emergency mitigation within 48 hours of Wiz’s November 2025 report and completed a permanent architectural fix, including elimination of the platform-wide key, by July 2026, with no evidence of exploitation beyond the researchers’ own testing [2][3]. As Wiz put it, multi-tenant cloud services require at least one strong isolation boundary around tenant-controlled execution; CosmosEscape shows what happens when a single unscoped credential defeats that boundary across an entire platform [1].

Background

Azure Cosmos DB is Microsoft’s globally distributed, multi-model database service, used across the Azure ecosystem to back everything from customer-facing applications to internal Microsoft workloads. It supports several query interfaces layered atop a common storage engine, including the native SQL API, and API-compatible surfaces for MongoDB, Cassandra, and Gremlin, the last of which implements Apache TinkerPop’s graph traversal language [1]. Because Cosmos DB is a fully managed, multi-tenant service, Microsoft — not the customer — operates the gateway and compute infrastructure that parses and executes every tenant’s queries, an architecture in which a small number of shared components hold responsibility for isolating every tenant on the service.

Wiz researchers examining the Gremlin API’s behavior found that Cosmos DB compiled incoming Gremlin queries into executable .NET code before running them — a common performance optimization for query engines, but one that, in this case, was not paired with sufficient security isolation [1]. The service applied restrictions intended to keep compiled query code confined to graph-traversal operations, but those restrictions did not account for .NET’s reflection capabilities, a well-documented technique for stepping outside managed-code sandboxes by inspecting and invoking arbitrary types and methods at runtime [1]. By crafting Gremlin queries that abused reflection, the researchers found they could build file-read and file-write primitives and ultimately achieve arbitrary code execution on the DB Gateway, the multi-tenant service component that processes customer queries across the platform [1][3]. Wiz reported the finding to Microsoft on November 20, 2025; Microsoft blocked the vulnerable Gremlin entry point within 48 hours and began the longer architectural remediation that concluded roughly eight months later, with public disclosure following on July 30, 2026 [2][3]. Wiz has stated it will present the full technical chain at Black Hat USA on August 6, 2026 [3]. Notably, part of the discovery process involved Atlas, Wiz’s autonomous AI-assisted vulnerability research system publicly launched on July 27, 2026 — Wiz has described this as the first publicly confirmed case of Atlas contributing to a critical cloud infrastructure finding [5]. If AI-assisted tooling continues to be applied to cloud provider internals, disclosures of this kind may become more frequent, though this is the first such case rather than an established pattern.

CosmosEscape carries no CVE identifier or CVSS score, which is somewhat unusual for a flaw of this severity, though not unheard of for provider-specific architectural findings disclosed directly to a single vendor [1][2][3]. It is also technically distinct from earlier Cosmos DB security incidents: ChaosDB, disclosed in 2021, exposed customer primary keys through a Jupyter Notebook feature misconfiguration, and CosMiss, reported in 2022, involved a separate access-control gap in the Cosmos DB Notebooks feature [3]. CosmosEscape instead originates in the query engine itself and reaches a materially larger blast radius, since it targets a credential that was never meant to be scoped to any single customer.

Security Analysis

The core of the vulnerability is what Wiz researchers dubbed the “Cosmos Master Key,” a platform-wide signing secret that, once obtained through the DB Gateway compromise, could be used to retrieve the primary key of any Cosmos DB account on demand [1][3]. Unlike a customer’s own primary or read-only keys, which Microsoft scopes to a single account, this master key worked across tenants, across Azure regions, and across every API surface Cosmos DB supports — SQL, MongoDB, Cassandra, and Gremlin alike [1][2]. Possession of a target account’s primary key confers full administrative data-plane access: an attacker could read, modify, or delete any document in that account’s databases and containers, with no further authentication step standing in the way [1].

The master key’s reach did not stop at data access. It also unlocked the Cosmos DB Config Store, a regional directory that itself runs on Cosmos DB and holds metadata about every account on the service, including account names, subscription and tenant identifiers, network configuration, and tags [1][2]. Because the Config Store was queryable with the same master key, an attacker could enumerate the entire population of Cosmos DB accounts in a region or filter that population by subscription or tenant identifier to target a specific organization rather than attacking blindly [1][3]. Wiz noted that write access to the Config Store could also have permitted an attacker to alter network isolation settings on a targeted account, potentially defeating firewall or private-endpoint protections a customer believed were in force [1]. Given that Cosmos DB underpins internal Microsoft services such as Entra ID, Teams, and Copilot, the theoretical exposure extended beyond third-party customer data to Microsoft’s own operational and AI-service data stores, though Microsoft’s post-incident investigation found no evidence that this reach was ever exploited outside Wiz’s authorized testing [1][2].

Table 1 breaks the attack chain into its constituent architectural failures, each of which held on its own but which combined to convert a query-engine bug into a full-platform compromise.

Each of these individually reflects a familiar cloud security anti-pattern: insufficient sandboxing of user-supplied code, a service component provisioned with more privilege than its function requires, an authentication credential that lacks scoping boundaries, and a recursive trust relationship in which the directory of protected resources is itself protected by the same mechanism it is meant to safeguard. What makes CosmosEscape instructive is not that any single failure was novel, but that a hyperscale provider’s flagship database service — one long assumed to have “at least one strong isolation boundary around tenant-controlled execution,” as Wiz’s researchers put it in their writeup — still combined all four into a single exploitable chain [1]. The incident reinforces a principle central to cloud shared-responsibility discussions: however rigorously a cloud service provider engineers isolation, customers ultimately rely on architectural choices they cannot inspect or independently verify, and a single design flaw in a shared component can override every access control a tenant configured on their own account.

Recommendations

Immediate Actions

Organizations operating Azure Cosmos DB workloads should confirm that Microsoft’s fix has been fully applied to their accounts and should review Cosmos DB diagnostic logs and Azure activity logs for any anomalous data-plane access, unexpected key regeneration events, or unfamiliar source identities during the exposure window between the November 2025 report and the July 2026 remediation [2][3]. Because Microsoft has stated the master key is now eliminated rather than merely rotated, no customer-side key rotation is required to close this specific vulnerability, but organizations with heightened sensitivity — particularly those in regulated industries or storing data subject to breach-notification obligations — should still request written confirmation from Microsoft of the account’s remediation status and review whether the incident triggers any contractual or regulatory reporting duty.

Short-Term Mitigations

Security teams should treat this disclosure as an occasion to inventory which Cosmos DB accounts hold sensitive or regulated data and to verify that network isolation controls, such as private endpoints and firewall rules, are configured as an additional layer of defense rather than the sole control. Enabling and centrally monitoring Cosmos DB diagnostic logging, including data-plane request logs, allows anomaly detection to catch unusual query patterns or key-retrieval activity that would otherwise blend into normal platform telemetry. Organizations should also revisit vendor risk questionnaires for any cloud database or PaaS service to explicitly ask providers how shared query engines, gateways, and metadata directories are isolated between tenants, since this is precisely the class of internal architecture that customers cannot audit directly and must instead evaluate through provider disclosures and independent assurance reporting.

Strategic Considerations

CosmosEscape is a reminder that multi-tenant isolation failures are not confined to novel AI agent platforms; they can also surface in long-established, heavily used cloud infrastructure that has operated for years without a comparable public disclosure, and that a single overlooked mechanism — here, .NET reflection inside a query sandbox — can undo years of otherwise sound platform hardening. Enterprises should factor this pattern into cloud concentration risk assessments, recognizing that reliance on a single hyperscale provider for a critical data layer means inheriting that provider’s internal isolation architecture as an unauditable dependency. The involvement of AI-assisted research tooling in surfacing this flaw also suggests that defenders and attackers alike will increasingly use automated systems to probe cloud provider internals for exactly this kind of deep architectural weakness, and organizations may reasonably expect the pace of comparable disclosures to accelerate rather than slow, though this remains speculative based on a single case.

CSA Resource Alignment

CosmosEscape’s root cause — a single unscoped credential capable of impersonating any tenant — runs directly counter to the least-privilege and continuous-verification principles laid out in CSA’s Zero Trust Principles and Guidance for Identity and Access Management (IAM) [4]. That guidance argues that access decisions and the credentials that back them should be scoped as narrowly as possible to a specific protect surface rather than granted broadly for operational convenience; the Cosmos Master Key represents precisely the opposite design choice, and its elimination in Microsoft’s long-term fix is consistent with the scoped-credential model the guidance recommends, even though Microsoft’s public statements frame the change as a remediation rather than an adoption of any specific framework.

The incident is also relevant to CSA’s Navigating Identity and Access Management (IAM) [7], which surveys the standards and protocols organizations rely on to constrain what a given credential can reach. CosmosEscape shows what happens when a cloud provider’s own internal signing infrastructure does not follow that same discipline: because the Cosmos Master Key was valid across tenants, regions, and API surfaces rather than scoped to a protect surface of one, a single gateway compromise defeated every customer-side access control simultaneously.

The multi-tenant SaaS angle of this incident — a shared platform component whose compromise cascades into cross-customer exposure — is the same pattern CSA’s SaaS Security Capability Framework (SSCF) [8] is designed to help organizations evaluate in vendor architectures, particularly through its identity and access management domain covering session and credential scoping. Cosmos DB, like other PaaS and database services, increasingly sits underneath AI-facing workloads such as Copilot and enterprise agent platforms [1][2], and organizations evaluating such vendors should use SSCF and the AI Controls Matrix (AICM) v1.1’s identity and access management domain [6] as a baseline for the credential-scoping and tenant-isolation assurances to demand in vendor due diligence.

References

[1] Wiz Research. “CosmosEscape: Taking Over Every Azure Cosmos DB.” Wiz Blog, July 30, 2026.

[2] The Hacker News. “Azure Cosmos DB Flaw Exposed Platform-Wide Key That Could Access Any Database.” The Hacker News, July 2026.

[3] GBHackers. “CosmosEscape Vulnerability Enables Full Takeover of Azure Cosmos DB Databases.” GBHackers, July 2026.

[4] Cloud Security Alliance. “Zero Trust Principles and Guidance for Identity and Access Management (IAM).” Cloud Security Alliance, 2023.

[5] TechTimes. “CosmosEscape: Wiz Research Breached Azure Cosmos DB Gateway, Extracted Key to Every Database.” TechTimes, July 30, 2026.

[6] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” Cloud Security Alliance, 2026.

[7] Cloud Security Alliance. “Navigating Identity and Access Management (IAM).” Cloud Security Alliance, July 8, 2026.

[8] Cloud Security Alliance. “SaaS Security Capability Framework (SSCF).” Cloud Security Alliance, April 2026.