Git MCPのrepository境界: --repositoryとtool callの一致

Model Context Protocol公式のserversプロジェクトは2025年12月17日、pipパッケージ mcp-server-gitのrepository制限に関する脆弱性を公表しました。2025.12.18より前の版では、serverを--repository付きで起動して特定repositoryへ限定しても、その後のtool callが渡すrepo_pathを設定範囲と照合していませんでした。そのprocessから到達できる別repositoryで操作が成立し得る状態でした。

破られたのは、起動時の管理者設定と、呼出しごとの対象指定の間にある境界です。--repository /work/approvedという設定は、各tool callのrepo_pathが常に同じ値になることを保証しません。serverが両者を比較しなければ、設定は意図の表明に留まり、技術的な制限にはなりません。

修正版のrepository包含確認

公式patchは、設定されたrepositoryと要求されたrepo_pathをともに実体パスへ解決します。その上で、要求先が設定先と同じか、その配下にあることをpath component単位で確認し、Git repositoryを開く前に範囲外を拒否します。symlinkを経由して見かけ上だけ範囲内にするケースも、解決後の場所で判定されます。

このadvisoryで重要な条件は、--repositoryを使用した構成が対象であることです。公式patchも、flagが指定された場合の包含確認を追加し、flag未指定時の従来動作は維持しています。したがって、package更新だけで許可repositoryが自動設定されるわけではありません。範囲限定が必要な利用環境では、起動commandに明示的なrepositoryを渡し、その設定が実processへ届いていることまで確認します。

導入時の境界テスト

無害な二つのtest repositoryを用意し、許可したrepositoryでは必要なstatus、diff、logなどが動作し、隣のrepositoryを指定したtool callはGit操作の前に拒否されることを確認します。許可repository内から外部repositoryへ向くsymlinkも拒否対象です。複数repositoryが必要なら、一つの広い親directoryを渡す前に、processを分けられるか、用途別mountで権限を狭められるかを検討します。

実行権限も同時に狭めます。reviewだけの用途ならread-only mountが適合する場合があります。commitやcheckoutなど変更操作が必要なら、書込可能範囲を対象repositoryだけにし、同じuserから秘密情報や別projectへ到達できない構成にします。server内のpath検証とOS側の権限は、どちらか一方の代替ではありません。

確認範囲と限界

2026年9月22日に、公式advisory、公式patch、公式READMEを確認した解説です。MCP Guard独自の発見や、特定の現在環境への影響判定ではありません。影響判断には、実際のpip package version、起動時の--repository、toolを呼べる主体、processから見えるfilesystemが必要です。この修正はrepository選択の境界を扱うもので、Git引数のoption解釈、repository内の機密情報、正当な変更toolの副作用まで単独で解決するものではありません。

• 公式advisory: --repository使用時のpath validation不足
• 公式patch: repository実体パスの包含確認
• 公式mcp-server-git README: --repository設定例とtool入力