Your MCP Config Is the Attack Surface Now

When I wrote that your MCP server is an attack surface, I was describing one layer of a problem that had already spread further than I gave it room for. Here's where it's gone since, because it changes the threat model in a way worth catching up on.

Opening a folder is now enough

The AI coding tools people actually use, Cursor, Windsurf, Amazon Q, Claude Code, VS Code, all read their MCP server list from config files that live inside the project itself: .mcp.json, .cursor/mcp.json, .amazonq/mcp.json, and the rest. And many of them load that config automatically the moment you open the folder.

Now look at what an MCP config actually contains. For each server, it specifies a command to run and the arguments to run it with. Those aren't descriptions. They're execution instructions. A config file is, functionally, a shell script your IDE runs on your behalf.

Put those two facts together and you have the attack. A malicious MCP config, sitting in a repository, is code execution waiting for you to open the folder. No install, no approval, and in the worst cases no interaction at all. Researchers filed a zero-click RCE (CVE-2026-30615) against one popular AI IDE where attacker-controlled content the editor rendered silently rewrote the local MCP config and registered a hostile server, with no prompt and nothing required beyond the project loading. In a major cloud vendor's coding extension, a crafted config in a repo could pull cloud credentials the instant the folder opened. Multiple independent teams found the same shape across the major agentic IDEs: auto-load the workspace config, run it, ask the human never.

And it's being weaponized at scale

The worst example in the first piece was a single bad server that turned hostile after three tool calls. The update is that this is now being done with worms. One documented campaign planted malicious MCP config files across dozens of public GitHub repositories, including a project owned by a major cloud provider, harvesting credentials from any developer who opened an affected repo in a vulnerable IDE.

The delivery methods are the boring, effective ones: a pull request to a popular project, a typosquatted package, a compromised dependency that quietly writes a config, even repositories dangled through fake job interviews, a tactic researchers have tied to state-level actors. And the configs leak the other direction too. Scans have turned up tens of thousands of secrets sitting in MCP config files committed to public GitHub, because people treat the config as settings rather than the sensitive executable it is.

The bugs also climbed into the shared layer

Alongside the config vector, the plain CVE stream didn't slow down. It moved upward. The pattern from last time, one flaw in a widely-used component hitting everyone downstream, kept repeating at the ecosystem's shared layers: an actively-exploited critical authentication bypass in a popular MCP server, more remote-code-execution holes in reference servers, and a supply-chain classic where a malicious update to a Postmark MCP server silently BCC'd every email it sent. The lesson that mcp-remote taught with a single dependency and four hundred thousand installs is now the whole ecosystem's recurring experience.

The one genuinely good development

It isn't all worse. The thing I couldn't point to when I wrote the first piece is starting to exist: an immune system. There are now dedicated scanners that audit an .mcp.json for leaked secrets, over-broad auto-approve permissions, and tool-poisoning before you ever run it. There are security wrappers you can put in front of an untrusted server so it can't reach past what you allow. There are shared, open threat-rule catalogs built for exactly these attacks. None of that existed in usable form a year ago. The field filling up with people building MCP security tooling is the one trend here working in your favour, so use what they've built.

What to actually do now

Everything from the first piece still holds: authenticate your servers, least-privilege every tool, treat inputs, results, and tool metadata as untrusted. Add these, because the config vector is new ground.

Treat every repository you clone as if it carries a hostile MCP config, because some of them do. Turn off automatic MCP-server registration from workspace files wherever your IDE allows it, so opening a folder can't silently run anything. Read a config before you let a tool load it, the same way you'd read a shell script before running it, which is exactly what it is. Scan configs on untrusted projects with one of the auditors that now exist. And keep your own configs out of version control and clear of secrets, so you're not the repo leaking credentials into someone else's scan.

The mental-model update is one line. Last time: treat your MCP server like the privileged internet-facing service it actually is. This time: treat every MCP config file like the executable it actually is, because opening a project folder has quietly become a way to get owned. The attack surface didn't shrink since I wrote that first piece. It moved closer to you.