Path & Payload

The SDK Maintainer Called It Expected Behavior, but the CVE Trail Says Otherwise

Amazon patched a flaw in Amazon Q Developer this week that let a malicious workspace execute commands after a developer opened and trusted it, exposing the developer’s active AWS context. Tracked as CVE-2026-12957, the bug sat in how the tool handled .amazonq/mcp.json, a configuration file that defines Model Context Protocol servers. According to Wiz Research, once the workspace was trusted, Amazon Q could load the MCP configuration and launch the configured process with access to the developer’s environment, including AWS credentials, CLI tokens and other local session material. AWS’s bulletin likewise frames the vulnerability around a maliciously crafted workspace that a local user opens and trusts.

Four months earlier, the same root behavior surfaced in three other AI coding tools, each by a different mechanism. Read together, they describe something more durable than a string of vendor bugs. In each case, a configuration file controlled by someone other than the developer — whoever owns the repository, the rendered page, or the registry entry — turned into a process running with the developer's own permissions. And in each case, the consent step meant to stop that handoff failed in a different way.

The Root Cause Anthropic Declined to Patch

OX Security's April 15, 2026 disclosure, titled “The Mother of All AI Supply Chains,” traced a version of this problem to the MCP SDK itself, across every officially supported language: Python, TypeScript, Java, and Rust. The researchers found that the SDK's STDIO transport passes configuration values directly into the command used to spawn the server process, with no sanitization step between the two.

OX reports that it shared this finding with Anthropic privately ahead of publication and recommended a protocol-level fix, such as manifest-only execution or a command allowlist built into the SDK, changes that would have applied automatically to every project built on it. According to OX's account, Anthropic called the behavior “expected” and declined to change the SDK's architecture, characterizing the STDIO execution model as a secure default and placing the sanitization responsibility on the developers building on top of it.

The Register sought comment from Anthropic directly for its coverage of the disclosure and did not receive a response, which is worth noting: the “expected behavior” framing comes from OX's account of a private exchange, not from a public statement in Anthropic's own words. OX's writeup states that Anthropic updated its SECURITY.md file nine days after the researchers' initial contact, adding guidance to use STDIO adapters with caution, without making architectural changes to the SDK. VentureBeat's reporting on the disclosure quotes OX's reaction to that update directly: “This change didn't fix anything.”

The vendor side of the dispute deserves equal weight. Per OX's account in coverage from The Register, Google, Microsoft, and Anthropic each pushed back specifically on the zero-click IDE category, arguing that because modifying the configuration file requires explicit user permission in the first place, the downstream execution isn't a vulnerability in their own products so much as an expected consequence of a file the user already chose to change.

That's a position about how each vendor's IDE handles a file once it exists. Google and Microsoft are commenting on their own products as consumers of MCP, not on the protocol itself. The decision to leave the SDK's STDIO transport unchanged is Anthropic's alone to make, since Anthropic maintains the reference implementation many MCP consumers build on or look to for defaults.

The IDE-level argument holds up cleanly for Cursor and Claude Code, where a human did approve something at some point in the chain. But it doesn’t hold up for Windsurf, where OX's CVE-2026-30615 finding shows the configuration file changed itself, with the prompt injection arriving through rendered content the user never approved touching anything.

OX put a number on the resulting exposure: more than 150 million combined downloads of the affected SDKs, over 7,000 publicly reachable MCP servers, and an estimated 200,000 vulnerable instances in total, extrapolated from the ratio of exposed to total servers OX could enumerate.

Four CVEs, One Unpatched Assumption Underneath Them

The Amazon Q, Claude Code, Cursor, and Windsurf flaws are not, strictly, four instances of the same bug. Each vendor built its own consent flow on top of the SDK, and each consent flow failed differently. But all four sit downstream of the same starting condition: a protocol whose reference implementation treats the command that launches a server as ordinary configuration rather than as code, and whose maintainer has stated a position that sanitizing that command is the responsibility of whoever builds on top of it.

That's a defensible position for a developer running a single MCP server they wrote themselves, where the configuration source is the developer's own keyboard. But it’s a harder position to hold at the scale MCP has actually reached, where configuration increasingly arrives from a cloned repository, a rendered web page, or a marketplace listing, none of which the end user wrote or fully controls. The four vendor patches reviewed here each addressed their own consent flow. None of them changed the underlying assumption that process-launch instructions in configuration can be treated like ordinary metadata.

Until the SDK Changes, the Burden Sits With You

For the immediate Amazon Q flaw: update to Language Servers for AWS 1.69.0, per AWS's bulletin, which also closes a second symlink-related flaw, CVE-2026-12958. The minimum patched plugin versions are VS Code 2.20, JetBrains 4.3, Eclipse 2.7.4, and the Visual Studio toolkit 1.94.0.0.

More broadly, the pattern across all four incidents points to the same operational habit: treat any MCP configuration file as untrusted input regardless of where it came from, regardless of whether it was approved once already, and regardless of whether the tool in front of you re-prompts on modification. Audit .mcp.json, mcp.json, and equivalent files in cloned repositories before opening them in an agentic IDE. Where a tool offers it, disable auto-approval settings like Claude Code's enableAllProjectMcpServers. And treat a vendor's claim that "the user already approved this" as a meaningful defense only when the modification path genuinely runs through the user, which Windsurf's case shows it does not always do.

The Bottom Line

Three vendors patched their own consent failures, and each patch made its own product safer. But none of them (and none could) touch the assumption underneath all four incidents: that a string in an MCP configuration file is safe to hand to a shell until something proves otherwise. That assumption lives in the SDK, and the SDK is Anthropic's to fix.

OX Security pushed for a protocol-level change and, by its own account, was told the behavior was expected. Google and Microsoft's separate pushback on the zero-click IDE classification is a narrower claim about their own products, not a defense of the SDK decision. Until the SDK changes, every team building on MCP inherits the sanitization work Anthropic has said belongs to them, whether or not they know they've inherited it.

Sources

#Perspectives