ChaosDB - A Notebook Feature in a Managed Database → Local Privilege Escalation → Firewall Rules Rewritten → Full Admin on Other Tenants' Databases
In August 2021 Wiz researchers found that the Jupyter Notebook feature added to Azure Cosmos DB in 2019 could be used to escalate out of a customer's own notebook container, reach the Cosmos DB backend, and retrieve the primary keys of other customers' databases. The result was complete unrestricted read, write and delete access to the accounts and databases of several thousand Azure customers, including many in the Fortune 500. Microsoft disabled the feature within roughly 48 hours of the report and advised every Cosmos DB customer to regenerate their primary keys. Like the Entra ID Actor token flaw, this was research rather than a breach - but it is the more fundamental one. Actor tokens broke authentication. ChaosDB broke tenant isolation, the property every multi-tenant cloud service is built on, and the one customers have no ability to verify or compensate for.
The feature is genuinely useful - query your data, visualize it, run Python next to it, without moving anything. It is also, structurally, the provider offering to run arbitrary customer code inside its own managed service, which changes the isolation problem completely. A managed database normally exposes a query interface; adding notebooks means the provider now has to contain a general-purpose runtime, per tenant, correctly. Wiz's later PEACH framework grew out of exactly this class of finding: the more capability a managed service offers inside the tenant boundary, the more surface there is for that boundary to fail on.
Enabled: By default for Cosmos DB accounts
What it changes: The provider must now contain a general-purpose runtime per tenant
Customer visibility: None into how that containment is implemented
Later formalized as: Wiz's PEACH tenant isolation framework
The chain ran from inside the customer's own notebook: escalate locally within that environment, then modify the firewall rules constraining it, and the network restrictions that were supposed to keep a tenant's notebook talking only to that tenant's data no longer applied. From there the backend was reachable directly. Each individual step is a familiar container-security problem - a local escalation, a network control that could be changed from inside the thing it was containing - but the consequence is not, because the blast radius of a container escape in a multi-tenant managed service is every other tenant on it.
Step 2: Modify firewall rules to remove network restrictions
Step 3: Reach and authenticate to the Cosmos DB backend directly
Why it is different from a normal escape: The blast radius is every other tenant
Control that failed: A network boundary changeable from inside the thing it contained
The prize was the primary keys - Cosmos DB's long-lived, full-privilege credentials. With them, an attacker has complete administrative control of a victim's database from anywhere on the internet, independent of the vulnerability that produced them. Two consequences follow. First, the access is not bounded by the flaw's lifetime: a key obtained in August 2021 keeps working until it is rotated, which is why Microsoft's advice was to regenerate keys rather than simply to apply a fix. Second, because these keys are long-lived by design and rarely rotated in practice, the honest position for any customer was to assume exposure over an extended window rather than a moment.
Access granted: Full read, write and delete, from anywhere
Key property: Long-lived and rarely rotated, so the access outlives the vulnerability
Microsoft's advice: Regenerate primary keys - not merely wait for the fix
Honest customer position: Assume exposure across months, not a moment
This is the point of including a research finding on a page of breaches. Every customer-side control the industry recommends was irrelevant here: network restrictions, least privilege, MFA, encryption at rest, private endpoints. None of them sit between one tenant's notebook and another tenant's keys, because that boundary is the provider's to enforce and the customer has no visibility into it. It maps directly onto the shared responsibility model - isolation is unambiguously the provider's side of the line - and it is the clearest available demonstration that the provider's side is not a formality. Microsoft disabled the feature within about 48 hours, which is a genuinely fast response, and notified affected customers.
Customer controls that would have helped: None
Whose responsibility: Tenant isolation is unambiguously the provider's
Microsoft response: Feature disabled within ~48 hours; affected customers notified
The uncomfortable part: You cannot audit, test or compensate for this boundary