川崎元 (@foryangxin) on X

What it is

CVE-2025-6514 is an OS command injection (CWE-78, CVSS 9.6) in mcp-remote, an npm bridge that local clients such as Claude Desktop use to reach remote MCP servers. Versions 0.0.5 through 0.1.15 are affected. It was published on July 9, 2025 and fixed in 0.1.16. The thread argues that the risky moment in an MCP connection is the login step, which happens before any tool is called.

How it works

During OAuth discovery the client fetches metadata from the server and opens the returned authorization_endpoint in a browser. The server chooses that string. mcp-remote passed it to the open package, which on Windows goes through PowerShell. The JFrog advisory showed arbitrary OS command execution with full parameter control on Windows. Its PoC value was:

file:/c:/windows/system32/calc.exe

On macOS and Linux the same flaw ran arbitrary executables, but with limited parameter control.

Preconditions / Affected

• The client runs mcp-remote 0.0.5 to 0.1.15.
• The user connects to an MCP server they do not control. No authentication or tool call is needed first.
• Windows is the worst case. macOS and Linux are affected with less control over parameters.

What to do

• Upgrade mcp-remote to 0.1.16 or later. Pin bridge tool versions and check them.
• Sandbox third-party bridges, or run them as a low-privilege user.
• Treat all discovery metadata URLs as untrusted. Parse them with a real URL parser, allowlist https, and show the full host to the user.
• Never open URLs through cmd.exe, sh or PowerShell.
• Follow the MCP spec Security Best Practices. Clients MUST allow only http and https for authorization URLs, with http only for loopback in local development. They must reject javascript:, data:, file:, vbscript: and other dangerous schemes. The spec calls for an allowlist, not a blocklist.
• Apply SSRF rules to discovery. The spec warns that discovery URLs can target internal addresses such as 169.254.169.254, so block private and link-local ranges.

Caveats

The thread says the fix closes one bug, not the pattern. Any client with its own OAuth flow can let a server-controlled string reach an OS opener. Scheme allowlisting also does not stop a convincing https phishing login page. The thread poses this as an open question and gives no fix for it. It also gives no detection guidance and no check for whether a given install was exploited.