Earlier this week, JFrog disclosed CVE-2025-6514, a critical vulnerability in the mcp-remote project that could allow an attacker to “trigger arbitrary OS command execution on the machine running mcp-remote when it initiates a connection to an untrusted MCP server.”
Mcp-remote is a project that allows LLM hosts to communicate with remote MCP servers, even if they only natively support communicating with local MCP servers, JFrog explained.
“While previously published research has demonstrated risks from MCP clients connecting to malicious MCP servers, this is the first time that full remote code execution is achieved in a real-world scenario on the client operating system when connecting to an untrusted remote MCP server,” Or Peles, vulnerability research team leader at JFrog, wrote in a blog post.
Glen Maddern, mcp-remote’s primary maintainer, quickly fixed the vulnerability, so anyone using mcp-remote should update to 0.1.16.
According to Peles, the moral of the story here is that MCP users should only connect to trusted MCP servers and should be using secure connection methods like HTTPS, since similar vulnerabilities could be found in the future. “Otherwise, vulnerabilities like CVE-2025-6514 are likely to hijack MCP clients in the ever-growing MCP ecosystem,” Peles said.
Addressing security concerns in the broader MCP ecosystem
JFrog’s discovery isn’t the first vulnerability related to MCP to come to light. Other recent CVEs include CVE-2025-49596, which detailed MCP Inspector being vulnerable to remote code execution (fixed in version 0.14.1); CVE-2025-53355, which detailed a command injection vulnerability in MCP Server Kubernetes (fixed in version 2.5.0); and CVE-2025-53366, which detailed a validation error in the MCP Python SDK that could lead to an unhandled exception when processing malformed requests (fixed in version 1.9.4).
According to the MCP documentation, some of the most common attacks in MCP are confused deputy problems, token passthrough, and session hijacking.
Gaetan Ferry, a security researcher at secrets management company GitGuardian, said “My current feeling about the protocol itself right now is that it’s not gatmature enough from a security perspective. So if even the protocol itself is not mature security-wise, you can’t really expect the ecosystem to be mature security-wise.”
He predicts we’re going to continue seeing more CVEs pop up as MCP adoption increases, and noted that right now we’re seeing a new exploitation scenario roughly every two weeks.
He said that there isn’t yet an industry consensus on best practices for using MCP safely, but some recommendations are starting to come out. His biggest recommendation is to install servers in unique trust boundaries. For example, one installation would be only for dealing with sensitive data, and another could be designated for only working with untrusted data.
Despite the lack of security in MCP, Ferry believes it’s still possible to use MCP safely if you are conscious about what you are doing when you use it. GitGuardian uses MCP internally, but it has specific guidelines that must be followed and restricts the kinds of features, servers, and data they can use.
The problem, he said, is that MCP is so young and adoption has been quick, and often when you try to go fast, security is not the first thing that is thought about. We’re past the point of no return now, with so many already having adopted it, so now we need to move forward with security top of mind.
“It’s going to be a challenge for the industry, but that’s something we’ve already faced in the past every time the industry comes up with a new exciting technology,” he said. “Microservices and APIs at some point were also kind of a revolution, and we saw the same patterns like old attacks starting to work again in a new environment, and a whole new security environment needing to be built.”
