The Cursor Agentic Jira MCP Attack Explained with Toxic Flow Analysis

What happened in Cursor + Jira 0-Click attack? I’ll break it down for you in a flow chart that traverses the attack step-by-step, how it was exploited, and why developers are at the center of it all.

• When: August 1, 2025 security advisory by Marina Simakov of Zenity Labs
• What: Attack targeting Cursor IDE users
• How: Toxic flows in the Model Context Protocol (MCP) exploited by attackers

What is MCP, Toxic Flows, and why should you care? let’s break it down.

MCPs in developers tool-box

Model Context Protocol (MCP) servers enable developers to embed actions, information and context into their agentic coding workflows. These may be IDE tools like Cursor, or command-line tools like Claude Code.

Developers reach out to MCPs to get context-aware code completions, code generation, and other AI-assisted coding tasks. In this sense, JIRA MCP is a server that provides context about JIRA tickets, projects, and workflows to the AI coding assistant. Developers can then use a ticket’s own information to plan, generate, and update code related to that ticket. All without opening Jira, or a web browser, because the agent (Cursor in our story) can drive actions via the Jira MCP.

The Cursor + Jira MCP Workflow

Developers using Cursor IDE can connect to the Jira MCP server to enhance their coding experience. The workflow typically looks like this:

This is pretty straightforward. The developer prompts the AI coding assistant (Cursor) to perform actions related to a Jira ticket. Cursor then communicates with the Jira MCP server to fetch relevant information about the ticket, such as its description, status, and comments. The MCP server responds with the requested data, which Cursor uses to generate context-aware code completions or suggestions.

The Cursor + Jira MCP Attack Flow

In parallel to the agentic developer workflow above, the attacker sends an email to the support team, which translates to a Jira ticket. The ticket contains a malicious prompt that abuses the MCP protocol to execute arbitrary code on the developer’s machine.

So the following takes place:

Putting these two seemingly separate flows together, we get the full picture of how the attack unfolds:

The support ticket from the user (the attacker) contains a prompt that instructs the AI coding assistant (Cursor) to retrieve JWT tokens from the developer’s machine. These can be any tokens to any systems, they are just found and placed in plaintext on the developer’s machine via .env files and other config files.

Cursor uses the Jira MCP server to fetch the ticket’s description, which includes the malicious prompt and is then being acted upon. An Agentic IDE like Cursor also has other built-in tools like a generic web fetch tool, which means that the malicious prompt can also include instructions that tell Cursor to send the stolen tokens to an external server controlled by the attacker.

The attack in action is demonstrated in the following screenshot from Zenity Labs and their research:

Toxic Flows in MCPs

Looking at the full flows above we can identify specific points of failure that enabled the attack to succeed. These are what Snyk security research team refers to as “Toxic Flows”.

More precisely, we can name these flows as follows:

• *Untrusted Content Tools
• Public Sink Tools
• Private Data Tools

And they’re illustrated in the following diagram:

Applying this knowledge to the Cursor + Jira MCP attack, we can see how each of these toxic flows played a role in the attack:

Conclusion

Toxic Flow Analysis is a powerful framework for understanding and mitigating security risks in AI-assisted coding environments.

The Cursor + Jira MCP attack serves as a reminder for the potential culprits of MCP weaknesses with agentic workflows but it isn’t new and has been published initially by Invariant Labs researchers (acquired by Snyk) in May 2025. Their research uncovered security issues in the GitHub MCP Server exploitation and how it was exploited in a similar manner.