The Fourth Layer: When MCP Attacks Move Into Your IDE
Source: Dev.to
Overview
Three weeks ago I published an analysis of MCP attack surfaces across three layers: servers, developer tooling, and host applications. At that time we had 30 CVEs.
Today, Knostic.ai released research on CVE‑2026‑27180, which adds a fourth layer—and it’s the most dangerous one yet.
Target
Cursor IDE – an AI‑powered code editor used by millions of developers
Researcher: Dor Munis, Knostic.ai
Attack type:
MCP server → JavaScript injection → credential theft → full workstation compromiseThe attack does not require code execution or any user‑initiated tool call. It triggers the moment Cursor loads the MCP server’s tool list.
Attack Flow
- Malicious MCP server is installed (e.g., from GitHub, Discord, or a curated list).
- When Cursor calls
tools/listto discover available tools, the malicious server:- Hooks into Cursor’s internal extension directory.
- Injects
document.body.innerHTML = [attacker payload]into Cursor’s embedded browser.
- Every browser tab opened in Cursor now displays attacker‑controlled content while the legitimate URL remains in the address bar.
- Developers enter credentials into what looks like their own application’s login page.
Resulting chain:
MCP discovery → IDE modification → browser hijack → credential theftNo tool needs to execute; the passive handshake is sufficient.
Why Cursor Is Vulnerable
- Cursor is a fork of VS Code with AI capabilities built in.
- VS Code performs integrity checks on its own extension files; Cursor does not.
- Consequently, any modification of Cursor’s internal code—by an MCP server, an extension, or any process with file‑system access—occurs silently, without warnings or checksum failures.
Knostic researchers describe the exploit as “eval on top of another eval”: the injected code runs in the Cursor browser context, which itself is an evaluation environment with full access to the user’s development state.
“An MCP server should be treated exactly like VS Code extensions in terms of security.” – Dor Munis to CSO
Existing Framework (Three Layers)
| Layer | Examples | CVEs |
|---|---|---|
| L1: MCP Servers | exec() injection, eval() bypass, path traversal | 25 |
| L2: Developer Tooling | MCP Watch, MCPJam Inspector, MCP Probe | 3 |
| L3: MCP Host Applications | Dive deeplink, Dive XSS/Mermaid | 2 |
New Fourth Layer (L4)
| Layer | Description | CVEs |
|---|---|---|
| L4: MCP Client/IDE | Cursor browser injection | 1 (and counting) |
What Makes L4 Different from L3?
| Aspect | L3 – Host Applications (e.g., Dive) | L4 – IDE Clients (e.g., Cursor) |
|---|---|---|
| Role | Runs MCP servers and manages connections (orchestration layer). | Where developers build applications; holds elevated privileges (file‑system access, process execution, developer credentials, signing keys). |
| Trust | Developers interact with a remote service. | Developers trust the IDE as their own tool, not a third‑party server. |
| Impact of Compromise | May affect a single service or workflow. | Gives attacker access to every service the developer uses, every repository they push to, and every secret stored during development. |
tools/list Recon Problem — Revisited
- In our earlier analysis of AWS EC2 crawler behavior, 70 % of MCP protocol traffic was
initialize → tools/list → disconnect, with zero tool calls. We interpreted this as attackers merely mapping the attack surface. - CVE‑2026‑27180 shows the opposite: the server can use
tools/listas a hook—not just the client for reconnaissance.
Key insight:
tools/listis not passive. When a MCP client calls it, a trust relationship is created, and the response can modify the client environment.
This surface is also used for:
- Tool‑poisoning attacks (malicious tool descriptions that manipulate LLM behavior)
- Prompt injection via tool metadata
Thus, the attack surface is tool discovery, not tool execution.
Full CVE Landscape (as of today)
| Layer | Sub‑category | CVE Count | Typical Issue |
|---|---|---|---|
| L1 – Server | exec() class | 10 | child_process.exec() without sanitization |
eval() class | 3 | Python eval with/without scope restrictions | |
| Other server | 12 | Path traversal, auth bypass, credential exposure, SSRF | |
| L2 – Developer tooling | — | 3 | Security scanners, debuggers, inspectors |
| L3 – Host applications | — | 3 | Dive (two vectors), eBay env injection |
| L4 – IDE/Client | — | 1 | Cursor browser injection |
Pattern: The ecosystem treats MCP security primarily as a server‑side problem. Every layer beyond L1 was discovered only after researchers specifically looked for it—not by the developers building the tools.
Immediate Actions
- Audit every MCP server you have installed.
cat ~/.cursor/mcp.json # or the equivalent path on your system - For each server:
- Locate its GitHub repository.
- Review the source code.
- Remember: MCP servers run with your IDE’s privileges—treat them like root access.
- Disable YOLO/auto‑run mode.
- When agents execute actions without human confirmation, there is no checkpoint between tool discovery and arbitrary execution.
- Avoid installing MCP servers from Discord, Reddit, or aggregator lists without code review.
- Even curated lists are imperfect; our dataset shows the official MCP registry has quality issues.
- Be suspicious of MCP servers that request broad file‑system or network access unrelated to their stated purpose.
Recommended Mitigations for Cursor
| Mitigation | Rationale |
|---|---|
| Integrity checks on extension files (as VS Code does) | Detects unauthorized modifications to the IDE’s internal code. |
| Sandboxing of the embedded browser (separate process, restricted permissions) | Prevents injected scripts from accessing the full development environment. |
| Code signing for MCP server packages (similar to browser‑extension signing) | Guarantees provenance and prevents tampering. |
| Container isolation (e.g., Docker) | Limits the impact of a compromised IDE, though CVE‑2026‑27180 occurs before any container is launched. |
Docker’s recent “MCP Horror Stories” series highlighted defensive tooling and containerization as mitigations. While container isolation helps, CVE‑2026‑27180 executes in the host environment, so the above IDE‑level defenses are essential.
End of cleaned markdown.
rts.
The attack surface is expanding faster than any single defensive framework can address. Container isolation protects the server, but it doesn’t protect the IDE that loads the server’s tool list.
The correct security model for MCP isn’t “run servers in containers.” It’s “treat every MCP server as a hostile binary executing in your development environment.”
That’s not a technical problem—it’s a cultural one. And 33 CVEs in six weeks suggests the culture hasn’t caught up yet.
Resources
- Live MCP scanner and CVE registry:
- Full 33‑CVE dataset:
mcp-disclosures.md - Previous essay: Two New CVEs — eval() bypass + Dive XSS