CVE-2026-108716 in mcp-remote
Summary
by MITRE • 10/11/2026
mcp-remote 0.8.0 through 0.14.3 contains a cleartext transmission vulnerability in authorizeWithDeviceCode that sends client secrets and receives tokens without enforcing HTTPS endpoints. When discovered device authorization and token endpoints are non-loopback http URLs, on-path network attackers can capture the client secret plus issued access and refresh tokens.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The mcp-remote library versions 0.8.0 through 0.14.3 exhibit a critical security flaw related to insecure data transmission during the device authorization flow. This vulnerability specifically affects the authorizeWithDeviceCode function, which is responsible for initiating authentication sequences that rely on out-of-band device codes. In these affected versions, the implementation fails to enforce HTTPS endpoints when communicating with discovery-based device authorization and token endpoints. Instead of mandating secure transport layer encryption, the library permits connections over plain HTTP if the discovered URLs do not utilize loopback interfaces such as localhost or 127.0.0.1. This design oversight creates a significant attack surface for network adversaries who can intercept sensitive authentication materials in transit.
The technical root cause lies in the conditional logic used to determine transport security requirements. The code incorrectly assumes that non-loopback URLs might inherently be secure or ignores protocol validation entirely when dealing with remote endpoints. Consequently, when an application utilizes this library to authenticate via device codes against a server configured with HTTP rather than HTTPS, all subsequent communications remain unencrypted. This includes the transmission of client secrets and the reception of issued access tokens and refresh tokens. These credentials are essential for maintaining authenticated sessions and accessing protected resources within the target service. The absence of certificate validation or protocol enforcement means that any entity capable of monitoring network traffic between the client application and the authentication server can observe these values in plaintext.
The operational impact of this vulnerability is severe, as it compromises the confidentiality and integrity of user credentials. An on-path attacker positioned at various points along the network route, such as within a public Wi-Fi hotspot, compromised router, or through sophisticated man-in-the-middle attacks, can capture the client secret alongside the newly issued access and refresh tokens. Possession of these tokens allows the attacker to impersonate the legitimate user without needing their password or multi-factor authentication credentials. The compromise extends beyond immediate session hijacking; because refresh tokens are often long-lived, attackers can maintain persistent unauthorized access even after initial sessions expire. This undermines the security guarantees provided by OAuth 2.0 and OpenID Connect device authorization flows, effectively rendering encryption-based protections useless for applications relying on this specific library configuration.
This vulnerability aligns with CWE-319, which classifies cleartext transmission of sensitive information as a weakness in application design. It also maps to the MITRE ATT&CK technique T1557, specifically Adversary-in-the-Middle, where attackers intercept communications between two parties who believe they are directly communicating. Furthermore, it relates to CWE-326 regarding insufficient encryption strength and CWE-924 concerning improper enforcement of secure communication channels. The failure to enforce HTTPS violates fundamental security principles outlined in industry standards such as RFC 8628 for OAuth Device Flow, which mandates that device authorization requests be sent over TLS unless specific local-only conditions are met.
To mitigate this vulnerability, developers must upgrade the mcp-remote library to a version greater than 0.14.3 where these security controls have been corrected. If upgrading is not immediately feasible, applications should implement strict endpoint validation logic that rejects any non-loopback URLs that do not use HTTPS. Additionally, enabling Certificate Pinning can provide an additional layer of defense by ensuring the client only trusts specific server certificates, thereby preventing man-in-the-middle attacks even if other network controls fail. Organizations should also audit their authentication configurations to ensure that all token endpoints and authorization servers are configured with valid TLS certificates and enforce HSTS headers where applicable. Regular security assessments and static code analysis tools can help identify similar patterns of insecure transport usage across the application ecosystem before they are exploited in production environments.