mcp-remote CVE-2025-6514: how an OAuth URL from a server became a command on your machine

The short answer

CVE-2025-6514 is a critical flaw (CVSS 9.6) in mcp-remote, the npm package many desktop MCP clients use to reach remote servers. Versions from 0.0.5 up to, but not including, 0.1.16 were exposed to OS command injection when connecting to an untrusted MCP server, through crafted input in the server’s authorization_endpoint URL. The fix is in 0.1.16.¹ JFrog’s researchers, who reported it, recommend upgrading and connecting only to trusted servers over HTTPS.²

If any MCP config on your machine runs npx mcp-remote without a pinned version, check which version it actually runs.

What mcp-remote is

Some MCP clients only speak the stdio transport: they start a local process and talk to it over standard input and output. mcp-remote is a small proxy that lets those clients reach remote MCP servers over HTTP, handling the OAuth sign-in on the way. JFrog describes it as a popular tool used by MCP clients, letting applications that only support local stdio connect to remote servers.² A typical config line:

Code Data in JSON, the format software uses to pass records and settings.

{ "command": "npx", "args": ["mcp-remote", "https://example.com/mcp"] }

That line runs whatever version npx resolves, on your machine, with your permissions.

What the advisory says

From GitHub’s advisory GHSA-6xpm-ggf7-wc3p:¹

The npm registry lists 0.1.16 as published on 17 June 2025.⁴ JFrog’s write-up, by Or Peles, is dated 9 July 2025.² When we ran npm view mcp-remote version on 26 October 2026, it printed 0.15.2.⁴

How the attack worked

The flaw sits in the OAuth step. When a client connects to a remote server that needs sign-in, the server tells the client where its authorization endpoint is, and the client opens that URL in a browser so the user can log in.

JFrog’s account: a malicious server returns a specially crafted authorization_endpoint value; mcp-remote passes it to the open package to launch a browser; and the crafted value causes command injection instead of opening a page.²

The effect differed by platform:²

No click on a link was needed beyond connecting to the server. The server’s own metadata did the work.

Who was exposed

JFrog names two situations: connecting to a malicious or hijacked MCP server, and connecting over plain HTTP, where an attacker on the network could intercept the traffic and supply the crafted URL.²

So the realistic exposure was people who tried MCP servers from directories, blog posts or chat messages, or who connected to servers over http:// on shared networks. Connecting only to servers you run, over HTTPS, kept the risk low even on an affected version, which is why JFrog’s second recommendation is trusted servers over HTTPS.

Check your machine

Find every config that runs it. On macOS, the usual places are the Claude Desktop config, Cursor’s, VS Code’s and project files:

Code Commands typed in a terminal. The text around it says what happens.

grep -rl "mcp-remote" \
  ~/Library/Application\ Support/Claude/claude_desktop_config.json \
  ~/.cursor/mcp.json ~/.claude.json .mcp.json .cursor/mcp.json .vscode/mcp.json 2>/dev/null

For each hit, look at the version:

• "args": ["mcp-remote", ...] with no version runs whatever npx resolves, which may be a copy cached long ago.
• "args": ["mcp-remote@0.1.16", ...] or later pins a fixed version.

Then:

1. Pin a fixed version in each config, for example mcp-remote@0.1.16 or newer, and update deliberately.
2. Check each server URL is https:// and belongs to someone you trust.
3. Remove servers you no longer use. An unused remote server is risk with no benefit.
4. If you connected an affected version to a server you don’t trust, treat the machine as possibly compromised: rotate credentials it holds and look for unexpected processes or startup items.

Pin every MCP server, not just this one

The npx some-package pattern in MCP configs is convenient and it’s the root of the exposure here. Three habits apply to every server you run that way:

• Pin exact versions (package@1.2.3), so an upgrade is a change you make and can review, not something npx does or doesn’t do behind your back.
• Read the advisory feed for what you run. GitHub’s advisory database covers npm packages; npm audit in a project that lists your MCP servers as dependencies will flag known advisories.
• Prefer servers that use stdio and touch only what they need. A server that opens browsers, spawns shells or listens on ports has more ways to go wrong than one that reads a file.

None of this would have stopped a first-day exploit. It does shorten the time you run a known-bad version from months to days.

The lesson for MCP clients

The MCP spec now has a section on exactly this class of bug. It says clients must allow only http:// and https:// schemes for authorization URLs (with http:// only for loopback during development), must reject javascript:, data:, file: and other dangerous schemes, must not use shell commands such as cmd.exe, sh or PowerShell to open URLs, and must sanitise URLs received from servers.³

The general rule: anything an MCP server sends is untrusted input, including metadata the protocol treats as plumbing. Tool descriptions, resource contents, error messages and OAuth URLs all come from the server. Our posts on token passthrough and the confused deputy and local server security cover the neighbouring risks, and MCP server security basics the wider picture.

What we don’t know

• How many people ran affected versions against untrusted servers. We’ve seen no public count.
• Whether it was used in an attack. The sources we cite describe research and a fix, not an incident.
• Whether other stdio-to-HTTP proxies have similar bugs. The spec section above is a good checklist to hold them to.

To find configs that run unpinned MCP servers, or servers the scan doesn’t recognise, paste them into the check page or run npx deedglass scan (how the grade works); to try tool-call rules in your browser, open the playground.

Written with AI assistance and checked against our claims register.