mcp-remote (the npm bridge Claude Desktop / Cursor / VS Code use to reach remote MCP servers; ~784K downloads/week) — five CVEs assigned 2026-09-24 for a seven-finding OAuth-discovery audit the researcher published 2026-07-31: a hostile MCP server's WWW-Authenticate metadata URL is fetched with no SSRF guard (CVE-2026-51994), browser-launch URL validation still lets loopback/private/metadata addresses through after the 2025 RCE fix (CVE-2026-51997), MD5-keyed token storage (CVE-2026-51996), SSE token-origin scope (CVE-2026-52001), metadata info leak (CVE-2026-51995, CVSS 7.5); reviewed range 0.1.16–0.1.38, no vendor advisory, package now maintained under a new owner at 0.14.x

View raw markdownEdit on GitHub ↗

TL;DR

mcp-remote is the npm shim that turns a stdio-only MCP client into a client for a remote (HTTP/SSE) MCP server, handling the OAuth dance; it is what Anthropic's own docs told Claude Desktop users to put in claude_desktop_config.json, it pulls ~784,000 downloads a week, and it was the subject of the first MCP-client RCE (JFrog's CVE-2025-6514, July 2025). On 2026-09-24 the GitHub Advisory Database's mcp recency listing showed five new CVEs against it — CVE-2026-51994 (SSRF via the resource_metadata URL a remote server supplies in its WWW-Authenticate header), CVE-2026-51995 (information disclosure through the authorization-server-metadata code, NVD CVSS 7.5), CVE-2026-51996 and CVE-2026-51997 (recorded as "execute arbitrary code," through the MD5 getServerUrlHash storage namespace and the open() browser-launch functions respectively), and CVE-2026-52001 (SSE transport eventSourceInit fetch wrapper leaks the token across origins). All five were assigned by MITRE on 2026-09-24 and reference a researcher's own advisory repository, playb0t/mcp-remote-oauth-security, published 2026-07-31 after a February report and a May revalidation; the reviewed range is 0.1.16 through 0.1.38. There is no vendor advisory (the package's security tab is empty), no maintainer statement, and the package has since changed hands — versions ≤ 0.2.0 point at geelen/mcp-remote, 0.11.0+ at punkpeye/mcp-remote (Glama), now at 0.14.3 — with release notes that harden OAuth (RFC 8707 resource indicators, RFC 9207 iss validation, PKCE fixes) but never mention these findings. Whether any of the seven is closed in 0.14.x is not established; this file is unconfirmed for that reason. Practical position: run the newest mcp-remote, only point it at MCP servers you trust, and remember the thing being attacked is the client on the developer's laptop — a hostile server is the attacker.

What happened

What mcp-remote is. Local MCP clients (Claude Desktop, Cursor, Windsurf, VS Code's MCP support in older versions) speak stdio; remote servers speak Streamable HTTP or SSE with OAuth. mcp-remote sits in between: the client launches npx mcp-remote https://server.example/mcp, and the shim performs OAuth discovery against the server, opens the browser for the authorization step, stores the tokens under ~/.mcp-auth/, and proxies the session. Every remote-MCP configuration that predates native HTTP support in the client goes through it — which is why its download count is in the hundreds of thousands a week and why a bug in it is a bug on the developer's machine, not the server's.

The 2025 precedent. JFrog's JFSA-2025-001290844 (CVE-2025-6514, CVSS 9.6, published 2025-07-09, affected 0.0.5–0.1.15) showed a malicious MCP server returning a crafted authorization_endpoint URL that mcp-remote handed to the OS, giving command execution on Windows. The fix in 0.1.16 added URL validation before the browser launch. The 2026 findings pick up exactly there.

The seven findings (researcher's numbering; two carry no CVE). From the playb0t/mcp-remote-oauth-security README and the per-finding pages fetched this sweep:

ID Finding Reviewed range CVE
F-01 SSRF via unvalidated resource_metadata URL — the client "accepts a resource_metadata URL from an MCP server's WWW-Authenticate header and retrieves it without proper validation of the protocol, hostname, or address type" during OAuth discovery; reaches "localhost services, private network addresses, or cloud metadata endpoints accessible from the user's machine" 0.1.32–0.1.38 CVE-2026-51994
F-02 Blind SSRF via authorization_servers[] 0.1.32–0.1.38 (none listed)
F-04 MD5-based storage namespace (getServerUrlHash) — flagged as defense-in-depth by the researcher; NVD text says "execute arbitrary code via … the getServerUrlHash function" 0.0.14–0.1.38 (NVD: 0.1.16–) CVE-2026-51996
F-08 Incomplete internal-address validation before browser launch — "The security patch addressing CVE-2025-6514 introduced URL sanitization for browser launch operations. However, the validation mechanism accepted HTTP(S) URLs while failing to block access to loopback addresses, private IP ranges, link-local addresses, or cloud metadata service endpoints" 0.1.16–0.1.38 CVE-2026-51997
F-09 OAuth credentials stored in cleartext 0.0.11–0.1.38 (none listed)
F-10 Redirect validation bypass 0.1.32–0.1.38 CVE-2026-51995 (NVD: "obtain sensitive information via the src/lib/authorization-server-metadata.ts, src/lib/utils.ts components", CVSS 3.1 7.5)
F-11 Token-origin binding on the SSE transport (eventSourceInit fetch wrapper) — the stored token is sent without checking the origin it is being sent to 0.0.18–0.1.38 CVE-2026-52001

The researcher's framing: "REMOTE METADATA IS NOT PASSIVE DATA. Every URL, redirect, origin, and credential handoff is a trust decision." Timeline from the repository: initial report 2026-02-17, revalidation 2026-05-03, public disclosure 2026-07-31; the repository's own "corrective release v1.0.1" refers to the advisory set, not to mcp-remote. No maintainer response is documented there. Note that the CVE↔finding mapping above is taken from the reference URL in each NVD record (each CVE links one F-xx page), and that NVD's "execute arbitrary code" wording for CVE-2026-51996 and CVE-2026-51997 is stronger than the researcher's own severity for F-04 ("defense-in-depth") — prefer the researcher's page for what each bug actually does.

Where the package is now. npm view mcp-remote time: 0.1.16 = 2025-06-17, 0.1.32 = 2025-12-17, 0.1.38 = 2026-02-05, 0.1.39 = 2026-08-21, 0.2.0 = 2026-08-24, 0.3.0 = 2026-08-26, 0.11.0 = 2026-09-11, latest 0.14.3 = 2026-09-21. repository.url is geelen/mcp-remote through 0.2.0 and punkpeye/mcp-remote from 0.11.0; the sole npm maintainer is punkpeye (Glama). The new repository's README credits Glen Maddern as original author and has no security section; its release notes from 0.8.3 to 0.14.3 describe OAuth work — "use the MCP server URL, not the authorization server, for the RFC 8707 resource indicator" (0.8.6), "stop concurrent sign-ins clobbering each other's PKCE verifier" (0.8.4), "forward the callback iss to finishAuth for RFC 9207 validation" (0.14.0) — and none mention SSRF, private-address filtering, redirect validation, token storage, or any CVE. The repository's security-advisories tab says "There aren't any published security advisories." So the 0.1.38 ceiling in every CVE is the last version the researcher reviewed, not a fix boundary; nobody has stated which, if any, later version closes each finding.

Why it matters for vibe coders. The attacker model is a remote MCP server you connect to — a marketplace listing, a vendor's hosted server, a URL from a README or a skill. F-01/F-02 turn OAuth discovery into an SSRF from the developer's laptop (cloud metadata endpoints included, if the laptop is a cloud dev box); F-08 means the "open your browser to log in" step can still be pointed at internal services after the 2025 fix; F-11 means a stored token can be replayed to an origin the server chooses. This is the same shape as the official Rust SDK's client-side token-theft bugs (rmcp CVE-2026-63127, CVE-2026-63128 and CVE-2026-64684) and the ToolHive/Obot entries in the same file: the MCP client trusts what the server's metadata says. Because most of this audience configured mcp-remote by copy-paste months ago and never updated the npx line, the installed version is whatever npx cached — often a 0.1.x.

Am I affected?

# Any MCP config that launches mcp-remote?
grep -rn 'mcp-remote' ~/.claude* ~/.cursor ~/.codeium ~/.config/Code/User 2>/dev/null
grep -n 'mcp-remote' ~/Library/Application\ Support/Claude/claude_desktop_config.json 2>/dev/null
# Which version does npx actually run? (cached npx installs live here)
ls ~/.npm/_npx/*/node_modules/mcp-remote/package.json 2>/dev/null | xargs -I{} sh -c 'grep -m1 \"version\" {}'
npm ls -g mcp-remote 2>/dev/null
# Stored OAuth material the findings concern
ls -la ~/.mcp-auth/ 2>/dev/null
  • Reviewed-vulnerable: any 0.1.16 → 0.1.38 (F-01/F-02/F-10 need ≥ 0.1.32).
  • Unknown: 0.1.39 → 0.14.3 — no fix statement exists; treat as "run the newest and limit which servers you point it at."

If you are affected

  1. Pin the launcher to the newest release (npx -y mcp-remote@latest …, or mcp-remote@0.14.3 explicitly) and clear the npx cache so an old 0.1.x is not reused.
  2. Remove mcp-remote entries for servers you do not fully trust; for clients that now speak Streamable HTTP natively, drop the shim.
  3. If you ever connected to an untrusted or unknown remote MCP server through mcp-remote, treat the OAuth tokens under ~/.mcp-auth/ as exposed and revoke them at the provider; if the machine had cloud credentials or a metadata endpoint reachable, → playbooks/rotating-cloud-credentials.md; general triage → playbooks/if-an-mcp-server-was-malicious.md.

Prevention

  • A remote MCP server is untrusted input to your client — its discovery metadata, redirect targets and auth URLs included. Only add servers from publishers you would install a package from: prevention/mcp-hygiene.md.
  • Keep MCP clients and bridges on latest and re-check the npx cache: a copy-pasted npx mcp-remote line freezes whatever version was current the day it was pasted.
  • Run agents on cloud dev boxes without an instance-metadata credential path (IMDSv2 hop limit 1, or no instance role) so a client-side SSRF cannot reach it: prevention/credential-hygiene.md.

Sources