CosmosEscape: the explosion that turns a Gremlin sandbox into full access to Cosmos DB multitenant

A Wiz research team discovered and reported a chain of exploitation in Azure Cosmos DB, which, according to its public report, allowed to escape from the Gremlin engine sandbox and to climb up to get reading and writing access on multi-tenant Cosmos DB accounts. Vulnerability - co-called CosmosEscape by researchers - combined an injection in Gremlin consultations with the ability to invoke .NET reflections within the custom engine, which facilitated file reading / writing primitives and, finally, code execution in a multi-tenant component of the service.

According to Wiz and Microsoft's public response, the proven initial vector was based on a Gremlin database controlled by the attacker and the credentials of that account; from there the execution moved to the component that Wiz calls DB Gateway, which runs in Service Fabric's shared clusters. This component had access to a platform signature key that allowed for the recovery of the primary accounts keys of Cosmos DB in different regions, APIs (SQL, MongolDB, Cassandra and Gremlin) and tenant levels, and there was also a regional warehouse (Config Store) with metadata and account / tenant mapping that would facilitate targeting.

Microsoft blocked the vulnerable entry point in less than 48 hours since the report received in November 2025 and completed a wider arrangement in July 2025, including the removal of the platform signature key as reported. Microsoft claims not to have detected unauthorized activity outside the researchers' tests and that it was not necessary for customers to take action Although the company did not yet publish a CVE or a full exposure period and the historical risk window is not fully clarified in public documentation.

The technical implications of this finding are relevant to any architect or responsible for cloud security: a leak from an execution sandbox to a multi-tenant gateway component can convert apparently limited credentials into full access to resources if there are secrets with global scope within the platform. This underlines the critical importance of the separation of privileges between data and control, as well as of avoiding secrets with massive scope within shared services.

For security teams and managers of Cosmos DB, careful immediate actions include asking Microsoft for a detailed report of the revised scope and period covered by its log review, confirming whether its account (s) were listed in the Config Store and asking for key rotation in case there was indirect risk. In addition, it is appropriate to activate and review diagnostic logs, to retain sufficient evidence for forensic hunts and to apply primary key rotation / regen if there is the least doubt. It is also recommended to validate network isolations (Private Link, VNET) and the existence of additional control measures such as the use of customer-managed identities and keys (CMK).

In terms of long-term mitigation, suppliers and customers should prioritize mechanisms that reduce the blast radius of any committed secret: segregate components that process customer consultations, remove global credentials, apply less privileged principle in each service and subject infrastructure changes to security reviews and penetration tests that include sandbox escape scenarios and reflection abuse in managed environments. In-depth defence and early detection capacity are the best guarantees against design failures in multi-tenant services.

Wiz has announced that he will present the complete chain in Black Hat USA, which will allow to technically review the exact conditions of the explosion, its robustness and limitations. To know these details it is reasonable to assume uncertainties about the initial requirements and the extensibility of the attack, so conservative mitigation measures and pressure to obtain an official breakdown remain recommended. The public resources of Wiz and Microsoft's documentation on Cosmos DB are available for official disclosure and chronology: Wiz and Azure Cosmos DB (Microsoft Learn). The conference presentation will also be available on Black Hat channels: Black Hat.

Finally, for risk and compliance equipment it is important to ask Microsoft for written confirmation of the scope of the log review, to request commitment indicators related to the reported chain and to require immediate notification of any retroactive finding. The absence of verifiable exposure today does not replace a proactive response: rotating secrets, tightening access and improving monitoring are steps that reduce the risk to future vulnerabilities of the platform.