Your MCP Config File Is Executable Code, and Two October Bugs Prove It

If your developers run AI coding agents, you have a new class of file on every workstation that behaves like a startup script: the MCP configuration. Whatever writes to it decides what runs on that machine the next time the IDE opens or the agent signs in to a server. Two disclosures in October made that concrete, and neither one needed the model to do anything clever. They needed the plumbing around the model to trust a string it shouldn't have.

My take: stop treating MCP setup as developer preference and start treating it like any other autostart location. Inventory it, control who and what can change it, and alert when it changes.

Two bugs, one shape

The first is in opencode, the open-source coding agent. Pillar Security's Eilon Cohen published a write-up showing that a malicious remote MCP server could get code execution on Windows and WSL during the MCP OAuth flow. The server advertises an authorization endpoint, opencode hands that URL to the open npm package to launch a browser, and the pinned version of that package built a PowerShell command that wrapped the URL in double quotes. PowerShell expands $(...) inside double quotes. So a perfectly valid-looking HTTPS URL carried a command. Affected versions are 1.0.137 through 1.18.32, and the fix landed in 1.18.33 on September 28.

The second is in GitHub Copilot inside Visual Studio and SQL Server Management Studio. Johann Rehberger documented CVE-2026-103572, which Microsoft rated Important at CVSS 8.8 and fixed on the October 13 Patch Tuesday. Copilot is supposed to ask before editing protected files like .mcp.json. The check compared filenames as strings, and Windows quietly drops a trailing period, so a write to .mcp.json. sailed past the check and landed on .mcp.json. Feed the agent a prompt injection through a file or a tool result, and it adds an attacker's stdio server to the config and enables it. In Visual Studio, the same trick could rewrite the ripgrep path in Copilot's settings so the next code search ran whatever binary the attacker chose. His demo popped calc.exe.

Different vendors, different languages, same failure. Untrusted data reached the code that launches processes. The Cloud Security Alliance put the two side by side under the same label: MCP launch paths as remote code execution.

The part that should bother ops teams

The opencode fix shipped with no CVE and no security advisory. Per Pillar, Anomaly's response to the report was that "trying to deal with a malicious MCP server is outside our threat model." As Infosecurity Magazine reported, that means conventional scanners and dependency alerts won't flag affected installs. If your vulnerability program runs on CVE feeds, this one is invisible to you.

I understand the vendor's position, and I don't accept it. A coding agent that connects to remote servers and launches local processes based on what those servers say has malicious servers in its threat model whether the vendor writes it down or not. Copilot's bug makes the same point from the other side. Microsoft built a confirmation gate for exactly these files, and a one-character path quirk walked through it. Rehberger's conclusion is the right one: controls around agents "must hold even when the agent itself is compromised."

That's the operating principle I'd adopt. Assume the agent will eventually be talked into doing something dumb. The question is what it can touch when that happens.

What I would do this week

Patch first. Get opencode to 1.18.33 or later on any Windows or WSL machine, and apply the October Visual Studio and SSMS updates. Because opencode has no CVE, you'll have to find it the old-fashioned way: query your endpoint inventory for the binary or the global npm package rather than waiting for the scanner to tell you.

Then treat MCP config like a Run key:

• Watch .mcp.json and the agent settings files the same way you watch scheduled tasks and startup folders. Any change made by the IDE process or the agent itself, rather than by a person in an editor, is worth an alert.
• Add EDR detections for odd children of the developer tools. devenv.exe, ssms.exe or a Node-based agent spawning powershell.exe -EncodedCommand is not normal developer behavior.
• Publish an approved list of MCP servers, pinned to origin, and make adding a new one a reviewed change. Remote servers that nobody vetted are the opencode attack in its entirety.
• Require a human to review any agent-authored diff that touches MCP, IDE or task-runner configuration. Most teams already gate CI pipeline changes this way. This is the same risk on the workstation.
• Put the agent somewhere it can't hurt much. A dev container or a disposable VM for agent work turns a full workstation compromise into a container you throw away.

And in procurement, ask the question directly: does your agent treat MCP servers as untrusted, and will you issue a CVE when it doesn't? A vendor that says no has told you how much of the patching work will land on you.

None of this argues for pulling agents off developer machines. They earn their keep. But the security model can't live inside the agent's judgment or a confirmation dialog. It has to live in the file system, the endpoint and the change process, where ops teams already know how to enforce it.