Translated from 日本語 • View original 
In recent years, the introduction of AI-based code completion and automation tools has been rapidly progressing in development sites to improve productivity. Cursor, Copilot, and various LLM-based IDEs are no longer just for a few forward-thinking teams, but have become everyday tools for many development organizations.
However, did you know that behind this "convenience" is a new attack surface that did not exist in the development environment so far?
In this blog, we will discuss the critical vulnerabilities identified in the AI code editor Cursor .
"Remote Code Execution (RCE) Abusing MCP (Model Context Protocol) Settings"
――We will organize and explain the mechanism, attack flow, risks, and practical countermeasures of MCPosion (CVE-2025-54136), commonly known as MCPosion .
Threat Summary: AI's "Trusted Settings" Become the Starting Point of Attacks
The essence of this vulnerability lies in the very "trust model" that Cursor employs.
Cursor uses MCP (Model Context Protocol) as a mechanism for AI to manipulate external tools.
Developers can define '.cursor/rules/mcp.json' for each project, which can include information such as:
- MCP Name
- Commands to be executed
- Arguments (parameters)
When Cursor opens a project, it automatically scans this '.cursor' directory and processes the defined MCPs.
The problem starts here.
Once the user acknowledges that "I trust this MCP" ,
**From now on, trust decisions are made based on the "name" alone, and changes to execution commands or arguments are not double-checked. **
By abusing this behavior,
If you replace it with a malicious command later, it will run without additional approval
A serious condition is born.
Attack Flow: "Ordinary Collaboration" on GitHub Becomes a Trap
MCPosion attacks proceed very realistically and quietly.
You don't need any special vulnerable servers or public services.
The **flow of the attack is as follows: **
1. Initial Intrusion: A Seemingly Innocuous Commit
The attacker uses the
Make a commit that contains a seemingly fine MCP configuration.
- Does not include malicious commands
- Looks like a normal tool definition
- Less suspicious when reviewing
At this stage, the damage will not occur yet.
2. Project approval in Cursor
When the victim (developer) opens the project in Cursor,
A confirmation dialog for the new MCP will appear, "Do you want to allow it to run?"
Here, when the user approves it,
The MCP name is recorded as a Trusted status .
3. Injection of Malicious Payloads
The attacker can use the
**Replace only the "execution commands" and "arguments" of the MCP that are already trusted. **
- No change to MCP name
- However, the execution content is completely different
- Cursor does not ask for re-approval
This is the crux of this vulnerability.
4. Exploit Execution: RCE with just synchronization and restart
The attack is established the moment the victim does any of the following:
- Synchronize repositories (pull)
- Restart Cursor
As a result,
Malicious commands are executed immediately with user privileges .
Studies have also confirmed complete system control using the Reverse Shell.
Why It's Dangerous: Breaking Down Traditional Security Assumptions
What makes this problem serious is that it's not just a "tool bug".
Traditional Assumptions
- GitHub repositories are reviewed
- Locally executed code is at your own risk
- IDE is a "passive tool"
The reality that MCPosion confronted
- The configuration file becomes the execution subject.
- AI automatically executes commands
- "One trust" allows for future changes
In other words,
The AI-assisted development environment itself becomes an attack vector
A new threat model has been exposed.
Detection Difficulty: No Logs or Alerts Left
This attack is very difficult to detect for the following reasons:
- Canonical GitHub operations (commit/pull)
- Canonical Cursor behavior
- MCP approved by the user himself
Even from the perspective of EDR and antivirus,
In most cases, it looks like "the developer just used the tool".
Countermeasure: Don't "trust the AI development environment too much"
1. Cursor Update (Top Priority)
This vulnerability has been fixed in the latest version .
For environments using Cursor, prompt updates are strongly recommended.
2. Targeting MCP Configurations for Code Review
- Review '.cursor/' as if it were normal code
- Not just the "name" of the MCP
Requires difference checking of execution commands and arguments
3. Minimize the privileges of AI tools
- Avoid using administrator privileges on development terminals
- Limit the scope of influence of commands executed via AI tools
4. Redefining "trust"
- Do not assume the design that one approval = permanent trust
- Clearly state the AI tool usage policy within the team
Conclusion: AI is powerful, but not neutral
MCPosion
This is not a story that "using AI itself is dangerous".
The problem is,
The reason is that the "boundaries of trust" that humans have built have been brought directly into the workflow of the AI era.
AI writes code,
AI powers tools,
The AI interprets the settings and
And -- AI can also be an attack vector.
Now is the time,
"What can AI do, to what extent, and with whose authority?"
It's time to ask again.
Development efficiency and security are not trade-offs.
If you design it right, you can do both.
We hope this blog will inspire you to review your AI development environment.
So far, Colorkrew Security's Jaeho Yoon has brought you the best.
Thank you very much.