Back to Blog 
TL;DR
- CVE-2025-54136 ("MCPoison") is a CVSS 8.8 High vulnerability in Cursor IDE versions ≤1.2.4: an attacker controlling an MCP server can write unsanitised directives into tool descriptors that Cursor processes, hijacking the IDE's AI agent.
- CVE-2025-54135 ("CurXecute") is a CVSS 9.8 Critical vulnerability in Cursor IDE versions <1.3.9: workspace files can be written without user approval, allowing an attacker to chain prompt injection with missing-dotfile creation to achieve remote code execution on the developer's machine.
- The two CVEs are commonly grouped because both target the same component (Cursor's MCP integration) and exploit overlapping primitives, but they are mechanistically distinct: MCPoison weaponises the descriptor channel, CurXecute weaponises the workspace file system.
- Together they are the canonical example of why IDE-embedded AI agents carry a heightened threat profile: the agent runs with full developer-environment authority (git tokens, AWS credentials, signing keys, source access).
- Both are now patched in current Cursor releases. The pattern they reveal — descriptor mutation and workspace-file-write attacks — is generic and applies to every IDE-embedded agent, not just Cursor.
Why these two CVEs are paired
Cursor IDE is one of the largest production deployments of an IDE-embedded agent — an AI agent that runs inside a developer's primary editor with full access to the workspace, the version control state, and (typically) the developer's credential store. When two distinct vulnerabilities in its MCP layer were disclosed within weeks of each other in mid-2025, security researchers paired them as the canonical illustration of why IDE-embedded agents need a different threat model than standalone agents.
CVE-2025-54136 was researcher-named "MCPoison" by Check Point Research; CVE-2025-54135 was named "CurXecute" by separate research. Neither name appears in NVD; the CVE numbers are the authoritative reference. Both are in the MCP Breach Index 2025–2026.
CVE-2025-54136 — MCPoison
What it does
An attacker who controls an MCP server connected to a Cursor IDE instance can write directive content into tool descriptors that Cursor processes. The content is read into the LLM's context as part of normal tool-selection reasoning. From there the directives can hijack the agent's behaviour: redirect tool calls, exfiltrate workspace content, modify code suggestions, or pivot to other connected tools.
Why it works
The Cursor MCP integration accepted MCP server descriptors without sanitisation between the descriptor source and the LLM context. There was no diff against the previous descriptor load, no length limit on the description field, no quarantine of instruction-shaped content. A poisoned descriptor entered the context with the same authority as the system prompt.
This is the tool poisoning attack class first documented by Invariant Labs in April 2025. MCPoison is the production CVE that validated the class against a real high-volume target.
Severity (CVSS 8.8 High)
The vector requires the attacker to control an MCP server the user has connected — typically through trojanised connector supply-chain compromise (npm typosquat, registry impersonation, malicious update of a popular MCP server). The "High" rating reflects this prerequisite. Once the prerequisite is met, the impact is severe: full agent hijack inside a privileged IDE.
Fix
Cursor 1.2.5 and later sanitise descriptor content and require explicit user approval for newly-added or modified tools. Operators on older Cursor versions should update immediately. The general-pattern mitigation — sanitise descriptors before LLM context insertion, log full descriptor content per load, diff against previous load — applies to every IDE that connects MCP servers.
CVE-2025-54135 — CurXecute
What it does
CurXecute is mechanistically distinct from MCPoison. It exploits Cursor's behaviour around workspace file writes: the IDE will write certain configuration files (notably
.cursor/rules and similar dotfiles) without surfacing the action to the user. An attacker who can chain a prompt-injection step with a missing-dotfile-creation step can cause Cursor to write a file whose content is then auto-applied as a rule — effectively injecting an arbitrary instruction into the agent's permanent configuration.The chain works like this: (1) attacker-controlled content (a doc, a tool output, a webpage the agent reads) contains prompt injection; (2) the injected prompt directs the agent to "create" a missing dotfile in the workspace; (3) Cursor performs the file write without user confirmation; (4) the dotfile contains attacker-chosen rules that Cursor applies to all subsequent agent turns; (5) those rules execute attacker-chosen actions, up to and including arbitrary command execution via Cursor's terminal/exec primitives.
Why it works
The combination of two design choices: workspace files are auto-written without explicit user confirmation, and certain workspace files are auto-applied as agent configuration. Either alone is defensible. The combination produces a workspace-file-write attack primitive that any successful prompt injection can chain to RCE.
Severity (CVSS 9.8 Critical)
The vector requires only that the agent processes some attacker-controlled input — a document, a tool output, a webpage. This is a low bar. The impact is full RCE on the developer's machine, with the developer's authority. CVSS rates it 9.8 because the attack-complexity is low and the impact is full system compromise.
Fix
Cursor 1.3.9 and later require explicit user confirmation before writing dotfiles in the workspace, and apply additional restrictions on which workspace files are auto-loaded as agent configuration. The general-pattern mitigation — never auto-write configuration files without user confirmation, restrict the set of workspace paths that can influence agent behaviour, log every workspace mutation — applies to every IDE-embedded agent.
Why IDE-embedded agents are a heightened threat profile
The two CVEs together highlight a structural property of IDE-embedded agents that makes them more dangerous than standalone AI agents.
Maximum credential exposure. A developer's IDE typically has access to git credentials (push to private repos), cloud-provider tokens (AWS, GCP), signing keys (commit signing, package signing), and the active session of every internal tool the developer uses. An IDE-embedded agent inherits all of this. RCE on the IDE host is functionally equivalent to a full developer compromise — and developers are often the highest-leverage target inside an organisation.
Trust by default. Developers extend high trust to their IDE. They install plugins liberally, they paste content from web pages without inspecting it, they accept agent suggestions without scrutiny. The agent operates inside this trust envelope. Every input the agent processes — a file, a search result, a tool output — is treated with the same trust the developer would extend.
Tight integration with execution. IDE agents have direct access to terminal execution, file write, and code modification primitives. A successful manipulation does not need to escape into a different subsystem to do harm — the dangerous primitives are already in the agent's tool surface.
Mutable configuration files. As CurXecute demonstrated, IDEs that auto-apply workspace configuration files create a path from prompt injection to permanent agent compromise. The attack surface includes any file the IDE reads as configuration, not just files the user explicitly authored.
These properties apply to every IDE-embedded agent — Cursor, Continue, Aider, Zed, JetBrains AI assistants, GitHub Copilot's agent mode. The Cursor CVEs are the production examples, not edge cases.
Detection and mitigation for similar deployments
If you operate or rely on an IDE-embedded agent, the four operational controls below cover the patterns these CVEs reveal:
1. Sanitise tool descriptors before context insertion. Strip known prompt-injection patterns. Enforce length limits. Quarantine instruction-shaped tokens. Prefer the structurally-validated parameter schema over the raw natural-language description for the agent's reasoning step.
2. Log full descriptor content and diff across loads. Descriptor mutation is invisible without this. With it, the signal is mechanical and obvious — a benign descriptor that suddenly contains crafted directives is a clear incident indicator.
3. Never auto-write workspace files without explicit confirmation. Especially configuration files (dotfiles, rule files) that the IDE will subsequently auto-apply. The attack surface includes every file the IDE reads as configuration. The MCPoison/CurXecute pair is what happens when the audit trail ignores configuration writes.
4. Restrict which workspace paths influence agent configuration. A small, explicit allowlist of paths that can carry agent rules — not "any dotfile in the workspace". Unknown configuration files should be ignored, not auto-applied.
For Web3 developers specifically, the additional rule applies: an IDE-embedded agent that has access to wallet keystores, hardware-wallet bridge credentials, or signing-related session tokens must run in a process boundary distinct from any agent that processes arbitrary external content. The composition is too dangerous to gate with prompt-level controls.
Are you audit-ready?
Download the free Pre-Audit Readiness Checklist used by 30+ protocols preparing for their first audit.
No spam. Unsubscribe anytime.
Where these CVEs fit in the OWASP standard
MCPoison maps cleanly to OWASP ASI02 (Tool Misuse and Exploitation): the agent runtime accepted descriptor mutation without sanitisation, allowing the malicious server's content to influence tool selection and behaviour.
CurXecute maps to OWASP ASI05 (Unexpected Code Execution) — the broader class of agent runtimes producing RCE through chained primitives that individually seem benign.
Both also overlap with ASI04 when the malicious MCP server arrives via a supply-chain compromise (the typical real-world vector).
FAQ
1. What is CVE-2025-54136 (MCPoison)?
CVE-2025-54136 ("MCPoison") is a CVSS 8.8 High vulnerability in Cursor IDE versions ≤1.2.4 where an attacker controlling an MCP server can write unsanitised directives into tool descriptors that Cursor processes. The poisoned descriptor enters the LLM's context with system-prompt-level authority, hijacking the IDE's AI agent. It was researcher-named "MCPoison" by Check Point Research; the name does not appear in NVD.
2. What is CVE-2025-54135 (CurXecute)?
CVE-2025-54135 ("CurXecute") is a CVSS 9.8 Critical vulnerability in Cursor IDE versions <1.3.9 where workspace files can be written without user approval, allowing an attacker to chain prompt injection with missing-dotfile creation to achieve remote code execution on the developer's machine. The chain works because Cursor auto-applies certain workspace files as agent configuration, so a written dotfile becomes a permanent rule.
3. How are MCPoison and CurXecute different?
MCPoison and CurXecute target the same component (Cursor's MCP layer) but exploit different primitives. MCPoison weaponises the tool descriptor channel — adversarial content in the descriptor hijacks tool selection. CurXecute weaponises the workspace file system — auto-written configuration files become permanent agent rules. They are commonly paired because both reveal structural properties of IDE-embedded agents, but the fixes and mitigations are mechanistically different.
4. Are these vulnerabilities still exploitable?
Both CVEs are patched in current Cursor releases — Cursor 1.2.5+ for MCPoison, Cursor 1.3.9+ for CurXecute. Operators on older Cursor versions should update immediately. The structural patterns (descriptor mutation, workspace-file-write attacks) are generic and apply to every IDE-embedded agent, so equivalent vulnerabilities can re-emerge in other products if the same controls are missing.
5. Why are IDE-embedded agents a higher-risk target than standalone agents?
IDE-embedded agents inherit a developer's full credential exposure (git tokens, cloud-provider credentials, signing keys, internal-tool sessions), operate inside a trust envelope that developers extend liberally to their editor, have direct access to execution primitives (terminal, file write, code modification), and often auto-apply workspace configuration files as agent rules. Each property amplifies the impact of any successful prompt injection or tool poisoning attempt.
6. How do I prevent CurXecute-class attacks in other IDE agents?
To prevent CurXecute-class attacks, never auto-write workspace files without explicit user confirmation — especially configuration files that the IDE auto-applies as agent rules. Restrict the set of workspace paths that can influence agent configuration to a small explicit allowlist. Log every workspace mutation. Treat any auto-write of an unknown configuration file as an incident requiring investigation. The structural fix is that prompt injection should not be able to chain to permanent agent reconfiguration through file-write primitives.
7. How do I detect a MCPoison-class attack against my agent?
To detect a MCPoison-class attack, log the full content of every tool descriptor at the moment it enters the LLM context, and diff against the previous load. A descriptor that mutates post-install — especially in ways that introduce instruction-shaped content ("ignore previous", "also send to", "do this before") — is the strongest mechanical signal of an active poisoning attempt. Without descriptor logging, the attack is essentially invisible during execution.
8. How does Zealynx audit IDE-embedded agent deployments?
Zealynx's MCP Security Audit tests IDE-embedded agent deployments across the patterns these CVEs reveal: descriptor sanitisation effectiveness, workspace-write controls, configuration-file auto-apply scoping, and credential-isolation between the agent and the developer's local credential store. Findings map to the OWASP standard (typically ASI02 and ASI05) with prioritised remediation guidance.
Glossary
| Term | Definition |
|---|---|
| Descriptor Mutation | The phenomenon where an MCP tool descriptor's content changes between agent runs — between install and first use, or between successive uses — without any update to the connector's declared version. The mechanism that enables MCPoison-class attacks. |
| Workspace-File-Write Attack | An attack pattern where an AI agent is induced to write a file in the host workspace whose content is then auto-applied as configuration or instruction by the agent runtime — chaining prompt injection to permanent reconfiguration or RCE. The mechanism behind CVE-2025-54135 (CurXecute). |
| IDE-Embedded Agent | An AI agent that runs inside a developer's editor (Cursor, Continue, Aider, Zed, JetBrains AI, GitHub Copilot agent mode) with access to the workspace, version control state, and developer credential store — a structurally higher-risk deployment profile than standalone agents. |
Are you audit-ready?
Download the free Pre-Audit Readiness Checklist used by 30+ protocols preparing for their first audit.
No spam. Unsubscribe anytime.