mcp-remote OS Command Injection from Untrusted MCP Servers - CVE-2025-6514

CVE-2025-6514 is an OS command injection flaw in mcp-remote, the proxy that lets MCP clients such as Claude Desktop talk to remote MCP servers. JFrog Security Research disclosed it with a CVSS score of 9.6, and it stands out because the victim is the connecting client, not the server. This advisory covers what was disclosed, why an mcp-remote command injection lands on the agentic-endpoint layer, and how to inventory and govern the remote servers your endpoints reach.

What happened

JFrog Security Research reported CVE-2025-6514 (tracked as GHSA-6xpm-ggf7-wc3p) in mcp-remote, an OS command injection flaw rated CVSS 9.6. mcp-remote is widely deployed to bridge a local MCP client to a remote MCP server. The root cause is inadequate sanitization of the authorization endpoint URL returned during the OAuth authorization flow: a hostile server responds with a crafted URL value that mcp-remote processes in a way that executes it, injecting commands onto the connecting client's machine. The affected versions are 0.0.5 through 0.1.15, and the issue is fixed in mcp-remote 0.1.16.

JFrog described this as the first documented case of full remote code execution on the client operating system originating from a remote MCP server. That inverts the usual MCP threat model, where the exposed server is the target - the same server-side pattern seen in the STDIO by-design command execution class. The impact varies by platform: on Windows the flaw yields arbitrary shell command execution with full parameter control, while on macOS and Linux it executes arbitrary executables with more limited parameter control. The practical takeaway is plain - connecting to a remote MCP server you do not control is itself a code-execution risk, which is why this case sits in the broader 2026 MCP CVE wave of disclosures that reduce to untrusted input crossing a trust boundary.

Why this is an agentic-endpoint risk

mcp-remote is not a passive library. It is the component an AI agent uses to reach tools that live on a remote MCP server, running with the agent's privileges on a managed endpoint. The flaw fires on the everyday path - a client opening an outbound connection to a server during normal use - not on an edge case. A developer adds a remote MCP server to unblock a task, the client connects, and the server's crafted response runs code locally before any tool call is even made.

This exposure is hard to see from the controls you already run, because it lives in the AI artifact layer. The remote server target sits in a local config file a developer edits; the mcp-remote process looks legitimate to EDR; the network sees encrypted agent traffic to an endpoint that may be perfectly reachable; and DLP sees nothing at rest. MCP servers and the proxies that reach them are part of the eight AI artifact types adopted bottom-up that report to no security tool - the dynamic that makes AI agents and MCP servers the new shadow IT. The question is not whether a given mcp-remote build is patched; it is which endpoints run a vulnerable version and which remote servers they are pointed at, and you cannot answer that without an inventory of the artifact layer.

How Anomity surfaces and governs it

Patching mcp-remote to 0.1.16 closes this specific flaw, but the durable control is to treat the outbound connection to a remote MCP server as a trust boundary and govern which servers endpoints reach and which tool calls run. Anomity does that in three steps.

First, inventory. Anomity inventories every MCP server an endpoint is configured to reach - including remote servers brokered through mcp-remote - as part of the eight AI artifact types it tracks. It captures the configuration metadata, including the mcp-remote version and the remote server targets each agent connects to, so you can find builds in the 0.0.5 through 0.1.15 range and the endpoints pointed at servers you do not control. Metadata only: secrets are redacted on the endpoint before anything leaves it.

Second, decide at the hook. On agents that expose a hook - for example, the PreToolUse event in Claude Code - Anomity evaluates each tool call against your policy and returns allow, deny, or log before the call runs. A tool call routed through a remote server that is not on your trust list can be denied at the boundary, which is exactly the control runtime governance provides while a vulnerable mcp-remote build is still being rolled forward across the fleet.

Third, keep the record. Every decision, and every added, changed, or removed MCP server or remote target, lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. When a CVE like CVE-2025-6514 is published, you can answer which endpoints ran the affected versions, which untrusted servers they connected to, and what those connections were allowed to do - from a record, not a guess. Anomity complements your Network, EDR, DLP, and GRC tooling; it covers the artifact layer those tools were never built to inventory.

You can't govern what you can't see.The Anomity principle

What to check across your fleet

• Inventory every endpoint running mcp-remote and record the installed version; flag anything in the 0.0.5 through 0.1.15 range and upgrade to 0.1.16 or later.
• Enumerate the remote MCP servers each endpoint is configured to connect to, and separate the servers you operate from third-party servers you do not control.
• Treat any outbound connection to an untrusted remote MCP server as a code-execution risk, regardless of mcp-remote version, and require a trust decision before it is allowed.
• Confirm high-risk tool calls routed through remote servers are evaluated at the agent hook with allow/deny/log, so a call through an untrusted server is stopped before it runs.
• Verify that every connection target and every server change is written to a 90-day audit trail and routed to your SIEM, so you can answer scope questions when the next client-side MCP CVE lands.
• Cross-reference this inventory against sibling disclosures such as the STDIO by-design command execution class to find endpoints exposed to more than one MCP code-execution path.

CVE-2025-6514 is a reminder that the MCP client is a target, not just the server: connecting to a remote server you do not control can run code on the connecting machine. Upgrade mcp-remote to 0.1.16, then inventory which remote servers your endpoints reach and govern the resulting tool calls at the hook. For the full MCP attack surface, trust tiers, and the 2026 CVE wave this sits within, see the pillar guide on MCP server security. To see Anomity inventory and govern the MCP layer across your fleet, request early access.