Allen Elzayn

November 13, 2025 · 6 min read

MCP x Cursor PoC: Rogue MCP Servers, IDE Browsers, and Real Defenses

#Security#Agentic AI#MCP#Electron#IDE#Threat Modeling
MCP x Cursor PoC: Rogue MCP Servers, IDE Browsers, and Real Defenses

A proof‑of‑concept published this week shows how a malicious Model Context Protocol (MCP) server can inject JavaScript into the built‑in browser of an AI IDE (e.g., Cursor/Windsurf/VsCode/ClaudeCode) and then leverage the editor’s privileges for system actions. This post avoids rehash and focuses on what practitioners need: a clear threat model, a safe lab plan to reproduce (without destructive payloads), generic detections you can wire into your telemetry today, and a security baseline for MCP deployments.

Key context:

  • PoC impact (news + demo): Rogue MCP servers can replace login pages inside Cursor’s in‑IDE browser and harvest credentials; the same capability can lead to workstation compromise (CSO Online, Nov 13, 2025; Knostic deep‑dive, Nov 5, 2025).
  • Standard & ecosystem: MCP is an open protocol that connects LLM apps to tools/data; clients/servers exist across vendors (Anthropic/GitHub/OSS). Misconfigurations and weak session handling have already produced CVEs and field‑grade abuse paths.
  • Electron reality: In‑IDE browsers are Electron webviews. Security settings (contextIsolation, sandbox, no Node for remote, strict CSP) often decide whether a UI compromise stays in the renderer or escalates to the OS.

Threat model: where this exploit actually lives

  • Boundaries
    • LLM/Agent ↔ MCP client ↔ MCP server ↔ IDE (Electron) ↔ in‑IDE browser ↔ OS.
  • Assets
    • Source code, credentials/tokens, SSH material, organization secrets, local files, IDE privileges.
  • Adversary paths
    • Malicious or hijacked MCP server returns active content (HTML/JS) to the in‑IDE browser; content manipulates UI flows (credential capture) or tries to escape the renderer via weak Electron settings (e.g., enabled Node, missing isolation, permissive IPC/preload).
    • Related ecosystem issues raise risk: predictable/reused MCP session IDs (CVE‑2025‑6515) enable session takeover; client‑side command injection (CVE‑2025‑6514) abuses crafted authorization URLs.
  • Assumptions
    • Developers add third‑party MCP servers for convenience; defaults may be permissive.
    • Teams lack network egress controls for IDE processes; logs from Electron/IPC are sparse by default.

Reproducing it safely

Goal: Reproduce the class of issue and validate mitigations without executing real malware.

  • Environment
    • Disposable VM (no prod creds), snapshot enabled.
    • IDE under test: Cursor or Windsurf (latest), default + hardened variants.
    • Mock MCP server under your control; two profiles: benign and “attacker.”
    • Instrumentation: process tree, file I/O events, network egress (domain/port), IPC/Electron warnings.
  • Procedure
    1. Wire IDE to the benign MCP server; confirm normal flows.
    2. Switch to attacker server that returns a crafted HTML page (login impostor + harmless JS markers).
    3. Observe: in‑IDE browser navigation, form capture attempts, outbound requests, attempts to use special protocols or preload bridges.
    4. Flip hardening toggles (see below) and repeat. Ensure behavior changes (blocked actions, console warnings, reduced surface).
  • Evidence to collect
    • Renderer → unexpected child processes or helpers.
    • Outbound connections from IDE to unallowed MCP hostnames or raw IPs.
    • File access attempts from IDE renderer to sensitive paths (~/.ssh, project .env, keychains).
    • IPC usage or errors indicating blocked Node/remote bridging.

What to watch in telemetry

These are vendor‑neutral hints you can adapt to OSQuery, Sigma, or your SIEM.

  • Process lineage
    • Parent process in {Cursor, Windsurf, Electron} spawning shells or platform installers.
  • File events (denylist paths)
    • Actor = IDE/Electron process AND path ∈ {~/.ssh/*, ~/.config/*/tokens*, project *.env}
  • Network egress
    • New outbound to MCP hosts outside your allowlist following an MCP session start.
  • DNS
    • Sudden spikes to newly observed MCP domains; mismatches between configured MCP endpoints and resolved targets.
  • Renderer security signals (if you can tap logs)
    • Warnings about disabled contextIsolation/sandbox, attempted use of remote, window open/navigation to external origins.

Pseudocode (conceptual):

  • Processes: parent in (Cursor, Windsurf, Electron) AND child in (bash, zsh, cmd.exe, powershell, wscript, osascript)
  • Files: actor in (Cursor, Windsurf, Electron) AND path matches (ssh keys, tokens, .env)
  • Net: dest_domain NOT IN mcp_allowlist AND proc in (Cursor, Windsurf, Electron)

Ship‑ready hardening

  • Electron/IDE
    • contextIsolation: true across renderers.
    • sandbox: true; avoid disabling sandbox via Node integration.
    • Do not enable Node.js for any remote/untrusted content; keep remote APIs off.
    • Define a strict CSP (no unsafe-eval, tight script-src), limit navigation/new windows.
    • Validate IPC senders; limit or eliminate preload bridges to the minimum.
  • MCP security baseline
    • Allowlist MCP servers; prefer local/stdio for sensitive tooling; if HTTP(S) needed, require TLS and verify pins/org.
    • Session IDs: cryptographically random, globally unique; never reuse or expose pointers/addresses as IDs.
    • Audit/log: server instructions/tool descriptors, tool invocations, and unexpected schema fields.
    • Policy‑as‑code (concept): gate tool actions by origin and intent (e.g., block filesystem writes unless explicitly approved by a rule/user step).
  • Network
    • Egress control for IDE/Electron to the MCP allowlist only; proxy inspection for HTML/JS “UI pages” returned by MCP.
    • Alert on raw IP connections, unusual ports, or domain mismatches.

Pre‑flight checks

  • Renderer isolation on (contextIsolation) and sandbox enforced.
  • No Node in remote content; preload minimized and reviewed.
  • MCP server allowlist + TLS (pinning optional, encouraged).
  • Session IDs: strong RNG; no reuse; no pointer‑derived IDs.
  • Egress to MCP restricted; detections firing on anomalous proc/file/net.
  • Attack page can’t exfiltrate secrets or spawn OS helpers under hardening.

Open threads

  • Public defaults for Cursor/Windsurf Electron settings (isolation, sandbox, remote) in the in‑IDE browser path.
  • Standardized MCP security profile (policy schema + conformance tests) akin to “baseline” CIS‑style benchmarks.

Resources:

Further Reading:

Connect

Allen Elzayn

Hi, I'm Allen. I'm a System Architect exploring modern tech stacks and production architectures. You can follow me on Dev.to, see some of my work on GitHub, or read more about me.

Comments