CVE-2026-108716: mcp-remote Information Disclosure Flaw

CVE-2026-108716 Overview

CVE-2026-108716 is a cleartext transmission vulnerability affecting mcp-remote versions 0.8.0 through 0.14.3. The flaw resides in the authorizeWithDeviceCode function, which transmits OAuth client secrets and receives access and refresh tokens without enforcing HTTPS on discovered endpoints. When the device authorization or token endpoints returned by discovery are non-loopback http:// URLs, the client proceeds with cleartext requests. On-path network attackers positioned between the client and the authorization server can capture the client secret along with issued access and refresh tokens. The weakness is categorized under CWE-319: Cleartext Transmission of Sensitive Information.

Critical Impact
On-path attackers can intercept OAuth client secrets, access tokens, and refresh tokens, enabling full impersonation of the compromised client against the authorization server.

Affected Products

mcp-remote version 0.8.0
mcp-remote versions 0.9.x through 0.14.2
mcp-remote version 0.14.3

Discovery Timeline

2026-10-11 - CVE-2026-108716 published to NVD
2026-10-16 - Last updated in NVD database

Technical Details for CVE-2026-108716

Vulnerability Analysis

The mcp-remote client implements the OAuth 2.0 Device Authorization Grant (RFC 8628) through its authorizeWithDeviceCode routine. During the flow, the client retrieves device_authorization_endpoint and token_endpoint values from the authorization server's discovery metadata. The implementation then issues HTTP POST requests to those URLs carrying the client_id, client_secret, and device code, and receives bearer tokens in the response body.

The client does not validate that the discovered endpoints use the https scheme before transmitting credentials. When a malicious or misconfigured authorization server advertises http:// endpoints — or when discovery responses are tampered with on-path — the client sends secrets in cleartext. The same code paths accept the token response over plaintext HTTP, exposing both the client secret and the issued tokens to any adversary on the network path.

Root Cause

The root cause is missing transport-layer validation in src/lib/device-authorization.ts and the client credential handling in src/lib/client-credentials.ts. The functions construct and send requests using whatever URL is returned by discovery, without enforcing a loopback exemption boundary or rejecting non-TLS endpoints. OAuth 2.0 specifications require TLS for all non-loopback token exchanges, and this check is absent.

Attack Vector

An attacker in a privileged network position — such as a shared Wi-Fi segment, a compromised upstream router, or a malicious proxy — intercepts the device authorization or token request. The attacker reads the client secret and tokens directly from the cleartext HTTP traffic. The captured credentials allow the attacker to request additional tokens, refresh existing sessions, and access MCP resources authorized to the client until the credentials are revoked. User interaction is required because the device code flow begins with a user action, but no privilege or authentication is required of the attacker.

The vulnerability mechanism is described in the VulnCheck Advisory on MCP Remote Vulnerability and the HackMD Analysis on MCP Remote. The affected code is visible in the GitHub Device Authorization Code and the GitHub Client Credentials Code.

Detection Methods for CVE-2026-108716

Indicators of Compromise

Outbound HTTP (port 80) traffic from hosts running mcp-remote to OAuth-related paths such as /device_authorization, /token, or /oauth2/*.
Discovery documents returned to mcp-remote clients that advertise non-loopback http:// values for device_authorization_endpoint or token_endpoint.
Unexpected token refresh activity or new client sessions originating from IP addresses that do not match the legitimate user population.

Detection Strategies

Inspect proxy and firewall logs for mcp-remote user-agent strings issued over cleartext HTTP to external hosts.
Correlate OAuth authorization server logs for client sessions where the same client_id appears from geographically or network-topologically unexpected sources.
Perform dependency scanning across developer workstations and build systems to inventory mcp-remote versions in the vulnerable 0.8.0 through 0.14.3 range.

Monitoring Recommendations

Enable TLS inspection or egress filtering that blocks plaintext OAuth traffic from endpoints running MCP clients.
Alert on short-lived access tokens being refreshed from multiple distinct source addresses within a single session window.
Track changes to OAuth discovery metadata served to internal clients and flag any shift from https to http endpoints.

How to Mitigate CVE-2026-108716

Immediate Actions Required

Inventory all systems and developer environments using mcp-remote and identify instances running versions 0.8.0 through 0.14.3.
Rotate any OAuth client secrets and revoke access and refresh tokens that may have been transmitted through vulnerable mcp-remote sessions.
Restrict mcp-remote connections to trusted authorization servers that publish only https endpoints in their discovery metadata.

Patch Information

At the time of publication, no fixed version is listed in the NVD record. Monitor the GitHub Repository for MCP Remote for a release that enforces HTTPS on non-loopback device authorization and token endpoints. Apply the fixed release across all affected hosts once available, and revoke credentials issued through earlier versions.

Workarounds

Configure network egress policy to block outbound TCP/80 traffic from systems that run mcp-remote, forcing all OAuth exchanges onto TLS.
Point mcp-remote only at authorization servers whose discovery metadata is verified to advertise https endpoints, and reject servers that return http URLs.
Where feasible, use loopback-only MCP server configurations so that device authorization flows do not traverse untrusted networks.

bash

# Configuration example: block cleartext OAuth egress for MCP hosts
# Replace <MCP_HOST_CIDR> with the subnet running mcp-remote clients
iptables -A OUTPUT -s <MCP_HOST_CIDR> -p tcp --dport 80 \
  -m string --string "/token" --algo bm -j REJECT
iptables -A OUTPUT -s <MCP_HOST_CIDR> -p tcp --dport 80 \
  -m string --string "/device_authorization" --algo bm -j REJECT