In July 2025, a JFrog researcher found a way to get full command execution on a developer's machine by doing nothing more than connecting to the wrong server. The flaw lived inside mcp-remote, a small proxy tool that lets AI clients like Claude Desktop and Cursor talk to remote Model Context Protocol servers. It scored 9.6 out of 10 for severity. JFrog called it the first known case of full remote code execution achieved in the wild through an untrusted MCP connection.
The maintainer patched it within days. The npm package moved to version 0.1.16. Everyone moved on.
Nine months later, a different research team found the same category of flaw baked into the official MCP SDKs themselves, the code every other MCP server is built on top of. Not a rogue package this time. The reference implementation, in Python, TypeScript, Java, and Rust. Anthropic reviewed the finding and declined to change the architecture, calling the behavior expected.
That's the actual story. Not one vulnerable package that got fixed. A pattern that keeps resurfacing because of how the protocol treats trust.
What Most Teams Think an MCP Server Is
Most engineering teams treat an MCP server the way they treat a VS Code extension: something you add from a marketplace, that runs inside some kind of sandbox, that's safe by default because enough other people already installed it. That mental model is wrong, and the gap between what people assume and what actually happens is where the damage gets done.
An MCP server is a live process with the ability to execute tool calls on your behalf, often with the same file system, network, and shell access as the developer running it. It receives responses from wherever it's configured to look, and it treats parts of those responses as instructions to act on, not just data to read. This isn't a bug. It's the entire premise of the protocol: the model asks a question, the tool answers, and something downstream acts on that answer immediately.
The failure mode has a name. It's called command injection: when a program doesn't clearly separate the data it's processing from the instructions it executes, an attacker who controls the data can make the program run their command instead. That's precisely what happened in mcp-remote. A malicious server's authorization response contained a crafted URL. The client didn't just read it. It passed that value straight into a system command.
One Root Cause, Five Different Codebases
mcp-remote wasn't an outlier. Look at the disclosures from the past year and the same failure pattern shows up in unrelated projects, built by unrelated teams, shipped for unrelated purposes.
In April 2026, OX Security went further and found the same root cause sitting inside the official MCP SDKs, the libraries every one of those projects and thousands of others import directly. Their research, titled "The Mother of All AI Supply Chains," put a number on the exposure: over 150 million downloads, more than 7,000 publicly accessible servers, and an estimated 200,000 vulnerable instances in total. They identified four distinct ways to trigger it, including a zero-click path through prompt injection in IDEs like Windsurf and Cursor that requires no user interaction at all.
Anthropic's response was to leave the architecture as is. Not because the finding was wrong, but because fixing it at the protocol level would mean changing behavior that thousands of downstream projects now depend on. That's the part worth sitting with. This isn't a queue of unpatched CVEs waiting for attention. It's a design decision the ecosystem now has to build around, because the standard's steward isn't going to build the fix in for them.
MCP Servers Skip the Scrutiny npm Packages Get
Software supply chain security spent the last decade building tooling most engineers now take for granted. Lockfiles. Software composition analysis. Provenance attestation. A team adding a new npm dependency to a production service can, at minimum, run a scanner against it before merging.
MCP servers largely skip all of that, despite running with equal or greater privilege. Adding one to Claude Desktop or Cursor takes about as much scrutiny as installing a browser extension: paste a config block, restart, done. Few teams pin versions. Fewer read the source of a server before granting it filesystem or shell access.
BlueRock Security scanned more than 7,000 public MCP servers in early 2026 and found 36.7 percent potentially exposed to server-side request forgery, a flaw where an attacker tricks the server into making requests to internal systems it shouldn't reach. In one proof of concept against Microsoft's MarkItDown MCP server, researchers used exactly that path to pull AWS credentials straight from an EC2 instance's metadata endpoint. A misconfigured tool integration became a direct line into cloud infrastructure, and nothing about the exploit required a zero-day.
The Registry Doesn't Check Who's Publishing
Not every MCP compromise requires a technical vulnerability at all. In February 2026, Straiker's STAR Labs documented an operation that skipped code flaws entirely. A group calling itself SmartLoader spent three months building five fake GitHub developer personas, cross-forking each other's repositories to look like an active community, before submitting a trojanized version of a popular Oura Ring MCP server to a public registry.
The fork was functionally identical to the legitimate server. It passed as normal for months. Once installed, it quietly deployed an infostealer that pulled browser passwords, cloud session tokens, Discord credentials, SSH keys, and cryptocurrency wallet files, disguising its persistence mechanism as a Windows audio process. No CVE, no patch, no vendor to notify. Just patience and a registry with no moderation standing between a developer and a production credential store.
Why Teams Keep Getting Caught by This
The pattern behind all three problems is the same. MCP's entire pitch to engineering teams is speed: connect an agent to a new tool in an afternoon instead of waiting on a procurement cycle or a security review. That speed is real, and it's why adoption moved as fast as it did. It's also why the review step that used to catch this class of risk got skipped almost everywhere.
The GitHub Copilot remote code execution disclosed in August 2025 shows the same human factor from a different angle. An attacker didn't need to breach a network. They needed a config file, .vscode/settings.json, to get edited automatically by an agent nobody was watching closely enough to notice. Most teams don't have a mental category for "a JSON file is now an attack surface." They're building one in real time, usually after something has already gone wrong.
MCP made connecting an agent to a hundred tools take an afternoon instead of a quarter. That part of the pitch is true, and it's why teams adopted it as fast as they did. What the pitch leaves out is that revoking trust from a bad connection now takes exactly as little effort as granting it in the first place, which means most teams haven't built a process for doing either one deliberately. The protocol didn't create bad judgment. It just removed the friction that used to catch it before it shipped.
Top comments (0)