IDEsaster: when base IDE features become agent RCE primitives

What is this?

On December 6, 2025, security researcher Ari “MaccariTA” Marzouk published IDEsaster, the result of roughly six months probing AI-powered code editors. The finding is not a single bug but a vulnerability class: prompt injection that steers an AI coding agent into abusing the underlying editor’s long-standing features — features that predate AI and were always assumed safe — to reach data exfiltration and remote code execution.

The numbers are the headline. Over 30 vulnerabilities were reported, 24 assigned identifiers, with an AWS security bulletin and an update to Claude Code’s documentation acknowledging the risk. Every application Marzouk tested was vulnerable to the new chain — GitHub Copilot, Cursor, Windsurf, Kiro, Zed, Roo Code, JetBrains Junie, Cline, Gemini CLI, Claude Code and more. Because the flaw lives in the shared base editor rather than in any one product, a single technique lights up an entire ecosystem at once.

How it works

Earlier attacks on AI editors followed known chains: a poisoned prompt drives a vulnerable tool, or drives ordinary tools into editing the agent’s own settings (its MCP config, its auto-approve list) to gain execution. IDEsaster adds a third link that most vendors left out of their threat model entirely: prompt injection → tools → base IDE features. The agent’s file-writing tool is used for exactly what it is meant to do — write a file — but the file it writes activates a legacy editor feature with dangerous side effects. Marzouk illustrates three cases; no exploitation prompts are reproduced here, and the researcher deliberately withheld exact payloads while some vendors remain unpatched past the 90-day window.

The first case abuses remote JSON schemas. Many editors let a .json file reference a validation schema at an external URL, and fetch it automatically. An agent tricked into writing a JSON file whose $schema points at an attacker domain — with stolen data appended as a query parameter — causes the editor to make the request on its own. Notably, the fetch fires even under diff-preview, sidestepping some human-in-the-loop checks.

The second case is IDE-settings overwrite for code execution. Unlike prior reports that flipped an agent’s setting, this targets the base editor’s settings, so it applies to every product sharing that editor. On VS Code–based editors, the agent writes a payload into an always-present executable file (a Git hook sample, for instance), then points a validator path setting at it; opening a matching file type instantly runs the binary. JetBrains editors have an equivalent path through their project configuration.

The third case, multi-root workspaces, shows the class’s depth: a workspace-definition file can add arbitrary folders as project roots, dissolving the “file must already be in the workspace” precondition and re-enabling the settings-overwrite path even where the first fix landed. Close one feature, another appears — which is the whole point.

Why it matters

The impact ceiling is full remote code execution on the developer’s machine, plus silent exfiltration of anything the agent can read, triggered by content the agent merely processed — a poisoned README, a rule file, a pasted URL with invisible characters, a compromised MCP server. Millions of developers use the affected products, and every tested one was exposed. Marzouk frames the root cause as a missing design principle he calls “Secure for AI”: editors were built secure-by-design for humans, but adding an autonomous agent that can read, write, and execute turns benign legacy features into attack primitives that nobody re-evaluated. The injection is inevitable; the durable fix is shrinking what a hijacked agent is allowed to reach.

Defenses

For developers using AI IDEs: only run agents on trusted projects, since file contents and even file names are injection vectors; connect only to trusted MCP servers and watch them for changes; manually review any URL or text you add as context for hidden or invisible instructions; and keep human-in-the-loop enabled wherever the tool supports it.

For teams building agents: apply least privilege to every tool — scope read_file to the workspace (no traversal, no symlinks, block dotfiles and credential paths), gate write_file to source directories and require confirmation for config or dotfiles, and prefer human approval or a domain allowlist for outbound http_fetch. Assume breach: require confirmation for any sensitive action, sandbox executed commands, and enforce egress controls at the IDE layer so exfiltration side effects (like an automatic schema fetch) are blocked globally. Finally, treat the base editor’s feature set as part of the threat model and security-test tools continuously — the surface keeps growing.

Status

Item	Reference	Notes
IDEsaster disclosure	Ari Marzouk (MaccariTA), 2025-12-06	30+ vulns, 24 CVEs, “Secure for AI” principle
Remote JSON schema (exfil)	CVE-2025-49150 (Cursor), CVE-2025-53097 (Roo Code), CVE-2025-58335 (Junie)	Auto-fetch of attacker-controlled $schema URL
IDE settings overwrite (RCE)	CVE-2025-53773 (Copilot), CVE-2025-54130 (Cursor), CVE-2025-53536 (Roo Code), CVE-2025-55012 (Zed)	Base-editor setting points a validator at a planted executable
Multi-root workspace (RCE)	CVE-2025-64660 (Copilot), CVE-2025-61590 (Cursor), CVE-2025-58372 (Roo Code)	Workspace file adds arbitrary roots, removing preconditions
Vendor acknowledgements	AWS-2025-019; Claude Code docs updated	Some products fixed without CVE; a few unpatched past 90 days
Exploitation in the wild	Per researcher, as of disclosure	None reported; payloads withheld to protect users

The lesson generalizes beyond editors: any autonomous agent bolted onto software that predates it inherits that software’s every feature as a potential primitive. Prompt injection is the inevitable delivery mechanism — the defense is to assume it succeeds and constrain what the agent can then do.