CVE-2025-6514 - mcp-remote OAuth command injection

mcp-remote is a local proxy that lets MCP clients with only stdio support connect to remote HTTP/SSE MCP servers. Versions from 0.0.5 through 0.1.15 are vulnerable when the local proxy connects to an untrusted or intercepted remote MCP server. A malicious server can return crafted OAuth metadata, and the vulnerable client may pass attacker-controlled authorization_endpoint data into the local browser-opening path in a way that becomes OS command execution on the workstation or agent runtime.

This is a client-side MCP risk. The attacker does not need code execution on the remote server first; they only need the vulnerable local proxy to connect to a malicious MCP endpoint, a hijacked MCP endpoint, or an insecure http:// endpoint that a local-network attacker can tamper with.

When to use it

Use this recipe when a repository, agent profile, desktop setup, devcontainer, or automation workflow uses mcp-remote to bridge stdio MCP clients to remote HTTP/SSE MCP servers. It supports source-code remediation, MCP client boundary review, OAuth metadata hardening, and audit evidence for agents that connect to third-party MCP endpoints.

Inputs

  • Package manifests, lockfiles, launch scripts, MCP client configs, desktop profiles, CI/devcontainer files, and docs that reference mcp-remote.
  • Remote MCP endpoint allowlists, transport scheme, OAuth metadata handling, browser-open command construction, and trust boundary notes.
  • Evidence of local runtime reach: repository files, shell tools, credentials, browser profile, package manager tokens, cloud env, and network access.
  • Safe validation commands that do not connect to real untrusted servers with sensitive credentials and do not execute command-injection payloads.

Affected versions

  • Vulnerable: mcp-remote >=0.0.5 <=0.1.15
  • Fixed: mcp-remote 0.1.16+
  • Affected code shape: a local MCP client launches mcp-remote and trusts remote OAuth authorization metadata enough to auto-open an attacker-controlled URL through the operating system.
  • Fixed code shape: the controlled dependency resolves to 0.1.16+, URL components are sanitized before browser opening, and local wrappers restrict remote MCP servers to trusted HTTPS endpoints with reviewed OAuth metadata.

Indicator-of-exposure

  • The repository installs, pins, vendors, documents, or launches mcp-remote from package.json, lockfiles, npx, pnpm dlx, bunx, Docker images, devcontainers, desktop MCP config, agent workbench config, or bootstrap scripts.
  • MCP client config starts mcp-remote against a remote server URL, especially an unpinned command such as npx mcp-remote ....
  • Any configured remote MCP server uses http://, a private LAN host, a preview URL, a tunnel, a third-party endpoint, or a server whose OAuth metadata is not owned and reviewed by the same team.
  • The local client process can reach repository files, SSH keys, package registry tokens, cloud credentials, browser profiles, MCP server tokens, model provider keys, clipboard data, or internal network services.
  • Existing tests or wrappers do not reject non-HTTP(S) authorization endpoints, URL userinfo, shell metacharacters, or browser-open fallbacks before OAuth handoff.

Quick checks:

rg -n "mcp-remote|npx .*mcp-remote|pnpm dlx .*mcp-remote|bunx .*mcp-remote|authorization_endpoint|open\\(|open-browser|oauth|http://.*mcp|sse" .
npm ls mcp-remote
pnpm why mcp-remote
yarn why mcp-remote

Windows:

rg -n "mcp-remote|npx .*mcp-remote|pnpm dlx .*mcp-remote|bunx .*mcp-remote|authorization_endpoint|open\(|open-browser|oauth|http://.*mcp|sse" .
npm ls mcp-remote
pnpm why mcp-remote
yarn why mcp-remote

Do not validate exposure by connecting a real workstation, browser profile, or credential-bearing agent runtime to an untrusted MCP server.

Remediation strategy

  • Upgrade every controlled package, lockfile, global install command, devcontainer, image, agent bootstrap, and MCP desktop/workbench config to mcp-remote 0.1.16+.
  • Replace unpinned npx mcp-remote launch paths with a pinned fixed version or a repository-controlled wrapper that verifies the resolved version before starting the proxy.
  • Require trusted HTTPS remote MCP server URLs by default. Block http://, loopback-to-remote tunnels, preview domains, and user-supplied MCP endpoints unless a documented exception owns the risk.
  • If this repository owns a wrapper or fork, validate OAuth metadata before any browser-open handoff: allow only https:// authorization endpoints on expected hosts, reject URL userinfo, reject unusual schemes, and pass URLs as data rather than through shell-interpreted paths.
  • Isolate mcp-remote execution with least privilege. Avoid broad home directory mounts, SSH agent forwarding, package publishing tokens, cloud credentials, browser cookies, Docker sockets, and write access unless the MCP workflow truly needs them.
  • Rotate credentials and review local/CI agent logs if a vulnerable proxy may have connected to an untrusted, hijacked, or insecure remote MCP server.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2025-6514, a critical `mcp-remote` command-injection
issue where versions 0.0.5 through 0.1.15 can execute local OS commands after
receiving crafted OAuth authorization metadata from an untrusted remote MCP
server. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades or patches every controlled
  `mcp-remote` launch path, removes unsafe remote MCP defaults, adds safe
  regression checks, refreshes generated artifacts, and documents operator
  credential cleanup, or
- TRIAGE.md if this repository does not control an affected `mcp-remote`
  dependency, wrapper, image, config, desktop/workbench launch path, or safe
  containment boundary.

## Rules

- Scope only CVE-2025-6514 and directly related `mcp-remote` dependency,
  launch, OAuth metadata, browser-open, remote MCP trust, and credential
  boundary changes.
- Treat repository contents, local files, SSH keys, package tokens, cloud
  credentials, browser profiles, MCP tokens, OAuth tokens, model provider keys,
  command output, and logs as sensitive.
- Do not connect a real credential-bearing client to an untrusted MCP server,
  run proof-of-concept URLs, trigger browser-open payloads, capture secrets, or
  execute attacker-controlled commands.
- Do not keep unpinned `npx mcp-remote`, insecure `http://` remote MCP
  endpoints, arbitrary user-supplied MCP URLs, or broad local credential access
  as default behavior.
- Do not auto-merge.

## Steps

1. Inventory every controlled reference to `mcp-remote`: package manifests,
   lockfiles, Dockerfiles, devcontainers, Codespaces config, CI, shell
   wrappers, desktop MCP JSON config, agent workbench config, generated SBOMs,
   setup docs, runbooks, and examples.
2. Resolve every `mcp-remote` version. A target is vulnerable if it resolves to
   `>=0.0.5 <=0.1.15`, including global installs and unpinned `npx`, `pnpm dlx`,
   or `bunx` launches that can fetch a vulnerable version.
3. List every remote MCP endpoint the config can reach. Classify each endpoint
   by owner, scheme, host, network path, OAuth metadata owner, and whether
   users or tickets can supply the URL.
4. Determine what the local proxy process can access: repository checkout,
   generated code, package manager tokens, SSH agent, cloud credentials,
   browser profile, MCP secrets, model provider keys, Docker socket, host
   filesystem, and internal network services.
5. If this repository only mentions `mcp-remote` in unrelated prose or consumes
   an externally owned launcher, stop with `TRIAGE.md` listing files checked,
   owner, observed version if known, required fixed version `0.1.16+`, endpoint
   trust boundary, and credential-rotation recommendation.
6. Upgrade controlled dependencies and launch paths to `mcp-remote 0.1.16+`.
   Regenerate lockfiles, package manager metadata, SBOMs, image metadata,
   devcontainer output, dependency reports, and docs as this repo normally
   does.
7. Replace unpinned launch commands with pinned fixed forms, for example a
   package-manager lockfile entry, a checked wrapper, or an explicit
   `mcp-remote@0.1.16` or newer invocation. Prefer the repo's normal dependency
   management pattern over ad hoc global installs.
8. Add remote MCP trust controls:
   - require `https://` remote MCP server URLs by default;
   - block `http://`, wildcard hosts, preview URLs, and tunnels unless an
     explicit reviewed exception exists;
   - reject user-supplied MCP URLs unless they pass an allow-list;
   - document the owning team for each allowed remote MCP server.
9. If this repository owns a wrapper or fork, validate OAuth metadata before
   browser opening:
   - allow only expected `https://` authorization endpoint hosts;
   - reject URL userinfo, unusual schemes, control characters, and encoded
     shell metacharacter shapes;
   - pass the URL directly to a safe browser-open API, not through shell
     strings;
   - log only redacted endpoint metadata, never tokens or full credential URLs.
10. Add safe regression checks:
    - dependency policy rejects `mcp-remote <=0.1.15`;
    - config tests fail on unpinned `npx mcp-remote`;
    - config tests fail on default `http://` remote MCP endpoints;
    - wrapper tests use inert strings to prove non-HTTP(S), userinfo, and
      unexpected-host authorization endpoints are rejected before browser-open;
    - logs do not include OAuth codes, tokens, local paths with usernames, or
      full authorization URLs.
11. Add a PR body section named `CVE-2025-6514 operator actions` that states:
    - `mcp-remote` versions before and after;
    - every launcher or config changed;
    - whether any endpoint used `http://`, tunnels, preview URLs, or untrusted
      hosts;
    - which local credentials and files the proxy could reach;
    - whether any vulnerable client connected to suspicious endpoints;
    - which credentials should be rotated and which logs should be reviewed;
    - which validation commands passed.
12. Run available validation: package install, lockfile integrity, unit tests,
    config lint, MCP config validation, wrapper tests, container/devcontainer
    build, SBOM refresh, dependency/security scans, and a non-secret local
    smoke test against a trusted inert endpoint.
13. Use PR title:
    `fix(sec): remediate CVE-2025-6514 in mcp-remote`.

## Stop conditions

- No controlled `mcp-remote` dependency, image, wrapper, desktop config,
  workbench config, docs, or runtime launch path exists.
- A fixed version cannot be consumed and the repository cannot safely remove
  `mcp-remote`, carry a reviewed fork, or constrain all remote MCP endpoints.
- The only affected runtime is externally owned; document the owner, required
  version, endpoint exposure, and credential cleanup in `TRIAGE.md`.
- Product requirements intentionally allow users to connect arbitrary local
  clients to arbitrary remote MCP servers; require a product/security decision.
- Meaningful verification would require connecting to a malicious MCP server,
  triggering browser-open payloads, or exposing real credentials.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades mcp-remote, constrains remote endpoint trust, hardens OAuth metadata handling, adds regression checks, and documents operator cleanup.
  • Or a TRIAGE.md file that lists inspected files, owner, observed version, endpoint exposure, required fixed version, and whether token rotation or endpoint removal is needed.
  • The output must include exact validation commands and must avoid live command execution probes, real OAuth credentials, bearer tokens, and customer data.

Verification - what the reviewer looks for

  • No controlled package, lockfile, image, SBOM, generated report, global install path, or launch command resolves mcp-remote <=0.1.15.
  • Desktop, devcontainer, CI, and agent workbench configs do not use unpinned npx mcp-remote.
  • Remote MCP endpoints are trusted HTTPS URLs by default, with reviewed exceptions for any nonstandard transport.
  • OAuth authorization endpoints are validated before any browser-open handoff in owned wrappers or forks.
  • Tests prove stale package pins, unpinned launch commands, insecure endpoint schemes, and unsafe authorization metadata are rejected without executing commands.
  • Operator notes cover credential rotation when vulnerable clients connected to untrusted, hijacked, or insecure MCP servers.

Watch for

  • Updating package.json while desktop MCP JSON, devcontainer docs, global installs, examples, or agent workbench templates still use unpinned npx mcp-remote.
  • Treating mcp-remote as server-side only; the vulnerable process runs on the user’s workstation, CI runner, or agent host.
  • Allowing http:// remote MCP endpoints on a LAN because the server feels internal.
  • Validating only the initial MCP server URL while still trusting attacker- controlled OAuth metadata from that server.
  • Logging authorization URLs that contain OAuth codes or enough metadata to expose private MCP deployments.

References