mcp-server-gitの境界回避を修正｜2026.10.28更新と複数ツールの点検

Model Context Protocol（MCP）の公式リファレンスサーバー「mcp-server-git」で、`--repository`により指定したGitリポジトリの境界を回避できる問題が公表されました。影響を受けるのは2026.10.28未満で、修正版は2026.10.28です。AIエージェントやコーディング支援へGit操作を許可している運用者は、実行中のパッケージ版を確認して更新し、同じ作業領域へ書き込める別のMCPツールがないかも点検してください。

本稿は2026年10月29日に、modelcontextprotocol/serversの公式セキュリティアドバイザリ、PyPIのmcp-server-git 2026.10.28配布ページ、公式READMEを確認した脆弱性ニュースです。公開日は10月28日、報告日は10月27日です。CVEは割り当てられていないため、存在しない番号を補いません。

対象は2026.10.28未満、修正版は2026.10.28

公式アドバイザリは影響版を2026.10.28未満、修正版を2026.10.28としています。確認された影響版は2026.10.19です。PyPIでは2026.10.28のソース配布物とwheelが10月28日に公開され、GitHub Actionsからの来歴も表示されています。Gitリポジトリにあるコードだけでなく、実際にクライアント設定から起動されるパッケージの版を確認する必要があります。

`uvx`を使う設定では、ローカルへ通常の形でインストールしていなくても、起動時に取得した版が動きます。`pip`や仮想環境、コンテナイメージから起動する構成もあります。設定ファイルのコマンド名だけで更新済みと判断せず、起動ログ、ロックファイル、コンテナのビルド記録、実行環境でのパッケージ情報のいずれかから2026.10.28以上であることを確かめます。

python -m pip show mcp-server-git
python -m pip install --upgrade "mcp-server-git>=2026.10.28"

上記はpip環境の確認例です。`uvx`、`pipx`、コンテナ、デスクトップ製品の組み込み設定では、その配布・固定方法に合わせて更新します。更新後はMCPクライアントを再起動し、古いプロセスが残っていないか確認してください。パッケージをダウンロードしただけでは、実行中のサーバーは置き換わりません。

文字列上は内側でもGitが外側を選ぶ

`--repository `は、mcp-server-gitの操作対象を指定したリポジトリへ制限する設定です。問題の根は、サーバーが利用者から渡されたパスを正規化し、そのパスが許可リポジトリの内側にあることを確認した後で、GitPythonが別の情報を解釈する点にあります。検査した対象と、実際に開いたGitリポジトリの実体が一致しない場合がありました。

Gitでは、作業ツリーの`.git`がディレクトリとは限りません。リンクされたワークツリーや分離したGitディレクトリでは、`.git`ファイルに`gitdir:`として実際のGitディレクトリへの参照を記録できます。今回の問題では、許可リポジトリ内の入れ子ディレクトリ自体は境界検査を通りますが、その中の`.git`ファイルをGitPythonが後からたどり、許可範囲外のリポジトリを開けました。ファイルシステムのシンボリックリンクだけを解決する検査では、このGit固有の参照を捉えられませんでした。

公式の確認では、範囲外のパスを直接`git_show`へ渡した場合は拒否された一方、入れ子の`.git`参照を経由すると、外部リポジトリのコミット済みファイルを読めました。また`git_create_branch`で外部リポジトリにブランチを作成できました。確認された影響は、コミット済み情報の開示と参照の変更です。アドバイザリは任意のホストファイル書き込みやコード実行を主張していません。

単独の認証不要リモート攻撃ではない

CVSS 3.1は5.3で、ベクトルはAV:L/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:Nです。この数値だけを見て、ネットワークから誰でも直ちに侵入できる問題と説明するのは不正確です。攻撃には、制限付きmcp-server-gitのツールを呼べること、許可リポジトリ内へ入れ子のディレクトリと`.git`ファイルを置けること、サーバープロセスが読める外部リポジトリのパスを特定または推測できることが必要です。

現実的な条件として公式資料が挙げるのは、同じ許可ディレクトリへ書き込めるファイルシステムMCPサーバーも利用できる構成です。Gitツール単体に`.git`ファイルを作る機能がなくても、別ツールが配置し、Gitツールが参照をたどれば、二つの権限が連鎖します。プロンプトインジェクションによる悪用が確認されたという発表ではありませんが、信頼できないリポジトリ内容や外部文書がエージェントのツール選択へ影響する構成では、複数ツールの合成を脅威モデルへ含める必要があります。

更新だけでなくマウントとOS権限を確認する

更新を最優先としたうえで、mcp-server-gitのプロセスから見えるファイルシステムを確認します。`--repository`はアプリケーション上の境界ですが、プロセスのOS権限やコンテナのマウント範囲まで自動的に縮めるものではありません。プロセスが他の機密リポジトリを読めなければ、境界回避後に到達できる対象も減ります。

• Gitサーバーへ対象リポジトリだけを読み書き可能な形で公開し、ホームディレクトリや他案件の親ディレクトリを丸ごとマウントしない。
• SSH鍵、クラウド資格情報、パッケージ公開用トークンを、Git操作だけを行うプロセスへ不要に渡さない。
• ファイルシステムMCPの許可ディレクトリとGit MCPの作業領域が重なる場合、`.git`ファイルを新規作成できる主体と必要性を確認する。
• 複数の顧客・案件を同じOSユーザーと同じ長寿命プロセスで扱わず、作業単位で資格情報とマウントを分ける。

正規のGitワークツリーやサブモジュールでも`.git`ファイルを使うため、すべてを一律削除する対策は既存の開発構成を壊す可能性があります。公式アドバイザリも、単純にGitディレクトリの物理パスが許可ツリー内かを見るだけでは、正当なlinked worktreeを壊し得ると説明しています。運用側は修正版を利用し、その上で自組織が許可するワークツリー関係を明示します。

更新後は拒否と正規操作を両方試す

検証環境では、第三者のリポジトリを対象にせず、すべて自組織が管理するダミーリポジトリを使います。許可用と範囲外用の二つを用意し、通常の許可リポジトリで`git_status`や読み取り操作が成功すること、範囲外のパスが拒否されることを確認します。さらに、許可領域内へ作った入れ子の`.git`参照から範囲外へ到達できないことを確認します。

拒否試験だけでは不十分です。正規のlinked worktreeや、組織が利用を認めるサブモジュール構成がある場合は、それらが更新後も期待どおり動くかを別に試します。境界を強くした結果、必要なビルドやレビューが失敗し、利用者が`--repository`を外して復旧する状況を避けるためです。失敗時は境界設定を無効化せず、修正版の仕様と自社のリポジトリ構成を突き合わせます。

既存環境の調査ではGit参照と操作履歴を分けて見る

影響版を、信頼度の低いクライアントや複数ツールから到達できる状態で運用していた場合は、更新とは別に利用済み環境を調べます。許可領域内の通常ファイルだけでなく、`.git`という名前の通常ファイル、そこに記載された`gitdir:`の参照先、linked worktreeやサブモジュールとして正規に作られたものかを確認します。見つけたことだけで侵害と断定せず、作成時刻、作成主体、タスク記録と対応付けます。

外部リポジトリ側では、見覚えのないブランチ・タグ・参照、コミットやインデックスの変更、MCPプロセスの実行時間帯に行われた読み取りやコマンドを確認します。Git自体の履歴にすべての読み取りが残るとは限らないため、MCPクライアントのツール呼び出し記録、プロセス監査、ファイルアクセス監視があれば併用します。ログがない期間を「操作なし」とは断定しません。

秘密情報がコミット履歴に含まれ、影響版のプロセスから到達可能だった場合は、実際の取得が確認できなくても、露出可能性と業務影響に応じて失効・差し替えを判断します。リポジトリから削除するだけでは、取得済みの資格情報を無効化できません。範囲外への書き込みが見つかった場合は、変更内容を保全してから、信頼できる基準点と照合します。

設定説明と実際の実行境界を一致させる

今回の問題は、`--repository`という設定名が示す境界と、Gitが最終的に開いた実体を同一視できないことを示しました。MCPツールの説明文・スキーマ・権限差分を継続的に確認する方法は、MCPツール更新後の差分レビュー記事で整理しています。今回追加すべき確認は、入力文字列だけでなく、ライブラリが解決した後の対象を認可することです。

運用では、モデルが選んだ`repo_path`をそのまま信頼せず、実行サーバーが許可済みリポジトリIDへ変換し、OS権限とマウントでも対象を絞ります。ファイル書き込み、Git操作、シェル実行を同時に許可する場合は、各ツールを単独で評価するだけでなく、前のツールが作った状態を次のツールがどう解釈するかを検証します。更新、境界の縮小、拒否試験、利用済み環境の調査を分けて完了させることが、今回の対応です。