Filesystem MCPのsymlink境界: 許可パスと実体パスの照合
許可ディレクトリ内に見えるsymlinkが、実体としては外部ファイルを指す場合があります。公式advisoryと修正パッチに基づく、実体パスの照合、配布版確認、OS側の制限という導入条件です。
Read in EnglishModel Context Protocolの公式serversプロジェクトは、Filesystem MCPサーバーについて、許可ディレクトリ内のsymlink（シンボリックリンク）を通じて意図しないファイルへ到達できる脆弱性を公表しました。破られたのは「入力されたパス文字列が許可ディレクトリから始まる」という見かけと、「OSが最終的に開く実体が許可範囲内にある」という境界の一致です。ファイルアクセス自体はFilesystem MCPの本来機能ですが、設定した範囲を越える到達は別の問題です。
文字列上の場所と実体の場所
たとえば許可範囲が /work/approved でも、その中の latest が /private/archive を指すsymlinkなら、/work/approved/latest/report.pdf という文字列だけでは許可範囲内と判断できません。OSがsymlinkを解決した後の実体パスも、許可ディレクトリそのものか、その配下である必要があります。
| 確認対象 | 不十分な確認 | 受入れに必要な確認 |
|---|---|---|
| 許可ディレクトリ | 設定文字列の保存だけ | 起動時に解決された実体パスと意図したディレクトリの一致 |
| 既存ファイル | 要求パスの先頭一致だけ | symlink解決後の実体パスが許可範囲内 |
| 新規ファイル | まだ存在しないため無条件に許可 | 既存の親ディレクトリを実体パスへ解決し、その配下として作成 |
| 実行環境 | サーバー内の判定だけ | コンテナのmountやOS権限でも不要な領域を不可視化 |
公式修正パッチは、許可ディレクトリを起動時に実体パスへ解決し、要求対象が存在するときはその実体パスを再確認する実装とテストを追加しました。存在しない対象では親ディレクトリの実体を確認する設計です。これは「見えるパス」ではなく「到達する場所」を境界にするための重要な変更です。
導入前の確認記録
まず、依存関係の宣言ではなく実際に配布・展開された @modelcontextprotocol/server-filesystem の版と出所を記録します。公式advisoryには、0.x系についてpatched versions表の0.6.3と、本文の更新推奨0.6.4が一致しない箇所があります。低い方を推測で採用せず、配布元が現在推奨するリリース、利用中の配布物、修正パッチ相当の変更が含まれることを一組で確認します。
次に、業務用の無害なテスト領域で、許可範囲内を指すsymlinkは必要な操作が成立し、範囲外を指すsymlinkは読取・書込の双方で拒否されることを確認します。新規作成を許す場合は、symlink化された親ディレクトリを経由して外へ出ないことも対象です。最後に、サーバープロセスへホームディレクトリ全体を見せず、必要な作業領域だけをmountまたはOS権限で渡します。アプリケーション内の検証に不備が再発しても、プロセスから見えないファイルには到達できません。
確認範囲と限界
2026年9月22日に、公式advisory、公式修正commit、MCP公式セキュリティ方針を確認した解説です。MCP Guardがこの脆弱性を発見したという主張ではなく、個別環境の再検査結果や脆弱性の普及率も示しません。公開パッチの確認だけでは、利用中のlockfile、コンテナimage、キャッシュ済みpackageが更新済みとは証明できません。また、realpath確認は重要ですが、検証後にファイルが差し替わる競合やOS固有の挙動まで、この確認だけで安全を保証するものではありません。