Why this comparison matters
CosmosEscape is the more important story here because it shows what happens when a tenant-controlled feature reaches deep into a shared data platform and pulls back a credential that was never meant to be tenant-visible. The starting bug was a Gremlin sandbox escape. The real damage came from what that escape unlocked afterward.
The Entra Actor Token issue is still useful as a comparison, but mainly because it leads to the same type of cloud failure from a different direction. In both cases, Microsoft-trusted authority crossed into another customer boundary. The difference is in the outcome: CosmosEscape exposed data service trust directly, while the Entra issue exposed identity-plane administrative trust.
Key point: In both incidents, a trusted execution context inside Microsoft services was not constrained tightly enough to the tenant that initiated the request.
Start with CosmosEscape
CosmosEscape: data plane and service infrastructure path
The crucial point is not that Gremlin was unsafe. The crucial point is that a bug in a query layer eventually reached a credential path that could mint authority for other customers. That outcome is why CosmosEscape belongs in the small set of cloud bugs that force architecture changes, not just input validation fixes.
What CosmosEscape actually broke
Wiz Research showed that the Gremlin API execution pipeline could be abused to escape intended query restrictions. The exploit chain moved from tenant-controlled query input to arbitrary code execution in a shared gateway layer used to process customer traffic.
Boundary failure sequence in CosmosEscape
From there, the important issue was not only code execution. The gateway had access to internal trust paths and signing capabilities that could be used to request primary keys for Cosmos DB accounts other than the attacker's own account. That is the moment where the outcome stops being a sandbox bug and becomes a cloud-boundary failure.
Wiz referred to this platform-level capability as the Cosmos Master Key. That key removed customer boundaries at the key-retrieval layer, which turned one compromised component into broad cross-tenant risk. The blast radius was not one workload, one cluster, or one subscription. It was the trust model around key issuance itself.
That also explains Microsoft's response speed. Wiz reported that Microsoft moved to contain and fix the exposed Cosmos DB path within roughly 48 hours of responsible disclosure. You do not make that kind of emergency platform change for an ordinary parsing bug. You do it when the issue reaches shared trust and cross-tenant data access.
Why Config Store made targeting practical
Cross-tenant key access is severe on its own. Precise victim selection makes it worse. According to Wiz, internal configuration data could be used to map tenants and subscriptions to account names and metadata.
That changed the attack from opportunistic to targetable:
Targeting chain
Private endpoints and network isolation do not automatically stop this class of issue when the compromised component sits inside the trusted service path that already enforces those controls.
Why the Entra case is still the right comparison
CVE-2025-55241 was not an MSAL bug. The issue centered on legacy Actor Token behavior and tenant validation gaps in legacy Azure AD Graph processing, as documented by Dirk-jan Mollema.
I am not using it here because the mechanics match CosmosEscape. They do not. I am using it because the outcome pattern matches: an attacker reached a Microsoft-trusted path and got a victim-scoped authority that should have stayed impossible outside the victim tenant.
Compact Entra comparison flow
Because this path represented backend service-to-service trust, traditional user-facing controls like Conditional Access in interactive sign-in paths were not the controlling boundary for this exploit chain.
Compare the outcome, not just the bug class
The cleaner way to compare these incidents is to ask what authority the attacker ended up with after touching a Microsoft-trusted component. That shows why CosmosEscape was such a serious data-platform event.
| Outcome lens | CosmosEscape | Entra Actor Token flaw |
|---|---|---|
| What was ultimately gained | Victim Cosmos DB primary key | Victim user and admin impersonation |
| What that authority looked like | Real data-plane account credential | Real identity-plane administrative context |
| Immediate victim impact | Read or modify application data across tenants | Create persistence, change configuration, grant permissions |
| Trust boundary that collapsed | Shared service path for database key issuance | Shared service path for delegated identity validation |
| Why the blast radius was so high | A shared gateway could reach keys for unrelated customer accounts | A trusted token model could cross into another tenant identity boundary |
| Why I keep the focus on CosmosEscape | It shows a data platform turning shared internal trust into direct customer data access | It confirms the same boundary lesson in the identity plane |
The shared exploit pattern
- Start from legitimate tenant-owned access.
- Reach a Microsoft-trusted intermediary component.
- Break or bypass tenant context validation.
- Convert platform authority into victim-specific authority.
- Enumerate target resources or privileged identities.
- Operate with credentials that the platform itself considers authoritative.
That pattern matters because it keeps surfacing in different service layers. The exploit surface can be a query engine, a legacy token path, or an automation feature. The dangerous transition is the same: tenant-origin input reaches a trusted service path, and that path acts with broader authority than the originating tenant should ever be able to trigger.
Where MSAL fits, and where it does not
MSAL handles modern token acquisition for applications. It was not the root failed boundary in CVE-2025-55241. Labeling this issue as a generic MSAL multi-domain bug points defenders to the wrong control layer.
A better description is: cross-tenant impersonation through legacy Actor Token trust combined with insufficient tenant binding in a legacy API path.
What defenders should validate now
These are the controls I would prioritize for any cloud platform, data platform, or AI agent platform where tenant-supplied input reaches high-trust internal services.
- Strict tenant cryptographic binding: Ensure tenant, audience, and resource claims are enforced at each handoff, not only at entry points.
- No universal key in tenant-reachable runtimes: Components processing tenant-controlled execution should receive short-lived, operation-scoped credentials only.
- Confused deputy testing: Explicitly test whether trusted middle-tier services can be tricked into acting on behalf of another tenant.
- Legacy protocol retirement: Identify older API paths and backend token formats that bypass modern policy enforcement layers.
- Cross-tenant abuse detection: Alert on unusual tenant-to-tenant graph traversals, key retrieval patterns, and delegation chains.
- Blast-radius modeling: Treat each internal signing capability or impersonation path as if it were a tier-0 secret, then scope and isolate accordingly.
Practical takeaway: Signature validity is necessary, but it is not sufficient in multitenant cloud systems. You also need tenant validity, resource validity, and delegation-chain validity at every trust transition.
Final assessment
CosmosEscape and the Entra Actor Token vulnerability were technically different incidents, but they converged on the same cloud isolation failure mode: broad platform trust exercised without enough tenant-boundary revalidation.
CosmosEscape is still the more striking case for me because Microsoft had to respond like a cloud provider protecting the integrity of a shared platform, not like a product team patching a normal feature defect. A 48-hour remediation window tells you how seriously the boundary failure was taken, and it underlines the real lesson: once customer-controlled execution reaches shared trust, the risk is no longer local.
For me, this is also the AI security lesson. As more products expose agent tool-calling, runtime code execution, plugin chains, and automation across tenants, the pressure on boundary validation gets higher, not lower.
No AI without Security is not a slogan. It is an architecture requirement. If a tenant-origin request can ever inherit a platform-level capability that is not cryptographically and operationally constrained to tenant, resource, identity, and operation, then cross-tenant compromise stays one design mistake away.