Skip to content
HACKTECH
Cloud & identityReported Published 3 sources

CosmosEscape: Azure Cosmos DB flaw exposed a platform key that could open any account

Wiz Research disclosed on 30 July 2026 a vulnerability chain in Azure Cosmos DB's Gremlin API that it named CosmosEscape. Wiz said the restrictions Cosmos DB's engine applied to Gremlin queries did not sufficiently account for .NET reflection, allowing code execution on the multi-tenant DB Gateway, where a signing key it dubbed the 'Cosmos Master Key' could retrieve the primary key of any Cosmos DB account across tenants, regions and API types. Microsoft deployed a mitigation within 48 hours of the 20 November 2025 report and completed a long-term fix across all regions in July 2026. Microsoft said extensive reviews of access logs found no evidence of unauthorised activity outside the researchers' testing and that no customer action is required.

  • Azure
  • Cosmos DB
  • tenant isolation
  • cloud control plane
  • Wiz
  • Gremlin API
  • managed identities

What the sources report

  • Wiz's disclosure timeline: reported 20 November 2025; Microsoft hot fix 22 November 2025; long-term fix rolled out across all regions in July 2026; public disclosure 30 July 2026.
  • Wiz said the key also opened the regional Config Store, which held account names, subscription IDs, tenant IDs, network settings and tags, enabling an attacker to list all accounts in a region or query by tenant ID to find a specific organisation's databases.
  • Wiz said private and network-isolated accounts were affected because the DB Gateway is responsible for enforcing network isolation, and that the databases of Microsoft Entra ID, Teams and Copilot, which store data in Cosmos DB, were potentially accessible.
  • Wiz told The Hacker News the only prerequisite was a standard Azure account with an attacker-controlled Cosmos DB Gremlin database; the disclosure lists no CVE identifier or severity score.
  • According to Wiz, Microsoft eliminated the Cosmos Master Key and introduced new guardrails to Cosmos DB to prevent similar attacks.
  • CSO Online reported an IDC analyst's view that Gremlin API users should review available logs and that organisations should reduce reliance on static database account keys through managed identities, fine-grained role-based access control and client-side encryption where practical.

What it means for your organisation

CosmosEscape shows tenant isolation failing beneath the layer customers configure: Wiz said the DB Gateway it compromised was the component responsible for enforcing customers' network isolation. Customers had nothing to patch, but they do decide how much a single database key can open, since a primary key grants full read-write access while identity-based access and client-side encryption limit what any one secret exposes. The Hacker News notes it is technically separate from the ChaosDB and CosMiss Cosmos DB flaws disclosed in 2021 and 2022, which is a reason for cloud threat models to plan for provider-side failure rather than treat it as an edge case.

What we check

  • Check whether Cosmos DB and other managed databases still accept account-key authentication, and whether key-based access can be disabled in favour of Entra ID role-based access and managed identities.
  • Locate every stored account key and connection string (app settings, pipelines, developer machines) and confirm rotation is scheduled and tested.
  • Identify the most sensitive fields and assess client-side or application-level encryption so a storage-layer key alone does not yield plaintext.
  • Confirm data-plane diagnostic logs are enabled and retained long enough to check provider advisories against your own records.
  • Check whether cloud threat models and incident response plans cover a provider-side isolation failure, including how to obtain assurance from the provider when regulators ask.

Sources

Services that cover these checks

  • Cloud configuration review

    An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.

    Duration: 4 to 8 working days

  • Database security audit

    A configuration and access review of your production databases: who can connect, from where and with which privileges, whether data is encrypted at rest and in transit, what is logged, and whether backups would survive the same attacker. We read each instance's live configuration.

    Duration: 3 to 7 working days

  • Threat modelling

    Facilitated workshops that map how a system or feature could be attacked before it is built or shipped. We draw the data flows with your engineers, walk them with STRIDE, rank the threats by likelihood and impact, and turn the result into backlog items and test cases your team owns.

    Duration: 2 to 5 days per system, remote or on site

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works