At A Glance
- CVE-2025-6514 is a critical (CVSS 9.6) remote code execution flaw in mcp-remote, disclosed by JFrog Security Research in July 2025 and fixed in version 0.1.16.
- A malicious or hijacked MCP server can execute arbitrary commands on a connected client’s operating system, no complex exploit chain required.
- Patching closes this specific hole. It doesn’t change the underlying assumption that let it happen: AI clients trust the network path to an MCP server by default.
- A Zero Trust architecture, where every MCP server and client gets its own verified identity and no endpoint listens for inbound connections, removes the exposure the flaw depends on
If you’re an AI platform leader, you’ve spent the past year saying yes: yes to new agents, yes to new tools, and yes to the MCP connectors that let your models reach the systems your business runs on.
JFrog’s security research team disclosed CVE-2025-6514 in July 2025, handing every platform lead a reason to slow down and read the fine print. This critical remote code execution vulnerability in mcp-remote carries a CVSS score of 9.6, and the mechanics behind it say more about how AI clients are built than any single patch can fix. Here’s what actually happened, and why the fix goes deeper than a version bump.
How CVE-2025-6514 Enables Remote Code Execution
The flaw lives in the OAuth authorization flow of mcp-remote, an npm package that bridges clients to remote MCP servers over HTTP. When a client connects, a malicious or hijacked MCP server can return a crafted authorization_endpoint URL, and mcp-remote passes that unsanitized string straight to the operating system. On Windows, the result is full arbitrary command execution on the developer’s machine. On macOS and Linux, an attacker can launch arbitrary executables with more limited control. JFrog’s research team described it as the first time full remote code execution had been achieved in the real world on a client operating system connecting to an untrusted remote MCP server.
Two scenarios trigger it: a developer connects to a server that an attacker controls or has already compromised, or a developer connects over plain HTTP to a legitimate server while an attacker on the local network sits in the middle. Either path ends the same way: code running on your engineer’s laptop, inside your network, using their credentials.
Why Patching mcp-remote Doesn’t Fix the Underlying Risk
Patching closes this hole, but it doesn’t close the category. CVE-2025-6514 is one entry in a fast-growing list of MCP vulnerabilities, and the pattern underneath them rarely changes: an AI client extends implicit trust to whatever sits on the other end of a network connection. The attack rode in on the transport, and the client trusted that transport by default.
Why AI Clients Trust MCP Servers by Default
MCP is spreading through your organization the way early APIs did, with enthusiastic developers wiring up connections faster than any security team can inventory them. Every one of those connections widens the surface you now have to defend, and most of them never crossed a review. When the connection model assumes the network is safe, every new server becomes a new place for something to go wrong: an exposed port, a crafted redirect, a man-in-the-middle on an unencrypted hop, or a server that looked trustworthy last week and got compromised this week. Each one turns your AI platform’s reach into the attacker’s reach.
Zero Trust flips that assumption. Rather than trusting a network path and hoping the far end behaves, a Zero Trust overlay issues every MCP server and every client a strong, certificate-based identity, and it evaluates an explicit authorization policy before it establishes a session. No verified identity and no matching policy means no connection. Each endpoint dials outbound to the overlay fabric rather than listening for inbound connections, which lets the MCP server run with no ports exposed to the underlying network. An endpoint an attacker cannot see or address is one they cannot scan, fingerprint, or exploit in the first place. NetFoundry’s MCP and LLM Gateways apply this exact model, wrapping MCP traffic in Identity-First Reachability™ so the servers behind them are invisible to anything without a verified identity.
End-to-end encryption closes the second gap. Traffic between the client and the server travels inside a mutually authenticated, encrypted session that runs from one endpoint straight to the other, so no one and nothing in between can inspect it. The local network, an intermediary device, and a compromised hop along the path all see the same thing: ciphertext. None of them can read, alter, or hijack a connection they cannot decrypt (for a closer look at what this looks like in practice, see how a private MCP server connection is built).
How to Close the MCP Trust Gap
Treat the patch as table stakes and the architecture as the actual work. Inventory every MCP client and server your teams have deployed, and confirm none of them run a vulnerable mcp-remote build. Then ask the harder question about the next CVE, because there will be one. Build your MCP connectivity on a foundation where identity, not network location, decides who talks to whom, and where a compromised or impersonated server has nothing to reach and no session to intercept.
The teams that scale AI safely won’t be the ones that patched fastest. They’ll be the ones who stopped trusting the network underneath their agents. NetFoundry’s Identity-First Reachability™ approach to AI security was built for exactly this problem: MCP servers, LLMs, and AI agents that run with no open inbound ports and no reachable attack surface, regardless of what the next disclosure turns out to be. Treat CVE-2025-6514 as your invitation to see what that looks like for your own MCP deployment.
Frequently Asked Questions
What is CVE-2025-6514?
CVE-2025-6514 is a critical vulnerability (CVSS 9.6) in mcp-remote, an npm package that connects AI clients to remote MCP servers. It lets a malicious or compromised server run commands on the connecting client’s machine. JFrog Security Research disclosed it in July 2025, and it’s fixed in mcp-remote version 0.1.16 and later.
How does the mcp-remote vulnerability actually work?
The flaw sits in mcp-remote’s OAuth authorization step. A malicious MCP server can send back a crafted authorization URL that mcp-remote passes to the operating system without checking it first, which lets the server run commands on the client’s machine, most severely on Windows.
Is updating mcp-remote enough to be safe?
Updating fixes this specific flaw, but it doesn’t address why an AI client trusted an untrusted server’s response in the first place. At NetFoundry, we see that same trust assumption behind most MCP-related vulnerabilities, which is why we recommend architecture-level controls, not just patch management, for any team running MCP at scale.
How does Zero Trust prevent this kind of MCP exploit?
A Zero Trust MCP architecture gives every client and server a verified identity and requires an explicit policy match before any session opens. Servers dial out instead of listening for inbound traffic, so there’s no open port for an attacker to reach in the first place, and traffic is encrypted end to end so nothing in between can intercept or alter it.
