After #538 every remote HTTP server starts an unpinned `npx -y mcp-remote`. Since 14 October that is 0.15.1, which still follows the server-selected OAuth metadata request paths of CVE-2026-51994 and CVE-2026-51995 (five CVE records on the package)

Aperta
  • Qualcosa non va?
#541 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 5 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
15/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
docker, nodejs, python
Ambito
authentication, devops, security

Direzione di ricerca

Start in remote_server_launch_config in src/ultrarag/client.py (around lines 975-979), where npx -y mcp-remote is built without a version, and check its two call sites near lines 1053 and 1284. The Dockerfiles copy Node from the frontend-builder stage, so the bridge now runs wherever an http or https MCP server is named. Done means the launch path is either pinned to a fixed version or removed in favour of fastmcp's Client, with the choice explained in the commit. Settle the approach with maintainers first, since the issue is a security report.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Hi @xhd0728, thanks for the fast fix in #538 and for the credit. One more thing on the same path. It is the reason I was looking at that launch in the first place.

remote_server_launch_config in src/ultrarag/client.py (lines 975 to 979 on main at 185e2032) builds npx -y mcp-remote <url> with no version. Both call sites use it, lines 1053 and 1284. Before #538 that launch never ran, because the images had no Node. Now all three images carry Node 22 with npx: the frontend-builder stage, copied in at lines 12 and 13 of each Dockerfile. So every pipeline that names an http:// or https:// MCP server starts the bridge. The version is whatever npm serves that day. Today that is 0.14.3, published 21 September.

I'm the researcher behind the five CVE records on that package (MITRE, 24 September; CISA-ADP 9.1 and 9.8 Critical, 8.8, 7.5, 7.5).

The bridge itself. mcp-remote does OAuth discovery for the stdio client, and it goes wherever the remote server points it. Two records cover exactly that. CVE-2026-51994 (9.1): the client fetches the resource_metadata URL from the server's WWW-Authenticate header. CVE-2026-51995 (7.5): it then asks for authorization-server metadata at whatever origin that metadata names. The records say "through 0.1.38". On 9 October I ran the published 0.14.3 CLI in full against loopback canaries. It followed the server-selected destination, through a controlled HTTP 302, and made the next request too. The same discovery chain is present in all 58 stable releases from 0.1.32 to 0.14.3; the per-release helpers were exercised on each, the full CLI on 0.14.3 only. Dossier, with procedures and checksums: https://github.com/playb0t/mcp-remote-oauth-security/blob/87480d3/docs/research-2026-10-09/RESEARCH_DOSSIER.md

Where upstream is. No fixed release. No comment. The repository has not moved since 21 September. The private report went in on 17 February; that is 238 days. In that time npm served 19,430,043 downloads of the package. The official MCP SDKs fixed this class in September. TypeScript: client 2.2.0 / sdk 1.31.0, GHSA-6qxp-vccf-f47h. Python: mcp 1.30.0, or 2.2.0 on the 2.x line, GHSA-qx49-fqc8-xw99. mcp-remote 0.14.3 still bundles @modelcontextprotocol/client 2.0.0, inside the affected range. The three other records (CVE-2026-51996, 9.8 Critical; CVE-2026-51997, 8.8; CVE-2026-52001, 7.5) stop at 0.1.38 in their text. I did not re-test them on 0.14.3. The bridge also keeps tokens, client secrets and PKCE material under ~/.mcp-auth/ in cleartext. CISA's SSVC on all five reads "exploitation: none" as of today (latest ADP update 6 October); I have seen none.

What I'd do this week. Pin an exact version in remote_server_launch_config today, so you at least know what your users run. Every published version has records against it, so a pin is a tourniquet, not a cure. Then drop the bridge. You already connect through fastmcp's Client, and it takes an http:// or https:// URL directly. The HTTP path can stay in Python and never spawn Node at all. That is a deletion, not a rewrite.

What happens next. I'm publishing a follow-up on the ecosystem around this package in the next day or two. It will say who runs the bridge and how. Your fix in #538 is going in with the credit. If you answer here before then, your answer goes in as written. If you pin or drop the bridge, a line in the commit pointing at the records, or at this issue, helps the next person who reads your Dockerfiles.

Records: https://www.cve.org/CVERecord?id=CVE-2026-51994 · https://www.cve.org/CVERecord?id=CVE-2026-51995 · https://www.cve.org/CVERecord?id=CVE-2026-51996 · https://www.cve.org/CVERecord?id=CVE-2026-51997 · https://www.cve.org/CVERecord?id=CVE-2026-52001 · advisories and timeline: https://github.com/playb0t/mcp-remote-oauth-security

Alex Gercog (playb0t)

Update, 15 October. Upstream published 0.14.4, 0.14.5, 0.15.0 and 0.15.1 on 14 October; npx -y mcp-remote now resolves to 0.15.1. I repeated the 9 October procedure on 0.15.1: the CLI still fetched the resource_metadata URL named in WWW-Authenticate, followed a controlled 302 and requested authorization-server metadata at the address the resource metadata named; the ten helper functions behind the records are byte-identical to 0.14.3 and the bundled SDK is still @modelcontextprotocol/client 2.0.0. None of the four releases names the records. Data and checksums: https://github.com/playb0t/mcp-remote-oauth-security/blob/main/docs/research-2026-10-15/README.md. The sentences above about 0.14.3 and «the repository has not moved since 21 September» are the state of 13 October and stay as written.

Lingua principale
Python
Stelle
5.7k
Fork
456
Merge medio
5g 6h
PR unite (30g)
8

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OpenBMB/UltraRAG

Tutte le issue di OpenBMB/UltraRAG

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.