mcp-remote 0.14.3 Is Still Latest. Device-Code Tokens Ride HTTP.

npm's latest tag for mcp-remote is 0.14.3, published 21 September 2026 at 00:28 UTC. 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. 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 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.

What the CVE actually says.#

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.

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.

1. 2026-08-27
   Device grant commit 0496a12 at 14:47 UTC. npm 0.8.0 at 14:49 UTC. The CVE later marks this as the floor. The device file has no https string.
2. 2026-09-11
   v0.11.0 at 03:03 UTC, npm at 03:06 UTC. client_credentials refuses non-HTTPS except localhost and 127.0.0.1. The device grant does not.
3. 2026-09-21
   v0.14.3 at 00:25 UTC, npm 0.14.3 at 00:28 UTC. Release notes are a token-save fix. No commit has landed since.
4. 2026-10-11
   CVE-2026-108716 at 12:19 UTC. No patched version. The note still says no public advisory for the device-grant issue.

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.