Within 48 hours of a November 2025 report, Microsoft shut down a Gremlin entry point that could have let attackers walk away with a platform‑wide signing secret. That rapid response capped a chain researchers at Wiz dubbed CosmosEscape, which exposed a single key that could unlock any Cosmos DB account across tenants.
Key Takeaways
- Crafted Gremlin queries could break out of the sandbox and run.NET code on a multi‑tenant gateway.
- The gateway stored a Cosmos Master Key that could fetch primary keys for any account, regardless of region or API.
- Microsoft patched the vulnerable Gremlin engine in two weeks and removed the master key by July 2026.
- No evidence of customer data being accessed; Microsoft found no unauthorized activity.
- Developers should rotate primary keys and audit network‑isolated Cosmos DB instances.
Historical Context
Azure Cosmos DB launched in 2017 as a globally distributed, multi‑model database service. Early on, Microsoft emphasized its ability to support document, key‑value, graph, and column‑family workloads from a single endpoint. Over the years, the platform added native support for the Gremlin graph language, letting developers query relationships without building custom layers.
That flexibility also meant a growing attack surface. In 2021, the community saw the ChaosDB vulnerability, which involved Jupyter Notebook integration and exposed internal keys. A year later, CosMiss highlighted configuration‑driven leakage in the same service. Both incidents required the attacker to interact with publicly exposed components.
CosmosEscape differs in its starting point. Instead of a public notebook, the exploit began inside a Gremlin database that the attacker already controlled. The chain used a rarely touched translation layer, showing how legacy code paths can become a hidden doorway when new features are layered on top.
Microsoft’s response timeline mirrors its past handling of similar bugs. The company typically moves quickly to block public entry points, then rolls out a broader remediation across regions. The two‑week window between the public disclosure and the Gremlin engine patch aligns with the pattern seen after earlier Cosmos DB bugs.
Azure Cosmos DB vulnerability: How the platform key was exposed
Wiz’s write‑up shows the exploit started with a Gremlin database the attacker already controlled. By feeding a specially crafted query, the team triggered.NET reflection inside Cosmos DB’s custom Gremlin engine. That broke the sandbox, letting them read and write files before they achieved arbitrary code execution.
From sandbox escape to gateway takeover
Once the code ran, it landed on a component Wiz calls the DB Gateway. The gateway sits on Azure Service Fabric clusters that serve many customers at once. It isn’t where the actual data lives, but it does hold credentials needed to service queries.
Because the gateway could retrieve the primary key for any requested Cosmos DB account, the researchers could ask it for the key belonging to a target tenant. That primary key, per Microsoft docs, grants full control over every resource in the account – databases, containers, even network settings.
The master signing secret
Even more alarming was the signing key the gateway used to sign internal requests. Wiz named it the Cosmos Master Key. With that secret, an attacker could generate a request that the gateway would accept for any account, across all supported APIs – SQL, MongoDB, Cassandra, and Gremlin.
Wiz also uncovered a regional Config Store, a database that listed every Cosmos DB account name, subscription ID, tenant ID, and network configuration. By querying that store, an adversary could locate a specific organization’s accounts and then pull their primary keys using the master key.
Technical Architecture Deep Dive
The DB Gateway is a thin service running on Azure Service Fabric. Service Fabric provides micro‑service orchestration, health monitoring, and automatic scaling. In Cosmos DB’s design, the gateway forwards incoming queries to backend storage nodes after performing authentication and request signing.
Authentication relies on a hierarchy of keys. At the top sits the Cosmos Master Key, which the gateway uses to sign internal service‑to‑service calls. Below that are per‑account primary keys, which clients present to prove ownership of a specific database. The master key can therefore derive any primary key on demand.
When the exploit reached the gateway, the malicious code could call the same internal APIs that legitimate components use. By invoking the key‑retrieval endpoint, the attacker bypassed the usual client‑side restrictions. The result was a single secret that opened every lock in the system.
Service Fabric itself isolates workloads at the process level, but the gateway runs with elevated privileges to perform its duties. That privilege level is why the breach could read the Config Store and write files. The sandbox escape essentially elevated the attacker from a low‑privilege script to a full‑service participant.
Microsoft’s later fix removed the master key from the gateway’s runtime. Instead, each request now requires a per‑tenant token generated by a dedicated key‑management service. This redesign reduces the blast radius of any single compromised component.
Microsoft’s response timeline
Microsoft blocked the vulnerable Gremlin entry point within 48 hours of the initial public report in November 2025. The longer‑term fix, which eliminated the master key and closed the signing‑key path, rolled out across all regions in July 2026.
“We appreciate Wiz’s work in identifying and reporting this issue through coordinated vulnerability disclosure,” a Microsoft spokesperson told The Hacker News. “We have fully addressed the issue and found no evidence of customer impact based on our investigations. We continue to invest in additional security enhancements across the platform.”
Microsoft’s internal review found no unauthorized activity beyond the researchers’ testing. It said no customer data was accessed and that no action was required from customers.
What the exploit reveals about multi‑tenant services
The chain underscores how a single mis‑configured component can become a universal backdoor in a multi‑tenant environment. The DB Gateway enforced network boundaries from inside the service, meaning even private or isolated accounts could have been compromised.
Wiz noted that the write access to the Config Store hinted at the possibility of altering network settings, though they didn’t demonstrate changing another tenant’s configuration.
- Primary key = full control over an account.
- Master key = ability to fetch any primary key.
- Config Store = directory of account metadata.
Microsoft documentation says Teams message data lives in Cosmos DB, and an engineering post confirms Copilot stores query histories there. While Wiz didn’t claim to have accessed those datasets, the potential exposure of such high‑value data is concerning.
Comparisons to past Cosmos DB flaws
This vulnerability is technically separate from the ChaosDB and CosMiss flaws disclosed in 2021 and 2022, which involved the Jupyter Notebook feature. Those earlier bugs also used internal keys, but they required different attack surfaces.
Unlike the earlier issues, CosmosEscape hinged on the Gremlin engine’s translation layer, a part of the service that most customers never touch directly. That makes it a classic case of “you don’t see it, so you don’t think about it.”
Practical steps for developers and operators
If you’re running Cosmos DB, start by rotating your primary keys. Even though Microsoft says no keys were leaked, rotating eliminates any lingering risk from the window before the patch.
Audit your network isolation settings. The exploit could have reached private endpoints because the gateway enforced those rules from inside. Verify that your firewall rules and private link configurations are still intact.
Enable Azure Monitor alerts for unusual gateway activity. While Microsoft’s logs didn’t show abuse, having your own telemetry can catch future attempts early.
What This Means For You
For developers, the key lesson is to treat every service component as a potential attack surface, even ones that seem abstracted away like query translators. Don’t assume that a sandboxed language runtime can’t be broken out of – especially when it compiles to a powerful platform like.NET.
For builders of SaaS platforms, the CosmosEscape story is a reminder that shared infrastructure must be designed with zero‑trust principles. If a single service can issue a signing request for any tenant, the whole ecosystem is at risk.
Going forward, you’ll want to keep an eye on Microsoft’s security bulletins and consider implementing automated key rotation via Azure Key Vault. That way, even if a future flaw surfaces, the blast radius stays limited.
Will Azure’s next‑generation Cosmos DB architecture incorporate hardware‑based isolation to prevent this kind of cross‑tenant key leakage? Only.
Concrete Scenarios for Different Stakeholders
Imagine a startup that uses Cosmos DB to store user profiles and relies on private endpoints for compliance. If an attacker gained access to the master key, they could retrieve the startup’s primary key and modify user data at will. The breach would be invisible to the application layer because the gateway would still appear healthy.
Consider a financial services firm that runs analytics workloads on a dedicated Cosmos DB region. The firm may have network‑isolated clusters that prevent inbound traffic. Yet the gateway’s internal signing path could bypass those restrictions, allowing an adversary to inject malicious queries that corrupt transaction logs.
A gaming platform that serves real‑time leaderboards across continents often uses the Gremlin API for graph‑based matchmaking. In this case, the exploit could have let a malicious player fetch the platform’s master key, then forge requests that alter leaderboard scores or expose other players’ statistics.
All three examples share a common thread: the underlying secret gives unrestricted access. Rotating keys, tightening gateway monitoring, and segmenting services reduce the chance that any single breach can cascade into a wider compromise.
Key Questions Remaining
- Will Microsoft publish a detailed post‑mortem that includes root‑cause analysis of the Gremlin engine’s reflection bug?
- How will future updates to Azure Service Fabric address the privilege model of gateway‑type services?
- Can customers rely on Azure’s built‑in key‑rotation features, or should they adopt an external secret‑management solution for defense‑in‑depth?
- What monitoring signals are most indicative of a gateway‑level compromise, and how can they be surfaced in existing Azure Sentinel dashboards?
- Will the industry adopt a standardized “no master key” design for multi‑tenant databases, or will vendors continue to rely on internal signing secrets?
Answers to these questions will shape how cloud providers think about shared components. The community will watch closely for any follow‑up guidance from Microsoft.
Sources: The Hacker News, Microsoft Documentation
