The JFrog security team recently discovered a serious vulnerability in the open-source project mcp-remote.
The bug, registered as CVE-2025-6514, allows an attacker to execute arbitrary operating system commands on the machine running mcp-remote as soon as it connects to an untrusted MCP server. This allows for full remote code execution on the client, a scenario that until now had only been discussed theoretically within the MCP community.
Mcp-remote is designed to allow LLM hosts to communicate with external MCP servers, even if they normally only support local communication. According to JFrog researcher Or Peles, this is the first time that an attack from an MCP server on a client has been successfully carried out in a real-world situation. The risk of connections between MCP clients and malicious servers had already been pointed out, but this vulnerability makes that risk concrete.
Important precautions
Users of mcp-remote are advised to update to version 0.1.16. At the same time, JFrog emphasizes the importance of precautions such as using secure connection methods and only connecting to trusted MCP servers.
This discovery is not an isolated incident. Vulnerabilities have also been reported in related MCP projects, including a bug in MCP Inspector that allowed remote code execution, a command injection vulnerability in the Kubernetes implementation of MCP Server, and a validation error in the MCP Python SDK. Although all of these bugs have since been fixed, their accumulation points to broader structural challenges in the ecosystem.
Attack techniques easy to apply
According to Peles, the rapid adoption of MCP is partly to blame for the lack of standardization in security. Commonly used attack techniques, such as token passing, session hijacking, and the confused deputy problem, can be applied relatively easily if implementations do not set clear boundaries for trust and access control. He argues that it is essential to implement servers within separate trust domains, for example by strictly separating sensitive and untrusted data.
The current situation is reminiscent of previous technological shifts, such as the rise of microservices and APIs, where initially known vulnerabilities reappeared in a new form. MCP is at a similar point in its development. According to Peles, going back is no longer an option. The only way forward is to make security central to the design and implementation of everything related to MCP from now on.