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)

オープン
  • 何か問題がありますか？
#541 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 5 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
15/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
docker, nodejs, python
領域
authentication, devops, security

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Python
スター
5.7k
フォーク
456
平均マージ
5日 6時間
マージ済み PR（30日）
8

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

OpenBMB/UltraRAG のほかの issue

OpenBMB/UltraRAG の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。