# 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?

**Short answer:** Yes, if the client mishandles what the server sends during sign-in, and it happened. CVE-2025-6514 (CVSS 9.6, published July 9, 2025, found by Or Peles of JFrog) affected mcp-remote versions 0.0.5 through 0.1.15, the npm proxy many people used to connect Claude Desktop, Cursor and Windsurf to remote MCP servers. When a server asked for OAuth, mcp-remote fetched its authorization-server metadata and passed the authorization_endpoint URL to the open npm package to launch a browser. On Windows that went through PowerShell, so a crafted value ran any command the attacker chose; on macOS and Linux it could launch an arbitrary executable with limited control over arguments. No tool call or click on anything suspicious was needed beyond adding the server and connecting. It's fixed in 0.1.16. The MCP security best practices now require clients to accept only https (or http on loopback for development) authorization URLs, reject javascript:, data:, file: and other schemes, and never open URLs through a shell. Upgrade or pin mcp-remote to 0.1.16 or later, prefer your client's built-in remote MCP support, connect only to servers you trust over https, and treat adding a remote server like installing software.

## Checklist
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.

## Ask Rightshold (free, no key)
Add the MCP server https://www.rightshold.com/mcp to Claude, Cursor, ChatGPT, Grok or VS Code (one-click setup: https://www.rightshold.com/start?ref=seo), then ask: "Before I add this remote MCP server to my client, what does it serve right now, has that changed from what was recorded, and does any tool definition carry hidden text?"

```json
{
  "tool": "precall_check",
  "arguments": {
    "url": "<the server's https MCP URL>"
  }
}
```
- Free, no key. It probes the server's tool definitions and compares them with any recorded fingerprint, scans them for invisible text, and reports standing security flags, reviews from KYA-verified agents and tool-name collisions. Checking a server doesn't register it.
- It doesn't inspect the server's OAuth metadata or authorization URLs, test your client for this CVE, or tell you which mcp-remote version you have. Pin a patched version and use a client that validates authorization URLs.

_Rightshold reports what an MCP endpoint serves and what it has on record about it. It doesn't scan your machine or your MCP client configuration, check package versions, or detect compromise, and an unchanged answer isn't a finding that a server is safe to connect to._

## Sources
- [JFrog: Critical RCE Vulnerability in mcp-remote: CVE-2025-6514 Threatens LLM Clients (July 9, 2025)](https://jfrog.com/blog/2025-6514-critical-mcp-remote-rce-vulnerability/)
- [GitHub Advisory Database: GHSA-6xpm-ggf7-wc3p, mcp-remote OS command injection (CVE-2025-6514)](https://github.com/advisories/GHSA-6xpm-ggf7-wc3p)
- [NVD: CVE-2025-6514](https://nvd.nist.gov/vuln/detail/cve-2025-6514)
- [MCP specification 2026-07-28: Security Best Practices (OAuth Authorization URL Validation, SSRF, stdio proxies)](https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices)

## Related
- [How to vet an MCP server before installing it](https://www.rightshold.com/answers/how-to-vet-an-mcp-server-before-installing-it)
- [How to pin MCP server versions and review changes before upgrading](https://www.rightshold.com/answers/how-to-pin-mcp-server-versions-and-review-changes-before-upgrading)
- [How to block SSRF and path traversal in MCP tool URL arguments and resource templates](https://www.rightshold.com/answers/how-to-block-ssrf-and-path-traversal-in-mcp-tool-url-arguments-and-resource-templates)
- [How to sandbox a local stdio MCP server to only the files and hosts it needs](https://www.rightshold.com/answers/how-to-sandbox-a-local-stdio-mcp-server-to-only-the-files-and-hosts-it-needs)

_Not legal advice. Updated 2026-11-10. JSON: https://www.rightshold.com/answers/can-connecting-to-a-malicious-remote-mcp-server-run-code-on-my-machine-mcp-remote-cve-2025-6514.json_