「ITニュース」｜Flowise — chatflow をインポートしただけで RCE しうる MCP stdio の話

2026年6月1日 16:14

はじめに

セキュリティ企業 Obsidian Security は 2026年5月28日 に、オープンソースの LLM ワークフロー基盤 Flowise の CVE-2026-40933 について技術ブログを公開し、5月31日 に PoC（概念実証） と 3.1.2 環境での再検証 を追記しました（Obsidian Security）。

要点は、Custom MCP の stdio（標準入出力） 設定が、chatflow JSON のインポートだけでサーバー上のコマンド実行に至りうる、という点です。Run ボタンを押す前に、キャンバスが ツール一覧を取る段階で子プロセスが起動する、と Obsidian は説明しています。

一方、2026年4月15日 の GitHub Security Advisory（GHSA-c9gw-hvqq-f33r）では 3.1.0 で修正済み とされ、Flowise Cloud は stdio MCP を無効にしているため 非影響、と Obsidian も記載しています。

読みどころは次の3点です。

「パッチ済み」と「stdio＝コード実行の設計」 を切り分けること
認証後 RCE と Obsidian が言う 「1クリック」（悪意 chatflow のインポート）の違い
Cursor Auto-review や Anthropic Zero Trust など、別レイヤのエージェント統制との対比

※本記事は Obsidian Security、GitHub Advisory、NVD 等の公開情報をもとにした一般的な整理です。PoC の再現・無許可の侵入テストは禁止です。インシデント対応・法務判断は自社手順と専門家に従ってください。Obsidian・Flowise への取材は行っていません。

この記事での用語

1. 何が起きたのか（結論）

先に結論です。

2026年4月15日、Flowise が GHSA-c9gw-hvqq-f33r を公開。影響: ≤3.0.13、修正: 3.1.0（GitHub Advisory）
原因は Custom MCP の stdio 設定が、入力検証をすり抜けて OS コマンド実行に至る点（CWE-78、同 Advisory）
2026年5月28日〜31日、Obsidian が Responsible disclosure 後に詳細を公開。3.1.2 でも フラグ検証の bypass が可能、と 5/31 更新で述べる
攻撃の静かな経路 — 共有 chatflow を インポートすると、Available Actions（利用可能な操作） 一覧を取る段階で stdio プロセスが起動しうる（Obsidian）
Flowise Cloud は stdio 無効で 非影響。自己ホスト（Docker 等）は デフォルトで stdio 有効、と Obsidian

忙しい方向けに一言でいうと、
「CVE は 4月に直した」と公式に書いてあっても、MCP stdio が「設定＝サーバー上のコード実行」のままなら、共有 JSON を信じすぎる自己ホストは危ない、という整理です。

2. 一次・準一次情報ベースの要点

2-1. 公式 Advisory が言うこと（4月）

GitHub GHSA-c9gw-hvqq-f33r（2026-04-15）の要約です。

認証済み攻撃者が Custom MCP に 任意コマンドを載せ、サーバー上で実行できる
例: `npx` に `-c touch /tmp/pwn` を渡すと 検証をすり抜ける（Advisory 内 PoC）
修正版: 3.1.0
CVSS 3.1: 9.9 — Network / Low complexity / Low privileges / No user interaction / Scope Changed

Advisory は 「入力は sanitize されているが、十分ではない」 と明記しています。

2-2. Obsidian が 5/31 に追加したこと

Obsidian ブログ（Published 2026-05-28 / Updated 2026-05-31）が中心です。

stdio MCP とは何か（Obsidian の整理）

MCP クライアントが設定どおり 子プロセスを起動し、stdin/stdout で JSON-RPC する
ローカル開発では「意図した設計」だが、ホスト型・共有型では 低信頼の入力が 高信頼環境のプロセス起動に触れると問題化

1クリック経路（Obsidian の説明）

攻撃者が 悪意 chatflow JSON を用意（Custom MCP に悪意 stdio 設定を埋め込む）
被害者が Load Chatflow でインポート
キャンバスが Available Actions を読み込むため、バックエンドが MCP ツール列挙を開始
stdio では列挙時にコマンドが起動 — 保存も Run も不要、と Obsidian

パッチ後も残る論点

Flowise は #5741 / #5943 で `-c`、`-y` 等の 危険フラグをブロック（Obsidian 引用）
Obsidian は 3.1.2 上で、`npm_config_yes=true` が `-y` 相当として フラグ検証を bypass しうる例を示す（当該 bypass 自体は vendor に再報告していない、と明記）
推奨緩和: 環境変数 `CUSTOM_MCP_PROTOCOL=sse` で stdio を切る（stdio 不要なら 最も効く、と Obsidian）

影響（Obsidian）

Flowise プロセス権限（コンテナでは root になりやすい）で OS レベル実行
プラットフォーム内の API キー・DB 接続・クラウド資格情報 まで到達しうる

2-3. 「機能 vs 脆弱性」の線引き（Obsidian）

Obsidian は stdio MCP 自体をプロトコルバグとは呼ばない、と整理しています。

ローカル単一ユーザー — 自分で信頼する MCP を起動するのは 想定内
ホスト型プラットフォーム（Flowise / Langflow / LiteLLM 等） — 低信頼ユーザーや 共有アーティファクトが stdio 設定に触れると 脆弱性化
OX Security の横断調査では、Anthropic は expected behavior と回答した、と Obsidian は引用（プロトコル変更は期待しない、という文脈）

LiteLLM の例 — CVE-2026-30623 では 低権限キーからの実行経路を PROXY_ADMIN 限定に寄せた、と Obsidian は対比として挙げています。

3. なぜ今（5/31）注目されるか

公開情報から読み取れる「今」の理由は、おおむね次の3つです。

1. 修正後の再検証と PoC 公開
4月 Advisory 後も 根本（stdio＝実行プリミティブ） が残る、という Obsidian の主張が 5/31 Updated で具体化。SecurityWeek 等が PoC 公開を報じ、「3.1.0 以上なら安心」 という読みを修正するタイミング、と読めます（SecurityWeek 記事は ページ上の公開日が明示されていない — 執筆時点）。

2. MCP エコシステムの成熟
Cursor・Claude Code・Flowise など エージェント実行面の製品が増え、MCP 設定ファイルが 攻撃面として議論され始めている文脈（Obsidian は Langflow CVE-2025-34291 の先行研究も言及）。

3. 悪用実績は未確認
Obsidian・二次報道とも in the wild の悪用は 確認していない、というトーン。PoC 公開で 再現障壁が下がる可能性はある、と読む余地は残ります（推測）。

4. 混同しやすい点

5. 誰に関係する話か

6. 短期・中期・長期の整理（観察レーン）

時間軸の定義

短期: 0〜3か月
中期: 3か月〜1年
長期: 1年以上

短期（0〜3か月）

自己ホスト Flowise チームの パッチ適用・stdio 無効化が進む 可能性
「MCP 設定＝攻撃面」 の メディア再認識（Obsidian 5/31 Updated 契機）
不確実性: Flowise が `npm_config_yes` 型 bypass を 追加修正するか（Obsidian 5/31 時点 3.1.2 で bypass 主張、vendor 再報告なし）。CISA KEV 登録は 2026-06-01 時点 NVD 上未確認
効果が出ない条件: Cloud のみ／localhost 実験／すでに sse のみ

中期（3か月〜1年）

ホスト型 AI オーケストレータで stdio デフォルト OFF・管理者限定 MCP・サンドボックスが 製品標準に近づく 可能性（LiteLLM admin-only 修正が precedents）
RFP・社内標準に 「MCP transport 制限」 が載る 可能性（推測）
不確実性: ベンダーが stdio 機能維持を選ぶと 入力検証の穴埋めが続く（Obsidian の endless cleanup cycle 警告）
効果が出ない条件: 開発速度優先で 内部ツール扱いのまま パッチ適用率が低い

長期（1年以上）

エージェント基盤が エンタープライズ標準になるほど、MCP stdio・hooks・Custom Tool など 「設定＝コード」 が CI/CD・署名・承認 対象になる 可能性
Zero Trust for AI agents 類の 実行環境分離が 横断パターン化する 可能性（推測）
不確実性: MCP 仕様自体の breaking change の是非。次の CVE が 別ベクトルに注意を奪う
効果が出ない条件: 本件が 「Flowise 固有」 として 記憶から消える

7. まとめ

CVE-2026-40933 は 4月に 3.1.0 で 公式修正。CVSS 9.9 の 認証後 RCE（GitHub Advisory）
Obsidian（5/31 更新） は chatflow インポートだけで stdio プロセス起動しうる経路と、3.1.2 でも bypass 可能と主張 — 「パッチ済み＝stdio 安全」 とは 切り分ける
実務の第一選択（stdio 不要なら）: `CUSTOM_MCP_PROTOCOL=sse`（Obsidian 推奨）

主な参照

※本記事は Obsidian Security、GitHub Advisory、NVD 等の公開情報をもとにした一般的な整理であり、投資・法務・インシデント対応の助言ではありません。PoC の再現・無許可の侵入テストは禁止です。対応判断は自社手順と専門家に従ってください。Obsidian・Flowise への取材は行っていません。 Advisory 更新・パッチで内容が変わりうる——重要判断は最新の GitHub Advisory とベンダー告知に従ってください。