Can just connecting to a malicious remote MCP server run code on my computer? What was the mcp-remote vulnerability (CVE-2025-6514), and how do I protect myself?

What should I check, step by step?

1. Find every mcp-remote entry in your MCP client configs (claude_desktop_config.json, .cursor/mcp.json, Windsurf and others) and pin a patched version in the args, for example "mcp-remote@0.1.16" or a later release, so you know which version runs instead of whatever npx resolves.

2. Where your client supports remote MCP servers directly, use that instead of a local proxy. JFrog noted in July 2025 that Cursor, Windsurf and Claude Desktop (paid plans) had added direct remote connections.
3. Connect only over https. JFrog's second attack scenario was a server reached over plain http on a local network, where anyone on the LAN who can intercept the traffic can play the malicious server.
4. Add a remote server only if you know who runs it. A URL in a README, forum post or a teammate's config file is a request to let that server's operator send your client data that it will act on.
5. If you build an MCP client or proxy, validate authorization URLs from server metadata before opening them: allow only https (http only for localhost, 127.0.0.1 or ::1 in development), reject every other scheme, and open them with a non-shell API, never cmd.exe, sh or PowerShell.
6. Apply the same suspicion to the other URLs a server hands you during discovery: resource_metadata, authorization_servers and token_endpoint. The spec's SSRF section says to block private and link-local ranges, including 169.254.169.254 cloud metadata, and validate each redirect hop.
7. Run MCP clients and local proxies as your normal user, never as administrator or root, and keep credentials such as SSH keys and cloud tokens out of what that user account can read where you can.
8. If you ran an affected version against a server you don't fully trust, treat the machine as possibly compromised: check for unfamiliar processes and startup items and rotate credentials that were reachable from it.

How did the mcp-remote CVE-2025-6514 vulnerability work?

mcp-remote is a local stdio proxy: the client starts it with npx and the server's URL, and it forwards traffic to the remote server over HTTP. When the remote server answered 401, mcp-remote started the OAuth flow from the MCP TypeScript SDK: it fetched /.well-known/oauth-authorization-server, registered a client, built an authorization URL from the server's authorization_endpoint value with new URL(), added the query parameters, and called open() on it to start a browser.

• On Windows, the open package runs the URL through a PowerShell command. JFrog showed that file:/c:/windows/system32/calc.exe launched an executable, that PowerShell's $( ) subexpression inside a URL ran a command, and that a made-up scheme such as a:$(cmd.exe /c whoami > c:\temp\pwned.txt) avoided URL-encoding of spaces and gave full command execution. On macOS and Linux, open uses the open and xdg-open commands without a shell, so a file URL could still launch an executable, with less control over its arguments.
• GitHub's advisory (GHSA-6xpm-ggf7-wc3p) lists affected versions as >= 0.0.5, < 0.1.16 and the patched version as 0.1.16. JFrog thanked mcp-remote's maintainer, Glen Maddern, for a prompt fix.

How must MCP clients validate OAuth authorization URLs from a server?

The MCP security best practices (2026-07-28) have a section on OAuth authorization URL validation that names this class of bug: a malicious server supplying a javascript: URL that a client passes to window.open() (XSS), or a URL with shell metacharacters that a client opens through cmd.exe, PowerShell or a shell script (command execution).

• Clients MUST only allow http and https authorization URLs, with http acceptable only for loopback addresses during local development; MUST reject javascript:, data:, file:, vbscript: and other dangerous schemes, and SHOULD use an allowlist rather than a blocklist; MUST NOT use shell commands to open URLs; and MUST sanitize and validate all URLs received from MCP servers. Web-based clients SHOULD set a Content Security Policy such as script-src 'self'.
• The same page explains why this matters more in proxy setups: if a client-side bug gives an attacker script execution, and a local proxy can spawn stdio MCP servers as child processes, a stolen proxy token can turn a web bug into running commands on the host. It recommends sandboxing spawned processes and logging all stdio launches.

Why is adding a remote MCP server a trust decision?

A remote MCP server controls more than its tool list. During connection and sign-in it supplies metadata URLs your client fetches and opens, and afterwards it supplies tool descriptions and results your model reads. CVE-2025-6514 was in the first part, before any tool was called, which is why reviewing a server's tools alone wouldn't have caught it.

• JFrog's closing advice applies beyond mcp-remote: connect only to trusted servers over https, because similar bugs could turn up elsewhere in the MCP ecosystem. Keep clients and proxies updated, and check advisories for the ones you run.