Breach anatomy
One tenant's MCP server answered with another tenant's data
Asana's MCP server, released on 1 May 2025, carried a logic flaw that could return data from one customer's domain to MCP users of other customers, within the kinds of objects the asking user was allowed to see. Asana found it on 4 June, took the server offline, fixed the code, reset every connection and notified about a thousand customers; it reported no evidence of malicious use. The server authenticated who was asking but did not bind every answer to that caller's tenant, which is the check a multi-tenant resource server owes on every request, not only at sign-in.
- Class
- Tenant isolation
- Disclosed
- Fixed
- Server offline from 5 to 17 June 2025; code fixed and all MCP connections reset
- Affects
- Asana MCP server (beta), 1 May to 4 June 2025
- Sources
- https://www.upguard.com/blog/asana-discloses-data-exposure-bug-in-mcp-server upguard.com
- https://www.bleepingcomputer.com/news/security/asana-warns-mcp-ai-feature-exposed-customer-data-to-other-orgs/ bleepingcomputer.com
- https://www.theregister.com/security/2025/06/18/asana-mcp-server-back-online-after-plugging-a-data-leak-hole/ theregister.com
The control that was missing
No requirement in the MCP auth atlas stands for this control yet. The summary above says what it is; a requirement is added to the atlas when a specification revision states it, not before.
Replay in the explorer
No scenario in the explorer replays this pattern yet. The incident is recorded here from its public notice; a replay follows when a baseline chain exists for it.