The First MCP Vulnerability That Hacks Your Laptop (Not the Server)

Algis Dumbris • 2026/04/19

The Pattern Shift Nobody Expected

Every major MCP vulnerability disclosed so far has shared one trait: the exploit runs on the server. Microsoft’s Azure MCP SSRF (CVSS 9.1) hijacked cloud credentials from inside Azure infrastructure. Amazon Bedrock’s prompt injection (CVSS 9.8) executed within AWS-managed compute. Docker’s MCP Toolkit escape (CVSS 9.6) broke container isolation on the Docker host. Atlassian’s MCPwnfluence chain pivoted through Confluence and Slack servers. In every case, the blast radius was the server — the infrastructure you connect to.

The mcp-remote vulnerability (CVSS 9.6) breaks that pattern entirely.

For the first time, the exploit runs on the connecting client’s machine. Your laptop. Your CI/CD runner. Your development workstation. The machine you assumed was safe because it was just asking for tools, not serving them.

How the Attack Works

The mcp-remote package is the standard npm library for connecting MCP clients to remote servers over HTTP with OAuth authentication. Versions 0.0.5 through 0.1.15 contain a command injection vulnerability in the OAuth handshake flow.

Here is the sequence. When an MCP client connects to a remote server using mcp-remote, the library initiates an OAuth authorization flow. As part of that flow, it fetches the server’s OAuth metadata — including the authorization_endpoint URL. The vulnerable code passes this URL to a system command (typically open on macOS or xdg-open on Linux) to launch the user’s browser for authentication.

A malicious MCP server crafts its authorization_endpoint to include shell metacharacters. Instead of a legitimate URL, the endpoint contains injected commands. When mcp-remote passes this value to the system shell, the injected commands execute with the full permissions of the user running the MCP client.

The critical detail: this happens during the connection handshake, not during tool use. The exploit fires the moment the client attempts to connect to the server — before any tool schema is retrieved, before any tool call is made, before the MCP protocol even begins its capability negotiation. The user’s machine is compromised as a side effect of trying to connect.

No prompt injection required. No malicious tool definitions. No user approval step. Just a connection attempt to a server that returns a poisoned OAuth metadata response.

Why Scanners Cannot Help

The MCP security ecosystem has developed solid static scanning tools. Cisco’s mcp-scanner analyzes tool schemas for injection vectors. Snyk’s agent-scan checks server code for vulnerabilities. AgentSeal and MCPSec validate configuration files. These tools have genuine value — they catch real vulnerabilities in server implementations and tool definitions.

None of them can detect this attack.

Static scanners operate on tool schemas and server-side code. They analyze what a server does after a connection is established. The mcp-remote vulnerability fires during the transport-layer handshake — the protocol negotiation that happens before any tool schema exists to scan. The attack surface is pre-protocol. By the time a scanner would have something to analyze, the exploit has already executed.

Runtime content inspectors face the same gap. They sit between the client and server, monitoring tool calls and responses for suspicious patterns. But this exploit does not produce a tool call. It does not generate a response that passes through a content filter. It lives entirely in the OAuth metadata exchange that precedes the MCP session.

This is not a failure of any specific scanning tool. It is a structural limitation of the scanning approach. Scanners assume a connection has been safely established and then analyze what flows through it. When the connection establishment itself is the attack vector, scanning is architecturally unable to intervene.

Quarantine-by-Default Is the Structural Answer

MCPProxy’s quarantine model was designed around a different assumption: no server should be trusted until it has been explicitly reviewed and approved. Every new MCP server starts in quarantine. Its tools are invisible to the AI agent. No connection is established to the server until an administrator reviews and approves it.

This design blocks the mcp-remote attack at the root.

No approved server means no connection attempt. No connection attempt means no OAuth handshake. No OAuth handshake means no authorization_endpoint exchange. The command injection payload in the malicious server’s OAuth metadata never reaches the client’s shell, because the client never initiates the connection in the first place.

The defense is not reactive — it does not detect the exploit and block it. It is structural — it eliminates the conditions under which the exploit can fire. The difference matters because reactive defenses require knowing what to look for. The mcp-remote vulnerability was not in any CVE database until it was disclosed. A quarantine that prevents unapproved connections does not need to know about the specific exploit. It prevents the entire class of connection-time attacks by default.

This is what admission-layer security means in practice. The gateway decides which servers are allowed to exist in the client’s universe. Everything else — scanning, content filtering, runtime monitoring — operates within that approved set. The admission layer is the one defense that works against vulnerabilities that have not been discovered yet.

30 CVEs in 60 Days and Accelerating

The MCP ecosystem has accumulated over 30 CVEs in roughly 60 days. That pace is not slowing down. If anything, the mcp-remote disclosure suggests it is accelerating and diversifying.

The early CVEs followed predictable patterns: prompt injection in tool descriptions, SSRF through URL parameters, missing authorization on sensitive operations. These are familiar web security vulnerabilities mapped onto a new protocol. Teams that already understood OWASP Top 10 could anticipate and defend against them.

mcp-remote represents something different. The attack surface shifted from server-side to client-side. The vulnerability is not in the MCP protocol specification — it is in the transport library that implements the connection. The exploit fires at a layer that most security models do not even consider part of the threat surface.

What comes next? The MCP specification is expanding. SEP-2571 proposes bidirectional write operations. The streamable HTTP transport is replacing stdio for production deployments. OAuth is becoming the standard authentication mechanism. Each expansion creates new surfaces, and the vulnerability researchers are finding them faster than the ecosystem can patch them.

The structural lesson from mcp-remote is clear: you cannot patch your way to safety when new attack classes emerge every week. You need a defense that works regardless of where the next vulnerability appears — server-side, client-side, transport-layer, or somewhere nobody has thought of yet.

That defense is admission control. Quarantine every server by default. Approve explicitly. Connect only to what you have reviewed. Everything else is perimeter, and the mcp-remote CVE just showed that the perimeter is the client.

MCPProxy is open source at github.com/smart-mcp-proxy/mcpproxy. Quarantine-by-default, BM25 tool discovery, and Docker isolation ship in every release.