Azure CosmosEscape Flaw Exposed Any Tenant's Database

Security firm Wiz disclosed a now-patched attack chain in Azure Cosmos DB that they named CosmosEscape. Starting from a crafted query against an attacker-controlled Gremlin database, the chain escaped Cosmos DB’s query sandbox, achieved code execution on shared platform infrastructure, and extracted a platform-wide key capable of reading and writing data across any customer’s Cosmos DB — regardless of tenant boundary. The Hacker News has the full write-up with details from Wiz’s research.

Microsoft has patched the vulnerability. No CVE has been publicly assigned; this was handled through Wiz’s responsible disclosure process.

What “cross-tenant” actually means here

Azure Cosmos DB is shared infrastructure. Multiple customers’ databases run on the same underlying platform. The platform-wide key Wiz extracted wasn’t scoped to one tenant — it could grant full read and write access to databases across the entire service.

That’s a category of failure different from a single-account compromise. An attacker who completed this chain could have read or modified any customer’s Cosmos DB data: application records, user data, transaction logs, anything stored in the service. The attack required the attacker to have their own Cosmos DB account as the starting point. Internal cloud APIs aren’t typically in scope for external threat models, which is exactly why this kind of lateral path gets overlooked.

What to do

Microsoft says the vulnerability is patched at the platform level — no customer-side action is required to close the technical gap. But “patched” doesn’t answer what happened before the fix landed.

If your organization has sensitive data in Azure Cosmos DB:

1. Request Azure activity logs for your Cosmos DB accounts. Look for anomalous API calls, unexpected reads against large datasets, or queries that don’t match your application’s normal access patterns. Cosmos DB diagnostic logs in Azure Monitor can be configured to capture data-plane operations if they aren’t already.
2. Identify what data was at risk. Which Cosmos DB accounts hold data that, if read by an unauthorized party, requires notification or downstream action? Document it now — before anyone asks.
3. Check for data integrity issues. The chain allowed write access as well as read. If your data has integrity-critical fields, compare current state against backups or audit logs from the exposure window.
4. Update incident response runbooks to include cloud platform-layer events. A vulnerability like this doesn’t trigger host-based or network-based detection. It lives entirely within the cloud provider’s infrastructure. If your IR process only looks at what’s in your own logs, you’d have missed this.

If your Cosmos DB accounts don’t hold sensitive data or you don’t use the Gremlin API — verify that before deciding it doesn’t apply.

Priority call

The vulnerability is patched. The immediate fire is out.

The harder question is investigative: could this have been exploited against your data before the fix, and would you be able to tell? Azure’s logging for Cosmos DB is off by default on most configurations. If you weren’t running diagnostic logs, you don’t have a retroactive view.

Cloud isolation boundaries failing is not a new category of problem — it has happened across providers. What’s different each time is how far someone who exploited it could reach. In this case: any tenant, full access.

If you’re not already running Cosmos DB diagnostic logging, turn it on now. After that, decide how much of the pre-patch window you need to reconstruct.

Sources: The Hacker News (citing Wiz research).