🛡️ 技術調査 - Unsafe by Flow / MCP-BiFlow

論文「Unsafe by Flow: Uncovering Bidirectional Data-Flow Risks in MCP Ecosystem」(Hou / Zhao / Wang. arXiv:2605.07836, 2026-05-08) の提案フレームワーク MCP-BiFlow を、構造とデータの観点から技術調査としてまとめます。

検証日: 2026-05-12
対象: arXiv:2605.07836 v1 / Zenodo アーティファクト DOI 10.5281/zenodo.19335837

概要

背景と問題意識

Model Context Protocol (MCP) は LLM エージェントと外部ツールを繋ぐインタフェース層として急速に普及しました。一方で既存の MCP セキュリティ研究は、ツール名の許可リスト・スキーマ検証・メタデータ審査といった入口側の議論に偏ってきました。

既存の汎用 SAST (静的解析ツール) は MCP の脆弱性を正確に検出できません。理由は 3 つあります。

1. ツール登録/ディスパッチの異種性。FastMCP のデコレータ、低レベル SDK の list_tools/call_tool、fastify-mcp の registry 登録など、エントリポイントの到達方法が多様で汎用 SAST が認識できません
2. MCP 固有の taint semantics の必要性。プロトコルが持つ「引数の受け渡し」「結果の返却」という境界を既存ルールでは表現できません
3. ツールスコープ単位でのみバグが顕在化する性質。全体のコールグラフではなく、個々のツールハンドラを分析単位にしないと見落とします

本論文の貢献

本論文は MCP 固有のデータフロー脆弱性が双方向に発生する ことを初めて体系的に定式化しました。脆弱性は 2 方向で現れます。

• Request-side propagation: requester (LLM / ホスト) が渡した引数が、サーバー側の命令実行・ファイル操作・DB クエリ・ネットワーク要求に到達する経路
• Return-side propagation: 外部から取得したコンテンツやサーバー内部の機微データが、MCP の出力境界を越えてホスト/モデルに戻り、その挙動を歪める経路

この定式化に基づいて構築した静的解析フレームワーク MCP-BiFlow は、32 件の confirmed 脆弱性ベンチで 30/32 (93.8% recall) を達成しました。CodeQL (1/32)、Semgrep (8/32)、Snyk Code (10/32)、MCPScan (11/32) をいずれも大幅に上回ります。実世界スキャンでは 15,452 リポジトリを対象に 549 クラスタを出し、手動レビューで 87 サーバーに 118 の脆弱パスを確認しました。

MCP セキュリティ研究における位置づけ

本論文は、静的解析の俎上で MCP プロトコルの双方向データフローを正面から扱った最初の体系的研究として位置づけられます。ランタイム防御 (MCP-Guard) や仕様強化 (OAuth 2.1 / RFC 8707) と相補的に積み上がる構図にあります。

特徴

他の MCP セキュリティ研究との比較

検出ツールとしての比較

汎用 SAST 3 ツールが低 recall に留まる主因は、MCP の dispatch パターンを理解できず entrypoint を見つけられない点にあります。MCP 専用の MCPScan でも約 1/3 にとどまり、return-side propagation を扱えないことが性能差の主因と推測されます。

MCP-BiFlow の主要な特徴

本フレームワークは 3 コンポーネントで構成されます。

1. MCP Entrypoint Recovery — Registration Resolution (10 variants) + Dispatcher Resolution (16 patterns) + Entrypoint Specialization ⟨t, h, r⟩
2. MCP-Specific Taint Specification — S_req / K_op / S_ext / K_ret の 4 オブジェクト
3. Bidirectional Interprocedural Analysis — 6 つの伝播ルール

LLM の役割

本フレームワークは LLM を「攻撃シミュレーション」ではなく「解析補助」として使用する点が特徴的です。

• M2: LLM-assisted source identification — S_ext の確定を補助 (削除でカバレッジ 23.6% 低下)
• M3: LLM-assisted guard/sanitizer validation — triage 品質を向上 (カバレッジには影響しない)

LLM 補助はあくまで補助的役割であり、コア解析の決定論性を損なわない設計です。

評価の両建て構成

構造

提案フレームワーク MCP-BiFlow の内部アーキテクチャを C4 model の 3 段階で図解します。

システムコンテキスト図

MCP-BiFlow が誰のために何をするかを示す最上位の俯瞰図です。

コンテナ図

MCP-BiFlow を構成する主要コンテナとその相互接続です。

コンポーネント図

3 つの主要コンテナの内部コンポーネントを詳細に示します。

Entrypoint Recovery の内部

Taint Specification の内部

Bidirectional Interprocedural Analysis の内部

データ

概念モデル

エンティティ名と所有・利用関係のみを示します。

情報モデル

属性の型は言語非依存表記 (string, list, map, bool, int) を使用します。論文に ER 図はないため、本文記述から推測した属性には「※論文記述から推測」と注記します。

属性補足

構築方法

本論文は手法論文であり、ツールとして完全に実装・公開されているものではありません。Zenodo アーティファクト (DOI: 10.5281/zenodo.19335837) に評価用スクリプト・データセットが含まれますが、汎用 CLI ツールとしては整備されていません。以下のコード例は「論文の意図を反映した実装案」として示します。

前提条件

MCP-BiFlow を自分の環境で再現・拡張するには以下が必要です。

• Python 3.10 以上 (型注釈と match 文を活用するため)
• 静的解析 IR ライブラリ: libcst (CST ベースの解析) または ast 標準モジュール。call グラフ構築には pycg などが候補
• LLM API キー: M2 / M3 の補助ステップで OpenAI / Anthropic の API を使用
• Zenodo アーティファクト (DOI: 10.5281/zenodo.19335837): 評価スクリプト・ベンチマーク 32 件・taint 仕様 JSON が含まれる想定

アーティファクトの入手とセットアップ

Zenodo からアーティファクトをダウンロードし、展開します。

curl -L "https://zenodo.org/doi/10.5281/zenodo.19335837" -o mcpbiflow_artifact.zip
unzip mcpbiflow_artifact.zip -d mcpbiflow/
cd mcpbiflow/

pip install -r requirements.txt

アーティファクトには以下が含まれると想定されます。

• benchmark/ — 32 件の ground-truth 脆弱性ケース (Python / JS / TS)
• taint_spec/ — S_req / K_op / S_ext / K_ret の仕様定義ファイル
• scripts/ — entrypoint recovery・taint propagation の評価スクリプト
• results/ — 論文中の数値を再現するためのログ

実装案: Registration Resolution

論文は Python MCP サーバーで 10 種類の登録パターンを識別します。FastMCP デコレータ方式と低レベル SDK 方式が代表例です。

# 実装案 / 例 — Registration Resolution
import ast

REGISTRATION_PATTERNS = [
    "mcp.tool",          # FastMCP: @mcp.tool()
    "server.list_tools", # 低レベル SDK
    "server.call_tool",  # 低レベル SDK
    "app.tool",          # 他フレームワーク系
    "add_tool",          # registry.add_tool(name, handler)
]

def find_registrations(source_code: str) -> list[dict]:
    tree = ast.parse(source_code)
    found = []
    for node in ast.walk(tree):
        if isinstance(node, ast.FunctionDef):
            for decorator in node.decorator_list:
                dec_str = ast.unparse(decorator)
                if any(p in dec_str for p in REGISTRATION_PATTERNS):
                    found.append({
                        "handler": node.name,
                        "decorator": dec_str,
                        "lineno": node.lineno,
                    })
    return found

実装案: Taint Sink の検出

K_op (sensitive operation sink) は呼び出しを AST でマッチングして検出します。

# 実装案 / 例 — K_op sink パターンの検出
K_OP_PATTERNS = {
    "command_exec": ["subprocess.run", "subprocess.Popen", "os.system", "eval", "exec"],
    "filesystem":   ["open", "os.remove", "shutil.rmtree", "pathlib.Path.write_text"],
    "database":     ["cursor.execute", "session.execute", "db.query"],
    "network":      ["requests.get", "requests.post", "httpx.get"],
}

def find_sinks(tree: ast.AST) -> list[dict]:
    sinks = []
    for node in ast.walk(tree):
        if isinstance(node, ast.Call):
            call_str = ast.unparse(node)
            for category, patterns in K_OP_PATTERNS.items():
                if any(p in call_str for p in patterns):
                    sinks.append({"category": category, "call": call_str, "lineno": node.lineno})
    return sinks

利用方法

Step 1 — Registration / Dispatcher 解析

対象リポジトリを clone し、ハンドラ登録方法を特定します。

git clone https://github.com/<org>/<mcp-server-repo> target/
cd target/

grep -rn "@mcp.tool\|@server.list_tools\|@server.call_tool\|add_tool" . \
  --include="*.py" | head -40

確認ポイントは以下です。

• デコレータ登録 (@mcp.tool()) か、低レベル SDK 登録か、動的 registry 登録か
• 1 サーバー内で複数の登録方式が混在していないか
• if tool_name == "xxx": のような branch dispatch が call_tool 内にあるか

Step 2 — Taint Spec の適用

論文の 4 オブジェクトを各ハンドラにマッピングします。

# 実装案 / 例 — FastMCP での S_req → K_op フロー
from mcp.server.fastmcp import FastMCP
import subprocess

mcp = FastMCP("example-server")

@mcp.tool()
async def run_command(cmd: str, working_dir: str) -> str:
    # cmd, working_dir が S_req (taint source)
    # subprocess.run が K_op (sensitive sink) → request-side 脆弱性
    result = subprocess.run(cmd, cwd=working_dir, shell=True, capture_output=True)
    # result.stdout が S_ext / return がそのまま K_ret → return-side 漏洩
    return result.stdout.decode()

# 実装案 / 例 — 低レベル SDK での K_ret (return-side taint sink)
from mcp.server import Server
import mcp.types as types
import httpx

server = Server("example-low-level")

@server.call_tool()
async def handle_call_tool(name: str, arguments: dict):
    if name == "fetch_url":
        resp = httpx.get(arguments["url"])              # S_ext
        return [types.TextContent(type="text", text=resp.text)]  # K_ret

Step 3 — Bidirectional Propagation の実行

6 つの伝播ルールに従い、S_req → K_op (request-side) および S_ext → K_ret (return-side) の経路をトレースします。

# 実装案 / 例 — 単純な代入伝播 (Assignment propagation) のトレース
def trace_propagation(handler_source: str, taint_vars: set[str]) -> set[str]:
    tree = ast.parse(handler_source)
    propagated = set(taint_vars)
    for node in ast.walk(tree):
        if isinstance(node, ast.Assign):
            rhs = ast.unparse(node.value)
            if any(v in rhs for v in propagated):
                for target in node.targets:
                    propagated.add(ast.unparse(target))
    return propagated

論文では 6 ルールを interprocedural に適用し、関数呼び出しをまたいだ taint 追跡を実施します。

Step 4 — Candidate Cluster の手動 Triage

解析で得た候補パスを以下の観点で手動レビューします。

• Guard / Sanitizer の有無: shlex.quote / html.escape / パラメータ化クエリ / 型制約チェックが taint フロー上に存在するか
• Exploitability の確認: 静的解析は「到達可能か」しか判断しないため、実際にリクエストから制御できるかを確認
• LLM 補助 (M3): 曖昧な guard は LLM に判定させて FP を削減

自社 MCP サーバーレビューチェックリストとしての転用

MCP-BiFlow のフレームワークは、そのままコードレビューチェックリストとして利用できます。

Request-side チェック (S_req → K_op)

• ハンドラ引数のうち subprocess / os.system / eval / exec に渡る変数はないか
• ファイルパス操作 (open / pathlib) にユーザー引数がそのまま渡っていないか
• SQL / NoSQL クエリ組み立てに文字列連結が使われていないか
• HTTP リクエスト先 URL にユーザー引数が含まれていないか (SSRF リスク)

Return-side チェック (S_ext → K_ret)

• 外部 API レスポンスをサニタイズせずに tool_result に含めていないか
• ファイル読み込み内容・subprocess stdout をそのまま返していないか
• サーバー内部の認証トークン・パス・設定値が戻り値に漏れていないか

登録 / ディスパッチの整合性チェック

• 1 サーバー内で登録方式が混在していないか
• call_tool 内の tool 名マッチングに未定義ツールへの fallthrough がないか
• 動的ディスパッチを使っている場合、入力バリデーションが十分か

運用

CI での差分スキャン (PR 単位)

• スキャン対象の絞り込み。git diff origin/main --name-only で変更ファイルを列挙し、MCP ハンドラを含むモジュールだけを対象に絞る
• ブロック条件の分離。request-side の high-severity パスはマージブロック、return-side は警告扱いで triage
• アーティファクト保存。解析出力を CI アーティファクトに保存し、M3 の結果はモデル名と seed を必ずログ記録

Nightly 全リポジトリスキャン

• 組織内の全 MCP サーバーリポジトリを対象とし、外部依存も含める
• overlap-compressed cluster を活用し、同型バグを cluster 単位で圧縮して出力
• 依存パッケージのアップデートで新たな entrypoint が増えうるため、週次では見逃しが発生する

出力の Triage フロー

MCP-BiFlow 出力 (候補パス JSON)
    │
    ├─ [自動 cluster 分類] request-side / return-side、sink 種別でグループ化
    ├─ [M3 LLM-assisted sanitizer 検証] ガード存在パスは mitigated に移動
    ├─ [manual review キュー] cluster 代表 1 件を人手確認 → exploitability 検証
    └─ [アクション分岐] confirmed → 開示 / パッチ、FP → 除外、要追試 → 動的検証

cluster 代表だけを人手レビューすることで、549 cluster を 87 サーバーまで絞った論文の手順を再現できます。

ベストプラクティス

反証エビデンス R1-R6 を「誤解 → 反証 → 推奨」の構造で統合します。

R1: 静的パスは exploit 可能性を保証しない

• 誤解: candidate vulnerable path が出た = 即座に悪用可能
• 反証: AgentSeal の Runtime Exploitation 報告では、静的候補のうちランタイムで再現できたのは一部のみ
• 推奨: static analysis → ランタイム PoC 試行 → confirmed の 3 段階を triage フローに組み込む

R2: TS/JS の reflective dispatch は対象外

• 誤解: TS/JS で書けばエントリポイントが隠蔽され、スキャナを回避できる
• 反証: reflective dispatch / runtime-generated handlers は論文が明示的に limitation とし、静的解析では扱えない
• 推奨: 同一サーバー内でデコレータ登録・registry・dynamic dispatch を混在させない。dispatch ファイルを独立モジュールに切り出し、レビューの焦点を明確化

R3: 87 サーバーは overlap-compressed の結果

• 誤解: 15,452 中 87 サーバーは 0.56% に過ぎず、リスクは局所的
• 反証: 549 cluster は同型バグを圧縮した後の数。複数の独立サーバーで再現する pattern が systemic な設計上の落とし穴を示す
• 推奨: 自組織が外部 OSS のコードパターンを参考にしている場合、同じクラスターに属する可能性。優先度を上げて対処

R4: MCP ルールを書けば差は縮まる?

• 誤解: CodeQL に MCP 専用ルールを追加すれば MCP-BiFlow と同等になる
• 反証: 既存 SAST の主因は「MCP の dispatch を entrypoint として認識できない」。登録パターンの多様性に対応するルールセット維持コストが高い
• 推奨: アーティファクトを試用し、自組織の tech stack でどの登録パターンが使われているかを確認。MCP-BiFlow の entrypoint recovery ロジックを参考にカスタムルールの優先項目を絞る

R5: LLM 補助の再現性

• 誤解: LLM が source を識別するので、同じコードでも結果が毎回変わる
• 反証: M2 削除でカバレッジ 23.6% 低下するが、コア解析 (M1) は決定論的
• 推奨: M2/M3 を使用する場合は、モデル名・プロンプトバージョン・temperature=0 を CI ログに記録。Zenodo アーティファクトのプロンプト設定を基準にする

R6: 外部追試がまだない

• 誤解: 外部検証がないので結果を信頼できない
• 反証: 2026-05-08 公開直後で時期的に当然。Zenodo アーティファクトはすでに公開
• 推奨: 自組織での試行結果 (FP 率・検出数・実行時間) をフィードバックし、外部検証データの蓄積に貢献

トラブルシューティング

まとめ

Unsafe by Flow は MCP サーバーのセキュリティを「危ないツール」のリストアップから、双方向データフローの静的解析へと引き上げた最初の体系的研究です。MCP-BiFlow の 3 コンポーネント (Entrypoint Recovery / Taint Specification / Bidirectional Analysis) と 4 オブジェクト (S_req / K_op / S_ext / K_ret) は、そのまま自社 MCP サーバーのコードレビュー観点として転用できます。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNS でのシェアをいただけると励みになります!

参考リンク

• 一次論文
  • Unsafe by Flow (arXiv:2605.07836)
  • Zenodo アーティファクト (DOI:10.5281/zenodo.19335837)
• 関連学術論文
  • Hou et al. — MCP ライフサイクル/脅威分類 (arXiv:2503.23278)
  • Huang et al. — tool-description poisoning (arXiv:2603.22489)
  • Radosevich & Halloran — MCPSafetyScanner (arXiv:2504.03767)
  • MCP-Guard — 防御フレームワーク (arXiv:2508.10991)
  • MCPSecBench — 包括ベンチ (arXiv:2508.13220)
  • MCPTox — tool poisoning ベンチ (arXiv:2508.14925)
  • InjecAgent — IPI ベンチ (arXiv:2403.02691)
• 反証・実害事例
  • AgentSeal — Runtime Exploitation of MCP Servers
• 公式
  • MCPScan (antgroup)
  • MCP 公式仕様 (2025-11-25)
  • MCP Python SDK
  • MCP Python SDK Tool System (DeepWiki)
  • FastMCP 公式ドキュメント (Tools)
  • MCP アーキテクチャ概要
  • Anthropic — MCP 紹介