In November 2025, Wiz researchers ran a Gremlin query against Azure Cosmos DB and walked out with a signing key that could unlock any customer’s database on the entire service — every API surface, every region, every tenant, no relationship to the victim required beyond knowing its account name. Microsoft didn’t publish a CVSS score. It didn’t assign a CVE. It called CosmosEscape a “cloud-service-side fix,” which is Microsoft’s polite way of saying: this was never your bug to have, and there was nothing you could have patched.

Here’s the part that should bother you more than the bug itself. In August 2021, Wiz disclosed ChaosDB — a different vulnerability chain, in the same product, that also ended with an attacker holding the keys to every Cosmos DB tenant on the platform. Five years, two unrelated root causes, one outcome: the promise that your data plane is walled off from every other Azure customer’s data plane turned out to rest on a single shared secret that shouldn’t have existed either time.

Cosmos DB isn’t uniquely cursed. It’s just the clearest illustration of a bug class that had five headline instances in the last twelve months across three different hyperscalers, and that most infrastructure teams have no process for even asking about, let alone testing.

What “cross-tenant” actually means, and why it’s the worst bug class in cloud

Every other vulnerability category in this publication has a boundary you control. A code injection bug in your web app is bad, but it’s your app, on your infrastructure, and you own the fix and the timeline. A cross-tenant break in a managed cloud service is different in kind: the vulnerable component is entirely vendor-operated, you have no visibility into whether you were exposed, no ability to test for it yourself, and no patch to apply — you’re simply told, after the fact, that a stranger could have read or written your data, and asked to trust that they didn’t.

That asymmetry is why cross-tenant bugs deserve more attention than their CVSS scores usually get (when they get scored at all — CosmosEscape has none). A SQL injection in an app with 10,000 users affects one blast radius. A shared master key sitting behind a multi-tenant database gateway affects every customer of that service simultaneously, and the only thing standing between “vulnerability” and “mass breach” is whether a researcher or an attacker found it first.

The 2026 casebook

Five incidents, five different products, one recognizable shape.

CosmosEscape (Azure Cosmos DB, reported November 2025, remediated July 2026). Wiz chained a .NET reflection bypass in the Gremlin query sandbox into code execution on Microsoft’s shared multi-tenant DB Gateway, then found a platform-wide Cosmos Master Key sitting in reach — a signing secret not scoped to any tenant, account, or region. With it, an attacker could retrieve the primary key for any Cosmos DB account on the service and authenticate directly, full read/write, across SQL, MongoDB, Cassandra, and Gremlin APIs alike. Static allow-lists blocked the obvious Gremlin operations; nobody accounted for reflection reaching arbitrary .NET types by name.

Pickle in the Middle (Google Vertex AI SDK, reported March 2026, patched April 2026). Unit 42 found that Model.upload() in the Vertex AI Python SDK generated a predictable staging-bucket name from the caller’s project ID and region when staging_bucket was left unset. Cloud Storage bucket names are globally unique, so an attacker who knew a victim’s project ID — frequently public — could pre-create the expected bucket in their own project and let the victim’s SDK upload straight into attacker-controlled storage. Swap the model artifact for a malicious pickle, wait roughly 2.5 seconds for Vertex AI to deserialize it inside the serving container, and you have code execution with a metadata-server OAuth token that reached other tenants’ model weights, BigQuery metadata, and cluster names. This was the second predictable-bucket bug in Vertex AI in 2026 — Google had already patched a near-identical flaw in Vertex AI Experiments (CVE-2026-2473) in February.

CVE-2025-55241 (Entra ID Actor tokens, disclosed September 2025). Dirk-jan Mollema found that an undocumented “Actor token” mechanism, used internally by Microsoft services to act on behalf of users, could be requested from an attacker’s own tenant and then presented to the legacy Azure AD Graph API in a completely different tenant — because that API never reliably validated which tenant the token actually originated from. The result: impersonate any user, including Global Administrators, in any other Entra tenant, bypassing MFA and Conditional Access, while leaving almost nothing in the audit log. CVSS 10.0. This is the oldest incident in this casebook and arguably the cleanest teaching example: a control-plane component built for internal convenience, exposed to a trust boundary it was never designed to cross.

Entra Agent ID Administrator service principal takeover (CVE-2026-35431, disclosed April 2026). Microsoft shipped a new built-in role, Agent ID Administrator, scoped on paper to managing AI agent identities. In practice the role’s permissions let a holder take ownership of any service principal in the tenant — not just agent-backed ones — because the filter that was supposed to restrict ownership changes to agent objects didn’t exist. Three Graph API calls (enumerate privileged service principals, add yourself as owner, inject a credential) turned a preview-feature role into a de facto second Application Administrator. Silverfort, who found it, drew the direct line back to CVE-2025-55241: a new capability layered onto an old primitive (the service principal) without re-deriving the scope from scratch.

AKS Backup Trusted Access confused deputy (disclosed publicly May 2026, reported March 2026). Researcher Tal O’Leary found that Azure Backup for AKS’s “Trusted Access” relationship granted the backup extension cluster-admin privileges inside the Kubernetes cluster, and that a user holding only the Backup Contributor Azure RBAC role — which has zero native Kubernetes permissions — could enable that Trusted Access relationship and ride it straight to cluster-admin. Microsoft’s own MSRC initially dismissed the report; CERT/CC independently validated it and assigned VU#284781 three days later. Microsoft silently changed Trusted Access to require manual configuration rather than issuing a public advisory — a pattern of vendor response that’s arguably as much the story here as the bug.

The pattern behind all five

Strip away the product names and every one of these reduces to the same failure: a privileged, shared control-plane component trusted something it should have verified independently per tenant — a bucket name, a token’s origin claim, a role’s object filter, an RBAC-to-RBAC trust relationship, or a signing key with no tenant scope at all. Norman Hardy named this in 1988 as the confused deputy: a high-privilege program tricked by a low-privilege caller into using its own authority on the caller’s behalf. Cloud control planes are confused-deputy machines by construction — they exist specifically to act with elevated privilege on behalf of millions of less-privileged tenants — and 2026 is the year that became impossible to ignore. Tal O’Leary’s Black Hat USA 2026 talk on exactly this pattern across Azure and GCP, “Trust No Deputy,” is a symptom of the same trend, not a coincidence.

Three sub-patterns are worth naming individually because they call for different defenses:

  1. Global secrets in multi-tenant infrastructure. CosmosEscape’s master key is the purest version: one credential, unscoped, sitting behind a sandbox that was assumed sufficient on its own. Any architecture where a single key or token grants access to more than one tenant’s data is a latent CosmosEscape waiting for someone to find the sandbox’s weak point.
  2. Predictable or guessable identifiers crossing a global namespace. Vertex AI’s staging buckets and (per Wiz’s own writeup) Cosmos account names both rely on an attacker being able to guess or discover an identifier in a globally shared namespace, then pre-position themselves at that identifier before the victim gets there. This is a race condition at the naming layer, not the code layer.
  3. New feature, old primitive, un-rederived scope. Both Entra incidents are this: a new capability (Actor tokens for internal services, Agent ID Administrator for AI agents) gets bolted onto an existing, broadly-trusted primitive (arbitrary user impersonation, service principal ownership) without anyone re-deriving what the new feature’s blast radius should be. Expect more of this specifically wherever vendors are racing to ship AI-agent identity features in 2026 — that’s precisely the seam Silverfort and Mollema both found.

Why vendors keep shipping this

None of these five bugs happened because engineers at Microsoft or Google are careless. They happened because multi-tenant cloud platforms are under permanent pressure to ship new capabilities fast — AI agent identity, managed backup, SDK convenience defaults — and every new capability is a new opportunity to implicitly extend an old trust boundary. Tenant isolation isn’t a feature you build once; it’s a property you have to re-verify against every single change to a shared component, forever, and that discipline scales worse than almost anything else in a cloud provider’s engineering org.

The AKS Backup case adds an uglier wrinkle: MSRC’s first response was to dismiss the report. That’s not a technical failure, it’s a triage failure, and it means the population of undiscovered bugs in this class is larger than what gets a CVE — some of it is sitting in a “won’t fix” queue right now because the reviewer didn’t recognize a confused-deputy chain when they saw one.

A framework for the boundary you can’t see: PEACH

You cannot audit Microsoft’s Gremlin sandbox or Google’s Vertex AI serving containers. But Wiz’s own PEACH framework — published after ChaosDB, evidently not yet fully internalized before CosmosEscape — gives you a vocabulary for the questions to ask any vendor, and a checklist for any multi-tenant system you operate:

  • Privilege hardening — do tenants and the shared host process run with minimal permissions, or does a compromise of the host process (the DB Gateway, the serving container) hand over everything?
  • Encryption hardening — is each tenant’s data encrypted with a key unique to that tenant, or is there one key (or one KMS scope) covering everyone?
  • Authentication hardening — does every control-plane call carry a credential cryptographically bound to a single tenant, or is there a shared secret, a shared service account, or an internal token type (looking at you, Actor tokens) that multiple tenants’ requests can produce?
  • Connectivity hardening — can a tenant’s workload reach the orchestrator or control-plane network at all, or is that path closed by default?
  • Hygiene — are certificates, keys, and tokens scoped and rotated such that a leak in one place can’t be replayed somewhere else?

If you run a multi-tenant SaaS or PaaS product yourself — and a meaningful fraction of this publication’s readers do — run your own architecture through those five questions before an external researcher does it for you. If you’re a customer of a hyperscaler’s managed service, use PEACH’s language in vendor security reviews and RFPs: ask, specifically, whether any platform-wide credential exists behind the service, and how per-tenant isolation is proven, not asserted.

What to actually do about a bug class you can’t patch

Most of the mitigation here is vendor-side by definition — that’s the uncomfortable truth of managed services. But “there’s nothing to patch” is not the same as “there’s nothing to do.”

  • Kill static long-lived keys wherever a workload-identity alternative exists. Every one of these vendors offers an IAM-based alternative to static keys — Entra ID / Azure AD auth for Cosmos DB, workload identity federation for GCP, IAM roles for AWS. A leaked or forged key is a full-account compromise with no scoping and no fast revocation path. A compromised identity can be scoped, conditional-access-gated, and revoked in seconds. Cosmos DB customers who’d already moved to Entra-based RBAC auth were never exposed to the master-key path at all.
  • Set explicit resource names; never trust SDK defaults in a shared namespace. The Vertex AI bug only worked because staging_bucket was left unset. Any time an SDK auto-generates a resource name in a globally-unique namespace (buckets, DNS names, package registries), treat the default as an attack surface and pin it yourself.
  • Audit who holds “preview” and “AI agent” roles in your identity provider today. Both Entra incidents trace to new roles shipped for AI-agent-identity plumbing. If you enabled Microsoft Agent Identity Platform or any equivalent GCP/AWS agent-identity preview, pull the audit log for every credential and ownership change made by a holder of those roles since GA, not just since the patch date.
  • Instrument control-plane audit logs for the specific actions these bugs abuse — Add owner to service principal, key-based authentication from unfamiliar ranges, Trusted Access / cross-service role bindings being enabled — even though you can’t detect the underlying vulnerability, you can detect its abuse pattern.
  • Ask your vendors the CosmosEscape question directly, in writing, for every managed service you depend on: does a platform-wide signing key or shared control-plane credential sit behind this service, and what happens to my tenant if it leaks? Most vendors have never been asked and don’t have a rehearsed answer. That’s diagnostic in itself.

The uncomfortable conclusion

The shared responsibility model has a silent asterisk at the tenant-isolation layer: you are responsible for nothing there, because you’re capable of nothing there. You can’t pen-test it, you can’t monitor it, you can’t even confirm you were safe during the exposure window — you get a blog post, months later, telling you a stranger could have read your data and that there’s no evidence anyone did. That’s not shared responsibility. That’s trust, full stop, and 2026 has made a decent case that the trust is being extended faster than the isolation engineering backing it up. Push your vendors for PEACH-style attestations the same way you’d push them for a SOC 2 report — not because it’ll stop the next CosmosEscape, but because it’s currently the only lever you have.