What happened
On November 20, 2025, Wiz disclosed a critical vulnerability in Azure Cosmos DB that could have allowed attackers to breach tenant boundaries and access any customer's database on the platform. Microsoft named this vulnerability CosmosEscape.
The attack exploited Cosmos DB's Jupyter Notebook feature. An attacker could run malicious code within their notebook environment to gain unauthorized access to the underlying infrastructure and then pivot to other customers' databases. This vulnerability didn't require stolen credentials or social engineering, just a standard Cosmos DB account with notebook access enabled.
Microsoft blocked the primary attack vector within 48 hours of disclosure and stated they found no evidence of exploitation in their logs.
Timeline
November 20, 2025: Wiz privately disclosed the vulnerability to Microsoft.
Within 48 hours: Microsoft blocked the Gremlin-based attack path that enabled the initial escape from the notebook sandbox.
Following weeks: Microsoft deployed additional isolation controls and monitoring across the Cosmos DB fleet.
Public disclosure: After Microsoft's remediation was complete and verified.
Which controls failed or were missing
The CosmosEscape chain revealed three distinct control failures:
Insufficient notebook sandbox isolation. The Jupyter Notebook environment didn't adequately restrict code access. An attacker could execute commands that reached beyond their allocated compute resources into the shared infrastructure layer. The sandbox should have been a hard boundary.
Overprivileged service identities. Once an attacker escaped the notebook sandbox, they landed in an environment where service components had broader access than necessary. These components could query metadata and connection details for other tenants' databases. The principle of least privilege wasn't enforced at the infrastructure level.
Weak tenant boundary verification. Systems managing database access didn't rigorously verify tenant context before serving connection strings and access tokens. An attacker who obtained a valid request format could retrieve credentials for databases they didn't own. There was no secondary check asking, "Does this service identity actually belong to the tenant requesting this resource?"
What the relevant standards require
ISO/IEC 27001:2022 Control 8.31 (Separation of development, test, and production environments) extends to multi-tenant cloud services. Isolation boundaries must be technically enforced, not just logically defined. Your cloud provider should demonstrate that tenant A's compute cannot access tenant B's data, even if both run on shared infrastructure.
NIST 800-53 Rev 5 Control SC-32 (System Partitioning) requires systems to "partition system components into separate execution domains" to minimize the impact of component compromise. In a multi-tenant database service, this means your notebook environment, data plane, and control plane should operate in isolated domains with explicit trust boundaries between them.
SOC 2 Type II Common Criteria CC6.6 (Logical and Physical Access Controls) requires entities to restrict access to system resources. For cloud providers, this includes demonstrating that one customer cannot access another customer's logical resources. Your SOC 2 report should include testing of these tenant isolation controls, not just perimeter access controls.
PCI DSS v4.0.1 Requirement 3.5.1 states that cryptographic keys must be restricted to the fewest number of custodians necessary. In a cloud context, this extends to service identities. The service components managing your encrypted data shouldn't have standing access to decrypt other tenants' data. If they do, you're violating the custodian restriction principle.
Lessons and action items for your team
Map your cloud service isolation boundaries. Don't assume your cloud provider has perfect tenant isolation. Document which services you use that involve shared infrastructure (managed notebooks, serverless functions, container orchestration). Ask your provider: what prevents my workload from accessing another tenant's resources? Request architecture diagrams showing isolation mechanisms.
Replace static database keys with managed identities. If you're still using Cosmos DB's primary keys or connection strings in your application code, you're expanding your blast radius. Switch to Azure Managed Identity or service principals with time-limited tokens. This won't prevent a provider-level compromise, but it limits what an attacker can do with stolen credentials from your application layer.
Audit your service principal permissions quarterly. Review every service identity that can access your cloud databases. Apply the same least-privilege analysis you'd use for human accounts. If a service principal has read access to all databases "for convenience," scope it down to specific collections or documents. Document why each permission exists.
Require evidence of tenant isolation testing in vendor assessments. When you evaluate cloud services, ask for proof that they test cross-tenant access controls. Look for penetration testing reports that specifically attempted tenant boundary escapes. A SOC 2 Type II report should include control tests for logical isolation, not just physical datacenter access. If the report doesn't mention tenant isolation testing, ask why.
Enable cloud provider audit logging at the control plane. For Azure, that's Azure Activity Log with long-term retention. For AWS, it's CloudTrail. You want a record of who accessed your database metadata and connection details, not just who queried your data. In a CosmosEscape-style attack, the attacker might never touch your data plane, they'd steal credentials from the control plane.
Test your own isolation if you run multi-tenant services. If you built a SaaS application on top of Cosmos DB or any shared database, you have your own tenant isolation to verify. Can customer A's API requests access customer B's data through parameter manipulation or privilege escalation? Hire someone to test this annually. The fact that your cloud provider has isolation controls doesn't mean your application layer does.
The CosmosEscape vulnerability was a cloud provider failure, but your response shouldn't be to wait for the next one. Treat tenant isolation as a testable security control, not an assumed property of cloud infrastructure.
