mcp-remote OAuth discovery: SSRF findings and CVE record discrepancies

View raw markdownEdit on GitHub ↗

TL;DR

A researcher reported seven OAuth-discovery and token-handling findings in mcp-remote, the npm bridge that some Claude Desktop, Cursor and VS Code configurations use to reach remote MCP servers (about 716,000 downloads in the week to 2026-10-01, per the npm registry). Five received CVEs on 2026-09-24; CVE-2026-51995 maps to F-02 (blind SSRF), not F-10 (redirect handling). CISA-ADP scores range from 7.5 to 9.8, but several impact claims exceed the evidence in the referenced research. This advisory remains high / unconfirmed; no fixed version is established. Only connect to trusted MCP servers, and do not treat upgrading alone as a verified fix.

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. These findings concern the bridge running on the client machine, rather than the remote MCP server.

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[] — the client takes the authorization-server origin from the server's own Protected Resource Metadata and fetches /.well-known/oauth-authorization-server from it without validating that origin; the researcher's page claims blind host discovery and probing only ("No response exfiltration was demonstrated") 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", CISA-ADP CVSS 3.1 7.5)
F-04 MD5-based storage namespace (getServerUrlHash): defense-in-depth; no token namespace takeover demonstrated. The CVE description claims code execution, which the cited research does not establish. Researcher: 0.0.14–0.1.38; CVE: 0.1.16–0.1.38 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 — OAuth discovery requests follow HTTP redirects with no destination check on each hop, so a fix that validates only the first URL would be bypassed (a source-review finding) 0.1.32–0.1.38 (none listed)
F-11 Explicit token-origin checks in the SSE wrapper: defense-in-depth. The reviewed SDK checks origins and the redirect implementation strips cross-origin credentials; no token theft demonstrated. Researcher: 0.0.18–0.1.38; CVE: 0.1.18–0.1.38 CVE-2026-52001

The researcher dates the private report to 2026-02-17, revalidation to 2026-05-03 and public disclosure to 2026-07-31. The private-report date has not been independently verified. The research repository's v1.0.1 is a corrected advisory release, not a patched mcp-remote version.

Correction — 2026-10-02: this table previously assigned CVE-2026-51995 to F-10 and listed F-02 without a CVE. The CNA reference identifies F-02. F-09 and F-10 have no CVE in this published batch. The earlier description of F-11 as a token leak also overstated the referenced research, which documents dependency controls preventing that path in the reviewed configuration.

Severity review — 2026-10-02

Registry scores checked 2026-10-28. Scores belong to the named provider.

CVE Finding Provider / CVSS Vector Provider updated
CVE-2026-51994 F-01 CISA-ADP / 3.1: 9.1 Critical CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N 2026-09-25
CVE-2026-51995 F-02 CISA-ADP / 3.1: 7.5 High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N 2026-09-24
CVE-2026-51996 F-04 CISA-ADP / 3.1: 9.8 Critical CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H 2026-09-29
CVE-2026-51997 F-08 CISA-ADP / 3.1: 8.8 High CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H 2026-09-25
CVE-2026-52001 F-11 CISA-ADP / 3.1: 7.5 High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N 2026-10-06

Score update 2026-10-07. CISA ADP added a CVSS 3.1 7.5 High (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) to CVE-2026-52001 / F-11 on 2026-10-06; the CNA container is unchanged (no MITRE metrics), NVD still lists the record as Deferred with the ADP score as Secondary, and OSV's description-derived range still reads 0.1.38 as fixed. The score is attributed above. It does not change the F-11 assessment: the finding remains a defence-in-depth token-origin check with no demonstrated token theft, and a C:H vector is CISA's reading of the MITRE description, not new evidence. severity: high / status: unconfirmed stand. Snapshots under sources/cve-evidence/ were refreshed the same day.

Snapshot refresh 2026-10-08. The --live evidence gate flagged CVE-2026-52001's OSV record again; reviewing stored vs live showed the only change was the OSV modified timestamp (metadata churn) with identical severity vector and affected range, plus routine NVD timestamp churn on the batch. No score, version or mapping changed. Snapshots re-synced and the attributed-score block's "checked" date rolled to 2026-10-08; the F-11 editorial assessment and every attributed score are unchanged.

Snapshot refresh 2026-10-22. The --live gate flagged the OSV records for all five CVEs, CVE-2026-51994 through CVE-2026-51997 and CVE-2026-52001 (modified 2026-10-21). Reviewing stored against live: OSV replaced the git-range event fixed: 02619aff… with last_affected: 02619aff… and removed the description-derived introduced/fixed 0.1.38 SEMVER events, listing v0.1.38 among the affected versions instead. OSV therefore no longer claims 0.1.38 is a fixed version, which matches the CVE descriptions and removes the version conflict recorded below; the scores and vectors are unchanged. Snapshots refreshed; no advisory severity changed.

MITRE supplied no CVSS metrics in these five CNA containers. The four scores above come from CISA ADP Vulnrichment; NVD carries them as Secondary metrics and lists all five records as Deferred, with no NVD-authored CVSS assessment in the fetched records. NVD, GitHub and OSV copies of the same CVE are not independent confirmation. The vectors matter: CISA's vector for CVE-2026-51997 includes UI:R, meaning its score assumes a user must take some action, while the other three scored records assume none (UI:N).

Assessment: retain severity: high and status: unconfirmed. The discovery findings warrant prompt attention because a configured hostile server can direct requests into the client's reachable network. However, F-01/F-02 demonstrate request issuance, not response exfiltration; F-04 establishes a weak-hash hardening concern, not code execution; F-08 is source review with impact dependent on browser and target-service behavior; and F-11 is defense-in-depth with positive dependency controls. The CVE descriptions' code-execution claims for F-04/F-08 are not demonstrated in those sources.

This is an editorial assessment of the batch, not a replacement CVSS score. Keeping high avoids presenting unverified code execution as established; the trade-off is a headline rating below CISA's Critical scores. Those scores remain visible above. Reassess if a vendor confirms impact or fixes, independent research demonstrates the stronger claims, or the registry evidence changes.

Version conflict: OSV's description-derived ranges mark 0.1.38 as fixed for all five CVEs, while the CVE descriptions include it in the affected range. Do not use that OSV boundary as proof of a fix. F-04 and F-11 also have different starting versions in the CVE records and researcher pages, shown in the table. See the evidence review for exact fields, vectors and source links.

Package status (checked 2026-10-02). 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 recommends an additional wrapper-level origin check; the researcher did not demonstrate token forwarding across origins in the reviewed dependency set. 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. Check the version actually installed or launched; a configuration snippet alone does not establish it.

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 versions: see each finding's range above. F-01/F-02/F-10 concern 0.1.32–0.1.38; F-04/F-11 are hardening findings, not demonstrated exploits.
  • 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. Update the installed bridge and verify the version your client launches. Version 0.14.3 was the latest checked on 2026-10-02; it is not a verified fix for this batch. @latest selects a moving release, while @0.14.3 is an explicit version pin.
  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 connected to an untrusted server, review activity and consider revoking the associated OAuth tokens as a precaution. These findings do not establish that your tokens were stolen. For signs of cloud-credential exposure, see 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.
  • The MCP specification already tells client authors how to close these paths. Its Security Best Practices — SSRF section names the resource_metadata URL, the authorization_servers list and redirect chains as attacker-controlled inputs, and says clients SHOULD block private, loopback and link-local ranges and validate redirect targets; RFC 9728 §7.7 separately flags fetching authorization-server metadata on a resource server's say-so as an SSRF risk and tells clients to take precautions such as blocking internal address ranges. If you write or choose an MCP client, check that it does this.
  • Keep MCP clients and bridges updated and check the version actually launched; do not infer patch status from a registry range alone.
  • Restrict cloud metadata access from agent environments. A response hop limit alone does not block a process running on the instance from reaching metadata. Review network isolation and instance-role permissions: prevention/credential-hygiene.md.

Update 2026-10-11 — an eighth finding from a second researcher: the --device-code grant sends the client secret and receives tokens over plain HTTP when discovery returns a non-loopback HTTP endpoint (CVE-2026-108716, VulnCheck, CVSS 4.0 6.0); still no fixed version, still 0.14.3

VulnCheck published CVE-2026-108716 on 2026-10-11 for mcp-remote 0.8.0 through 0.14.3: authorizeWithDeviceCode "sends client secrets and receives tokens without enforcing HTTPS endpoints," so when the discovered device-authorization and token endpoints are non-loopback HTTP URLs, an on-path attacker captures the client secret and the issued access and refresh tokens. CWE-319; CVSS 4.0 6.0 (AV:N/AC:L/AT:P/PR:N/UI:P/VC:H), CVSS 3.1 5.3, both VulnCheck's. Credit: HaiND, Post and Telecommunication Institute of Technology, who is not the researcher behind the seven findings above. The record's references are the researcher's HackMD write-up (which returned sign-in boilerplate instead of content on the sweep date) and two permalinks into src/lib/device-authorization.ts and src/lib/client-credentials.ts at v0.14.3.

This finding is outside the F-table above and is not part of its evidence manifest. It belongs to the same class the table documents: the bridge trusts what the server's discovery metadata tells it, here the scheme of the endpoints it will post a secret to. It applies only to the device-code grant, which an operator selects with --device-code; the default browser-redirect flow is not in the record. Fix status: npm still shows 0.14.3 (2026-09-21) as latest on 2026-10-11, no release references the CVE, and the vendor repository has no advisory for it. Status stays unconfirmed for the batch as a whole. The CNA-validated range for this one finding is the strongest evidence in the file. Readers using --device-code against a server they do not control should stop until a release enforces HTTPS; the batch write-up this CVE arrived in is the VulnCheck single-researcher wave.

Sources