Two publicly disclosed CVEs now document what security researchers had been warning about since the Model Context Protocol (MCP) launched in late 2024: MCP server vulnerabilities can hand an attacker code execution on a developer's machine, not just leak a chat transcript. In under three months, researchers at JFrog and Oligo Security independently found and disclosed critical flaws — one in the reference MCP Inspector tooling, one in the widely used mcp-remote proxy — both rated critical severity, both patched, and both instructive about where this new protocol's trust boundaries actually sit. This post walks through what's been confirmed, what's still just "disclosed" rather than CVE-numbered, and what teams running MCP servers or clients should do about it.
Why MCP Server Vulnerabilities Are a Different Risk Class
MCP is designed to let an LLM-based agent call out to external tools and data sources — a database, a ticketing system, a code host — through a standardized server interface. That design intentionally blurs a line that traditional application security depends on: the boundary between "data returned to the application" and "instructions the application acts on." An MCP server's tool descriptions, resource content, and even error messages are typically fed straight into the model's context, and a client-side proxy or inspector often executes local operations based on what a connected server tells it. That combination — untrusted server input plus a local process willing to act on it — is the common thread running through both of the CVEs below and most of the non-CVE incidents that follow them.
Two Confirmed MCP Server Vulnerabilities With CVE IDs
CVE-2025-6514 — OS command injection in mcp-remote. mcp-remote is an npm-distributed proxy that lets MCP clients which only speak local stdio (such as Claude Desktop) connect out to remote, OAuth-protected MCP servers. JFrog's security research team found that during the OAuth authorization flow, mcp-remote did not adequately validate values returned by the remote server before using them to construct a command executed on the local machine. A malicious or compromised MCP server could therefore return a crafted authorization endpoint or parameter that resulted in arbitrary OS command execution on the client host — full compromise of the developer machine, not just the agent's sandbox. NVD lists this as a critical-severity issue, with reporting at the time putting the CVSS v3.1 base score at 9.6. It affected mcp-remote versions from 0.0.5 up to 0.1.15; the maintainers shipped a fix in 0.1.16 that sanitizes and validates server-supplied values before they can influence any local command execution.
CVE-2025-49596 — Remote code execution in the Anthropic MCP Inspector. MCP Inspector is the official developer tool for testing and debugging MCP servers during development; it runs a local proxy alongside a browser-based UI. Oligo Security discovered that the proxy component listened without authentication and without validating the origin of incoming requests, which meant a malicious website — one the developer simply had open in another tab — could reach the local proxy via the browser and instruct it to execute code on the developer's workstation, a classic DNS-rebinding/CSRF-to-RCE chain against a tool that most engineers assumed was purely local and low-risk. This CVE was also rated critical, with a widely cited CVSS score of 9.4. It affected versions of MCP Inspector prior to 0.14.1; Anthropic shipped 0.14.1 with authentication added to the proxy and stricter origin checks.
Both are good examples of an "MCP CVE" pattern worth internalizing: the vulnerable code isn't the AI model, and it isn't even always the MCP server itself — it's the connective tissue (proxies, inspectors, client-side tooling) that assumes MCP servers and browser origins are trustworthy by default.
CVSS, EPSS, and KEV Context
Both CVE-2025-6514 and CVE-2025-49596 carry critical CVSS base scores (9.6 and 9.4 respectively, per NVD and vendor advisories), reflecting that successful exploitation gives an attacker code execution with the privileges of the developer running the tool. Neither had been added to CISA's Known Exploited Vulnerabilities (KEV) catalog as of this writing. That's consistent with the exploitation mechanics involved: both require a victim to take an action — connecting mcp-remote to an attacker-controlled or compromised MCP server, or having MCP Inspector running locally while visiting a malicious page — rather than being exploitable over the open internet against an unattended service. That nuance matters for prioritization: a critical CVSS score here doesn't imply internet-scale scanning risk, but it does imply that any team whose developers regularly connect to third-party or community-published MCP servers is exposed to a real, demonstrated Model Context Protocol bug with a full-compromise outcome.
Timeline
- Early-to-mid 2025: Researchers across the industry begin publishing MCP-specific attack research — prompt injection via tool descriptions, "rug pull" tool redefinition, and cross-server data leakage — establishing the threat model that later CVEs would formalize.
- Spring 2025: Oligo Security identifies the authentication gap in MCP Inspector's local proxy and privately reports it to Anthropic.
- June 2025: Anthropic ships MCP Inspector 0.14.1 closing the gap; CVE-2025-49596 is published shortly after with a critical severity rating.
- Mid-2025: JFrog's research team identifies the command injection path in
mcp-remote's OAuth handling and reports it to the maintainers. - July 2025:
mcp-remote0.1.16 is released with input validation on server-supplied OAuth values; CVE-2025-6514 is published.
Around the same window, several non-CVE but well-documented incidents reinforced the pattern: Invariant Labs disclosed a "toxic agent flow" in GitHub's MCP server in which a malicious issue filed on a public repository could manipulate an agent with combined public/private repo access into leaking private repository data; a separate report from General Analysis described a similar indirect prompt-injection path against the Supabase MCP server, where attacker-controlled support-ticket content could steer an agent with database access into exfiltrating data; and Asana disclosed a defect in its own MCP server's tenant-isolation logic that could expose one organization's data to another. None of these carry their own CVE identifiers, but they describe the same underlying MCP server exploit surface — untrusted content flowing into a privileged tool-calling context — that CVE-2025-6514 and CVE-2025-49596 formalized with concrete vulnerability IDs.
Remediation Steps
- Patch immediately. Upgrade
mcp-remoteto 0.1.16 or later, and MCP Inspector to 0.14.1 or later. If you can't confirm the version, check it — both tools are frequently pinned in developer setup scripts and forgotten. - Treat every MCP server as an untrusted input source. Don't wire an agent up to a third-party or community MCP server with the same trust level you'd give internal, reviewed code. Review tool descriptions and server responses the same way you'd review data from any external API.
- Never expose MCP Inspector or similar local dev proxies to a browser session used for general browsing. Run them in isolated profiles or containers, and confirm the version you're running actually enforces origin checks.
- Segment credentials and scopes per MCP server connection. If an MCP server only needs read access to one resource, don't hand it an OAuth token or API key scoped to everything the agent can touch — this limits blast radius when a server misbehaves or gets compromised.
- Pin and verify dependency versions for MCP tooling in CI/CD, including transitive dependencies pulled in by
mcp-remote, MCP SDKs, and any MCP client libraries, so a downgrade or malicious re-publish can't silently reintroduce a patched flaw. - Monitor for anomalous outbound behavior from processes running MCP clients or proxies — unexpected child processes, unexpected network destinations, or unexpected file writes are the practical signal of exploitation attempts against this vulnerability class.
- Subscribe to advisories from Anthropic, the MCP project's GitHub security tab, and package registries for the specific MCP packages your stack depends on, since this ecosystem is young and moving fast.
How Safeguard Helps
MCP server vulnerabilities are, at their core, a software supply chain problem: an external component — a server, a proxy, a package pulled from npm or PyPI — becomes part of your execution path, and its trustworthiness has to be verified continuously, not assumed once at install time. Safeguard is built for exactly that gap.
Safeguard continuously inventories the MCP servers, proxies, and SDK dependencies your teams actually connect to — including transitive dependencies most SBOM tools miss — and maps them against known CVEs like CVE-2025-6514 and CVE-2025-49596 the moment they're disclosed, so you're not relying on someone remembering to check a changelog. Policy controls let you require minimum patched versions before an MCP connection is permitted in CI or in developer environments, and provenance verification flags when an MCP package's published artifact doesn't match its source, closing off the exact kind of tampering that made the mcp-remote exploitation path dangerous. For the broader class of MCP server exploit that doesn't get a CVE — prompt injection, tool poisoning, tenant-isolation gaps — Safeguard's runtime monitoring watches for the anomalous process and network behavior that these attacks produce, giving security teams a detection layer even when the vulnerability itself is still unnamed. As MCP adoption accelerates across engineering organizations, that combination of dependency-level visibility, policy enforcement, and behavioral monitoring is what keeps a genuinely useful protocol from becoming an unmanaged attack surface.