OX Security’s April 15 disclosure of what it called the “Mother of All AI Supply Chains”1 placed five AI-powered IDEs under the same MCP RCE umbrella. Four required at least one user interaction to complete the attack chain. Windsurf did not. CVE-2026-306152, scored CVSS 8.0 HIGH by CISA-ADP on April 27, is the formal record of that distinction.
The April 15 Disclosure: Why Windsurf Got Its Own CVE
The OX Security technical advisory3 categorized CVE-2026-30615 as “MCP Vulnerability Family #3: Unauthenticated command injection via MCP configuration edit through prompt injection.” The classification is precise: this is not a flaw in MCP’s STDIO trust model as a protocol concept. It is an IDE-specific implementation decision that gave Windsurf’s AI agent autonomous write access to mcp.json when it encountered attacker-controlled HTML.
The CVE covers Windsurf version 1.9544.26. No patch from Windsurf or Codeium has been publicly verified as of April 29, 2026.
How the Exploit Chain Works: HTML to mcp.json to STDIO RCE
The attack path described by OX Security3 runs in three steps. Attacker-controlled HTML reaches Windsurf’s rendering surface, which in an agent context can arrive via a malicious repository, a poisoned documentation page, or a prompt injection in a connected tool. Windsurf renders the HTML. The agent then writes a new STDIO server entry into the local mcp.json without prompting the user. On the next agent invocation, the registered command executes.
That “next invocation” detail is load-bearing. The exploit does not fire at render time. The payload waits in the config for the agent’s next session. The user interaction the attacker avoids is the config-write confirmation, not the command execution itself.
NVD lists2 the CVSS 3.1 vector as AV
/AC/PR/UI/S/C/I/A. The local attack vector (AV) reflects that the malicious HTML must reach the IDE’s rendering process. Zero privileges required (PR) and zero user interaction (UI) describe what happens afterward. The high integrity and availability scores (I/A) describe the consequence: the agent executes whatever command the attacker registered.The Zero-Click Gap: Why Cursor, VS Code, Claude Code, and Gemini-CLI Escaped CVE Assignment
OX Security tested five IDEs1: Windsurf, Cursor, VS Code, Claude Code, and Gemini-CLI. The result was not close.
| IDE | User interaction required for MCP config write |
|---|---|
| Windsurf 1.9544.26 | None (zero-click) |
| Cursor | At least one approval step |
| VS Code | At least one approval step |
| Claude Code | At least one approval step |
| Gemini-CLI | At least one approval step |
The four IDEs that required at least one approval step did not escape MCP risk entirely. The underlying STDIO trust model means any agent that can write to mcp.json is one prompt injection away from a privileged command execution. What separates them from Windsurf is one confirmation dialog.
The absence of a CVE for the other four is not a finding that those implementations are sound. It reflects the specific property Windsurf lacks: a friction point where a cautious user could refuse. Windsurf removed that moment entirely.
Anthropic’s “Expected Behavior” Stance and the Unpatched Protocol
According to The Hacker News4, Anthropic declined to modify MCP’s protocol architecture after being notified, characterizing the STDIO trust behavior as “expected.” That characterization has not been verified against a primary Anthropic statement and should be treated as medium confidence.
The logic behind it is at least internally consistent: MCP does not prohibit agents from writing STDIO entries, and whether to require confirmation before config edits is an IDE-level decision. Anthropic’s position, if accurately reported, is that the protocol did what it was designed to do. Windsurf’s agent did something the protocol permitted but did not require.
The practical consequence is that remediation has no protocol-level backstop. Each IDE vendor has to independently decide that mcp.json is a privileged-execution surface and enforce that decision in their implementation. The April 15 advisory makes clear what the cost of not doing so looks like.
What Windsurf Users Should Do Until a Patch Ships
With no verified patch available, defense reduces to configuration hygiene and surface-area reduction.
Inspect mcp.json before starting agent sessions. Any STDIO entry that was not manually added is suspect. Diffing the file against a known-good state before each session catches unauthorized additions. The OX Security advisory5 does not specify a canonical file location, so consult Windsurf’s documentation for its path on your platform.
Restrict what content the agent renders. The exploit requires attacker-controlled HTML to reach Windsurf’s rendering surface. Narrowing which sources the agent can pull from is the only available reduction in exposure until a patch ships.
The design question CVE-2026-30615 forces is not unique to Windsurf: any IDE that auto-renders untrusted content near an agent-writable configuration file carries the same structural risk. Whether mcp.json is a user preference file or a privileged-execution surface is not a cosmetic choice. NVD’s CVSS 8.0 score2 is the documented cost of treating it as the former.
Frequently Asked Questions
Does CVE-2026-30615 affect Windsurf versions older than 1.9544.26?
The CVE’s scope lists 1.9544.26, but that version’s public changelog (January 30, 2026) documents only UI fixes, suggesting the autonomous mcp.json write behavior predates this release. Users on any recent Windsurf build should not assume they are unaffected simply because they run an older version number.
How does this differ from the other MCP vulnerabilities disclosed on April 15?
OX Security organized its findings into distinct vulnerability families. CVE-2026-30615 sits in Family #3 (unauthenticated injection via config edit through prompt injection), while the other April 15 findings address different trust boundaries in the STDIO model. Those other families affected multiple IDEs but required user interaction, which is why no additional CVEs were assigned for the config-write path in Cursor, VS Code, Claude Code, or Gemini-CLI.
Are AI IDEs beyond the five OX Security tested vulnerable to the same zero-click pattern?
Any IDE that renders HTML and grants its agent unchaperoned write access to configuration files shares the structural risk. The five tested tools are current market leaders, but newer or niche AI coding tools that follow the ‘agent autonomously manages preferences’ pattern should be audited for the same auto-write behavior before adoption in security-sensitive environments.
What defenses work beyond manually inspecting mcp.json?
Filesystem-level controls add independent layers: setting mcp.json to read-only between editing sessions blocks unauthorized writes entirely, and file integrity monitors (inotify-based watchers on Linux) can alert on modifications in real time. Endpoint-protection rules that restrict which binaries the IDE process can spawn also limit damage even if a malicious STDIO entry makes it into the config.