The computer is off.

Impact record mcp-remote From the author

your clock

Downloads of the versions the records list

How these are counted

    The five records, read now — state and CISA score

    Read from the CVE Services API when the page loads. If it does not answer, the ledger’s values are shown with its date.

      The ledger, at a glance

      From the author · not part of the ledger

      The problem, the five records, and what I am building against it

      I found the five flaws on this page, and I build software in the same field, offered under a commercial licence. This section says what that software does about this class of flaw today, what is commissioned and not built yet, and what it does not do. Nothing in the ledger above depends on it.

      The author

      Alex Gercog

      published as playb0t

      AI systems engineer and security researcher.

      The record

      • Found and reported the flaws behind the five CVE records on this page. Each record cites the research package as a reference.cve.org/CVERecord?id=CVE-2026-51994 (and -51995, -51996, -51997, -52001)
      • CISA scored four of the five: 9.8 and 9.1 Critical, 8.8 and 7.5 High.the records' CISA-ADP entries
      • The initial private report was submitted on 17 February 2026; F-08 through F-11 were added on 3 May. The public research package was released on 31 July, after the original 90-day window.github.com/playb0t/mcp-remote-oauth-security (TIMELINE.md)
      • The research package, now at v1.0.2, keeps a public corrections file: two findings were reclassified and every proposed severity number was withdrawn in favour of the official assessment.the same repository (CORRECTIONS.md)
      • Earlier work: a SHA-256 integrity check for coding-agent hooks, merged into RTK on 3 March 2026.github.com/rtk-ai/rtk/pull/119
      • Builds coord-hub, described below.

      Contact Email w0rldlogic.0point@proton.me · GitHub github.com/playb0t · X @playb_0t · LinkedIn linkedin.com/in/alex-gercog

      The problem

      mcp-remote performs OAuth discovery on behalf of an MCP client. The research examines several trust boundaries: where discovery can send a request from the user's machine, how local authentication state is separated, and which origin may receive a credential. These are distinct mechanisms. F-01 and F-02 were demonstrated with localhost canaries; F-08 rests on source review; F-04 and F-11 are hardening findings with corrected claims. The official CVE descriptions and CISA scores above are reported as published.

      coord-hub

      What I am building

      I build coord-hub, a coordination layer for AI agents that belong to different owners. Agents join a shared room only after a person vouches for them, and they hand each other tasks, messages and files. An outward call is carried by a gateway, a separate process that forwards only what a one-time grant names. It is at version 0.1.0, its repository is private, and it is in active development.

      Today an agent's own connection to a remote MCP server does not pass that gateway. So the hub as it stands would not have stopped the five flaws on this page. The gateway already applies the outbound policy this research asks for to every call that goes through it, and the connector that brings remote MCP connections under it is commissioned and not built yet.

      Works today · in the build's tree, under test

      • For a granted DNS name other than localhost, the gateway resolves once and checks every returned address before fetching a credential. It accepts public addresses by default; the operator can additionally allow private ranges. Other names resolving to loopback, link-local, known cloud-metadata or special-use ranges, or this machine's own interfaces are refused as a whole. Connections to DNS names are pinned to checked addresses. The localhost and explicitly granted IP-literal exceptions are listed under Limits today.

        basis: tests gateway-address DA1–DA12; source read: src/gateway/core.mjs

      • The hub's own outbound calls follow no redirect: a 3xx is recorded as the destination's answer, and nothing is sent where it points. On a call it forwards for an agent, the gateway carries one request for one grant and hands a 3xx back as the answer.

        basis: tests egress-redirect ER1–ER5, gateway GW3; source read: src/gateway/gateway.mjs

      • Where the operator has bound a credential to a destination, the agent needs none of its own on a call the gateway forwards. The gateway retrieves the value by reference from the configured provider and writes it into the configured request header. The egress event records the reference, status, byte count and response digest, without the credential value, request headers or response body. A destination can still echo a credential back to the agent, as noted under Limits today.

        basis: tests secretless-credentials SC1–SC9; source read: src/gateway/gateway.mjs, src/egress-witness.mjs

      • A grant is single-use and bound to one request and its destination, and the destination must be on a list of hosts the operator set. A person approves the request, except where it acts on material that traces wholly to a directive from the operator or from a person holding the member role, or on a build a person named for release.

        basis: tests policy, effect-acceptance, gateway GW3, GW5; source read: src/policy.mjs, src/router.mjs

      In build · commissioned 4 October 2026, not in the tree yet

      • A connector for remote MCP servers inside the gateway: the gateway performs the OAuth discovery itself, every address it is handed passes the same rule, and the tokens stay at the secret provider. An agent that reaches a remote MCP server through the hub will then need no client-side OAuth helper.

      • A check at the door: when an agent asks to join, the hub will show the person who vouches whether the agent's declared build lists mcp-remote in a version the five records name, or a copy of it published under another name.

      • The shipped MCP bridge and the reference agents will refuse a redirect on their own calls to the hub. Today they do not.

      Limits today

      • Confining an agent to the gateway's network exists only as a reference scheme for Linux run as root. Nothing confines an agent on Windows, on macOS or without root, and the Linux scheme's first live run is not yet on record. Where an agent is not confined, it can act around the hub, and the hub does not see it.

      • A destination granted as a literal address is dialled as granted, and the name localhost is dialled to loopback. Private network ranges are allowed when the operator sets a switch. The hub's own outbound calls are checked by host name only, not by resolved address.

      • Where no credential is bound, the gateway carries the agent's own headers as sent, a credential of the agent's own included. A destination that echoes request headers hands a written value back to the agent that asked.

      • The file secret provider is a file on the gateway's machine, and a stolen gateway disk is the credentials. With the HTTP provider, a stolen gateway environment is still the credentials. The shipped MCP bridge keeps each participant's signing key unencrypted in a file on the participant's machine. Both files are owner-only on Linux and macOS; Windows does not apply that mode.

      • The hub's own log, tokens and private key are encrypted at rest only when the operator turns that on. Whoever runs the hub's machine holds the door, the log and the disk.

      • The hub verifies nothing about who owns a resource at a destination, and it checks a person's release word only for its form and its author.

      • No live identity provider, directory engine, event collector, timestamp authority, transparency log, metrics scraper, browser authenticator or destination reporter has been reached; each was exercised against a fixture that speaks its specification. The hub is one process on one machine.

      • Two admitted agents can coordinate through messages the hub does not read. A harmful result assembled from steps that each gate nothing is not seen.

      Read from the build's tree on 4 October 2026, commit 76c1fba. The six test files named above were run that day on Windows under Node.js 24, together with two more on the same subject: 72 tests, all passed. "Source read" means the statement rests on reading the code and none of those test files names it. The repository is private, so the basis lines name where each statement rests, not a link a reader can open.

      The product's limits file, where every limit is listed in full, and its white paper are available on request through any of the contacts above.