In this write-up, we unfold the paradigm behind such attacks, which we’ve defined as Toxic Flow Analysis, and how they relate to input sources (prompt injection and indirect prompt injection), actionable agentic workflows (such as Cursor and other AI agents), and access to sensitive data such as credentials, PII or other non-public information.
About the Jira MCP Server security incident affecting Cursor
As the attack's authors explain, the Cursor AI agent is susceptible to a prompt injection attack through a malicious Jira support ticket. Let’s briefly recap the attack on Cursor and the MCP server integration and explain how it ties into our previous research on agentic toxic flows.
The attack is performed as follows: The attacker inserts a malicious prompt in a Jira ticket they submit to the target company. In his social post about the story, Michael calls this a “weaponized Jira ticket” and presents a realistic scenario in which an attacker can submit such a Jira ticket by simply emailing the victim company’s support address.
Once the Jira ticket is created and a developer points their Cursor agent to it, the compromised agent will read the ticket and happily leak credentials to the attacker.
The prompt injection technique used in the attack is inventive. Rather than directly asking the agent to leak secrets, the malicious prompt asks it to look for… apples. It then defines apples as “long strings that start with ‘eyj’” (the start of many JWTs). So, even if a developer implemented guardrails in the system prompt (e.g., to prevent the agent from searching for secrets), this technique tricks the agent into ignoring its developer's intent. This proves that while techniques like system prompt guardrails are helpful and necessary, they cannot fully secure an agentic system because they can often be bypassed.
How is this Cursor security incident related to toxic flows?
This attack is a classic example of a data leak toxic flow, a type of attack that exploits agentic workflows that we published earlier in May this year in our previous research.
A toxic flow attack relies on three conditions being met:
The agent must use a tool that gives it access to attacker-controlled data, which the agent then uses as context. In this case, the agent can read Jira tickets, which can be submitted by anyone. In our toxic flow analysis, we call these untrusted content tools.
The agent must have a tool that can read sensitive information. In this case, the agent had access to the local filesystem, which could contain credentials. We call these private data tools.
The agent must have a tool that can exfiltrate information. Here, the agent could perform HTTP requests, allowing it to leak data to an attacker-controlled endpoint via URL parameters. We call these public sink tools.
When all three of these conditions are met, the agentic system is vulnerable to a toxic flow attack. Note that many combinations of tools can create this vulnerability. For example, instead of reading Jira tickets, the agent could read public pull requests via a GitHub tool. Or, instead of accessing the filesystem, it could query a database containing sensitive information.
How can Snyk’s MCP-Scan help you detect and mitigate this?
We recently added toxic flow detection capabilities to our free, open source tool, MCP-Scan. Internally, we invest heavily in infrastructure like AI classifiers that allow us to label MCP tools as destructive, sensitive, or public. MCP-Scan detects the MCP Servers and tools you’ve installed locally (including in your Cursor IDE) and identifies potential toxic flows using our labeled dataset.
Previously, MCP-Scan only supported MCP Servers that a user explicitly installed for their Cursor IDE or other agentic products. Because the “Cursor + Jira MCP 0-Click” attack relies on built-in Cursor tools, MCP-Scan would not have previously detected it. However, today we’re happy to announce that we are extending MCP-Scan to support built-in Cursor tools, making it capable of detecting the “Cursor + Jira MCP 0-Click” vulnerability and similar toxic flows!
This feature is available immediately for all MCP-Scan users. Users can access this feature by running MCP-Scan with the --include-built-in flag.
What's next for MCP & Agentic Security at Snyk?
Snyk is actively researching and uncovering MCP-related security vulnerabilities and incidents, such as:
Working with the maintainers of
aws-mcp-server,markdownify-mcp, and others to secure against Snyk’s MCP prompt injection findings.Actively educate the developer community on MCP Security and vulnerable MCP Servers.
We are continuously working to improve our MCP & Agentic Security capabilities. We’re busy building a solution for security teams that will allow them to:
Gain visibility into the agentic assets (MCP Servers, tools, agents, etc.) that developers install on their dev machines or build servers.
Detect security risks like toxic flows or tool poisoning in these assets, and write policies to automatically triage and remediate them.
Remediate risks with runtime guardrails (e.g., blocking malicious actions at runtime).
We also plan to extend MCP-Scan and our Agentic Security solution beyond development and build environments to analyze and detect issues directly in your code and applications. This will help protect development teams from shipping insecure agentic applications.
Want to stay in the loop about security insights and research findings? Sign up for updates or become a design partner for agentic security products we’re building.
