# mcp-remote 0.14.3 Is Still Latest. Device-Code Tokens Ride HTTP. > CVE-2026-108716, published 11 October 2026, says mcp-remote 0.8.0 through 0.14.3 sends a client secret and receives access and refresh tokens in cleartext when the device-code grant uses a non-loopback HTTP endpoint from metadata. npm latest is 0.14.3, published 21 September. No patched version is listed. HaiND's check was a static comparison. No traffic was captured. Source: https://hackerlogs.com/blog/mcp-remote-device-code-http Published: 2026-10-11 ## Key takeaways - HaiND is the finder. VulnCheck published CVE-2026-108716 at 12:19 UTC on 11 October. CVSS is 6.0 on v4 and 5.3 on v3.1, both medium. - npm latest is 0.14.3, published 21 September 2026 at 00:28 UTC. The tarball version is 0.14.3. The git tag's package.json still reads 0.1.38. - The device grant arrived in 0.8.0 on 27 August. The sibling client_credentials grant learned an HTTPS refusal in 0.11.0 on 11 September. The device file did not. - HaiND's check was static. No authorization server was contacted and no traffic was captured. HTTPS metadata and loopback HTTP are outside the finding. - The security-advisory list was empty, and no commit has landed since v0.14.3. The next dist-tag is 0.1.0 from 30 April 2025. npm's `latest` tag for `mcp-remote` is `0.14.3`, published 21 September 2026 at 00:28 UTC. [CVE-2026-108716](https://www.cve.org/CVERecord?id=CVE-2026-108716) was published today at 12:19 UTC, and the affected range runs through that same version. The record lists no patched release. HaiND, of the Post and Telecommunication Institute of Technology, is the finder named on the CVE. The technical note is [the writeup the CVE cites](https://hackmd.io/@haind03/punkpeye-mcp-remote-device-code-cleartext-oauth-transport). VulnCheck is the CNA. US X trends at 22:32 UTC were NFL names, from the Giants through the Seahawks. Hacker News front page was a game port, Terence Tao, and IRCv3. The operator fact is the dist-tag. Medium on the CVE's own scores: CVSS v4 base 6.0, CVSS v3.1 base 5.3. High confidentiality on the vulnerable system, nothing else. Attack requirements are present. The v3.1 vector marks user interaction required. The control that failed is the transport check on the device grant. Three panels for the mcp-remote device-code cleartext grant: tokens sent when metadata names plain HTTP, npm latest 0.14.3 with no patched version, and the operator step to drop that grant until a release names the CVE. ## What the CVE actually says. [CVE-2026-108716](https://www.cve.org/CVERecord?id=CVE-2026-108716) is CWE-319, cleartext transmission of sensitive information, in `mcp-remote` from 0.8.0 through 0.14.3. The package URL is `pkg:npm/mcp-remote`. `authorizeWithDeviceCode` sends client secrets and receives tokens without enforcing HTTPS endpoints. When the device-authorization endpoint and the token endpoint discovered from metadata are non-loopback `http` URLs, an on-path attacker can read the client secret plus the access token and the refresh token. Versions outside that range are unaffected by default. No fixed version is listed. `mcp-remote` is a stdio proxy that signs an MCP client in to a remote server. The device grant is an opt-in flag for a machine with no browser. The scheme check on the MCP server argument does not apply to the OAuth endpoints. Those strings come from authorization-server metadata, and the device module checks that they exist. It does not compare the scheme. Both the device-authorization request and the token poll then call fetch on the raw string. A confidential client places its secret on those requests. A successful poll parses the access token and any refresh token from the response body. The sibling grant shows the check that is missing. `client_credentials`, commit `2acd281`, refuses to send the client secret when the endpoint is not HTTPS and the host is not localhost or `127.0.0.1`. That commit is tag `v0.11.0`, 11 September 2026 at 03:03 UTC, npm `0.11.0` at 03:06 UTC. The device grant predates it. Commit `0496a12` at 14:47 UTC on 27 August is tag `v0.8.0`, and npm `0.8.0` followed at 14:49 UTC. The device file at that tag contains no `https` string. The device file at `v0.14.3`, commit `6a06aca`, still has no scheme comparison. The sibling file at the same tag still has the refusal. HaiND's confirmation is static. A mirror of the two scheme decisions, run offline with no dependency install and no network, reports that the device grant transmits to a non-loopback HTTP endpoint where `client_credentials` refuses. The negative cases match the sibling: HTTPS transmits on both grants, and loopback HTTP transmits on both. No authorization server was contacted. No packet was captured. The on-the-wire claim is the cleartext property of `http`, reasoned from the source, not observed. > `0.14.3` shipped ten days after `0.11.0`. The refusal that landed in September sits on `client_credentials`. The device-code path never received it. npm latest is the top of the range this CVE marks affected. ## The package clock and the disclosure clock. The package clock is the registry, read tonight. `0.8.0` is the floor. The device-grant commit and the npm publish are two minutes apart on 27 August. `0.11.0` is the day the other grant learned to refuse cleartext. `0.14.3` is the current top: GitHub release at 00:25 UTC on 21 September, npm at 00:28:03 UTC, registry modified the same second. The release notes keep a stored token's expiry and issuer across re-saves. They do not mention transport. Nothing newer is on npm. `0.14.4` is absent. The published tarball for `0.14.3` says version `0.14.3`, and its `gitHead` is `6a06aca`. The `package.json` committed on tag `v0.14.3` still reads `0.1.38`. The same string is committed on `v0.8.0` and `v0.11.0`. Read npm. The git manifest is not the dist-tag. The `next` dist-tag is `0.1.0`, published 30 April 2025, which is older than the affected floor, not a release candidate past it. No commit has landed after `6a06aca` at 00:24 UTC on 21 September. That commit is the release. The public security-advisories list was empty tonight. A search for CVE-2026-108716 on the repo's issues returned nothing. The disclosure clock is today. The CVE record's `datePublished` is 12:19:28 UTC on 11 October. `dateReserved` is 01:51 UTC the same morning. `datePublic` is 10 October, a date with no minute. The note's references section says no public advisory for this device-grant issue had been published at the time of writing. The CVE record cites that note. The note's title line also names CVE-2026-51994. That is a different record, published 24 September, for a resource-metadata SSRF in `0.1.32` through `0.1.38`. It is not this transport check. Do not collapse the two clocks because the title used a slash. > An empty advisory list is not a fix. The release a defender would install tonight is `0.14.3`, and its notes do not name this CVE. The `next` tag will not move you forward. It points at `0.1.0`. ## What still holds. The precondition is the flag plus the metadata. The device grant has to be the one you started, and the discovered device-authorization endpoint or token endpoint has to be a non-loopback HTTP URL. HTTPS metadata, which is the common case, does not take this path. Loopback HTTP does not take it either. The browser redirect flow is a different function. A confidential client is what puts the long-lived secret on the request. The poll response is a separate exposure: when it succeeds over that HTTP token endpoint, the access token and any refresh token come back in the body for any device-grant client, confidential or not. HaiND did not capture either one. There is no remote code execution in the record, and no authentication bypass of the MCP server. There is no named organization and no observed packet. Brief the missing refusal. Do not brief an interception count. The v4 score and the v3.1 score are both medium, with high confidentiality and attack requirements present. They describe an on-path reader of a cleartext grant the metadata itself named. They do not describe every install of the proxy. ## What to change before the next sign-in. Inventory `mcp-remote` before the next device-code login. npm `latest` is `0.14.3`. The git tag of the same name is the same commit the tarball records as `gitHead`. Both are the top of the range the CVE marks affected. The committed `package.json` version `0.1.38` is a stale string. It is not evidence you are outside `0.8.0` through `0.14.3`, and it is not evidence you are inside the September SSRF range. Do not use `--device-code` against an authorization server whose metadata names a non-loopback HTTP endpoint. Prefer a client that signs in through the browser flow, or a device grant that refuses the scheme the way `client_credentials` already does. If a device-code run already completed against that kind of endpoint, rotate the client secret and revoke the refresh token the poll returned. Rotating them on a server that still advertises HTTP leaves the next login on the same path. Wait for a release note or a GitHub security advisory that names CVE-2026-108716. A version number merely newer than `0.14.3` would be evidence only after that note exists. Tonight the registry has no such version, `main` has not moved since the tag, and the advisory list is empty. ## Sources - [mcp-remote device-code grant transmits credentials in cleartext](https://hackmd.io/@haind03/punkpeye-mcp-remote-device-code-cleartext-oauth-transport) - [CVE-2026-108716](https://www.cve.org/CVERecord?id=CVE-2026-108716) (2026-10-11) - [mcp-remote 0.8.0 through 0.14.3 Cleartext Credential Transmission via --device-code OAuth Grant](https://www.vulncheck.com/advisories/mcp-remote-0.8.0-through-0.14.3-cleartext-credential-transmission-via-device-code-oauth-grant) (2026-10-11) - [Release v0.14.3](https://github.com/punkpeye/mcp-remote/releases/tag/v0.14.3) (2026-09-21) - [mcp-remote on npm](https://www.npmjs.com/package/mcp-remote) (2026-09-21)