On June 4, Asana identified a bug in its Model Context Protocol (MCP) server and took the server offline to investigate. While the incident was not the result of an external attack, the bug could have exposed data belonging to Asana MCP users to users in other accounts. 

What Happened

According to Asana’s disclosure, the bug “could have potentially exposed certain information from your Asana domain to other Asana MCP users.” Specifically, users leveraging the MCP interface—typically for LLM-powered chat interfaces—may have been able to access data from other organizations, but only within the “projects, teams, tasks, and other Asana objects” of the MCP user’s permissions.

There is no indication that attackers exploited the bug or that other users actually viewed the information accessible through the MCP bug. Asana emphasizes: “This was not a result of a hack or malicious activity on our systems.” 

Timeline and Response

Asana responded quickly upon discovery of the bug:

• May 1. Asana releases the MCP server. The bug appears to have been part of this initial release. 
• June 4: The MCP bug was identified, Asana took the server offline, and resolved the code issue. They write: “Our incident responders and engineering teams acted immediately. As soon as the vulnerability was discovered on June 4, we took the MCP server down to investigate, contain the issue and prevent any further potential exposure. The bug in our code was then promptly resolved.”
• June 16: Asana notified potentially affected customers–anyone with a user who used the MCP server.
• Ongoing: Asana is working to bring the MCP server back online. Additionally, they have sent out a form for affected companies to contact them to get a list of all Asana users with the MCP servers who may have potentially had their data read by others.

“As soon as the vulnerability was discovered, our teams immediately took the MCP server down and resolved the issue in our code,” the company wrote in its email to customers.

Customers have been given the ability to request logs and metadata associated with their MCP users to determine whether cross-account data exposure may have occurred. Asana advises organizations to “review any information you may have accessed through the MCP server in recent weeks and immediately delete any data that doe

Asana’s Next Steps

Asana reports that the MCP server will be reinstated “in the coming days,” but reconnection will be manual. “We want to ensure your team is aware of the issue we experienced, and that you have full control over when your Asana instance reconnects to the MCP server.”

The company also confirmed that a formal post-mortem report is underway and will be available upon request when completed.

Takeaways for Organizations Using LLM Integrations

This incident highlights key lessons for any organization integrating LLMs into sensitive workflows:

1. Limit scope aggressively: Ensure that context servers like MCP enforce strict tenant isolation and least-privilege access.
2. Log everything: Maintain granular logs of all requests, especially LLM-generated queries, to support forensic investigations.
3. Manual oversight during reintroduction: Automated reconnections or retraining pipelines should be paused when incidents arise.
4. Treat internal bugs seriously: As shown here, even internal software flaws can have real-world exposure consequences.

Asana’s transparency in handling the incident and proactive communication are commendable, but the episode underscores the risks inherent in LLM system design, especially when integrated with enterprise data platforms.

‍

Ready to see
UpGuard in action?

Ready to save time and streamline your trust management process?