はじめに：Flowiseの深刻なRCE脆弱性にご注意ください

日本のフロントエンドエンジニアの皆さん、こんにちは。今回は、バックエンドのツールであるFlowiseで非常に深刻な脆弱性（GHSA-xc48-889x-5qmw / CVE-2026-69263）が報告されましたので、その詳細と対策について解説します。FlowiseはLLMアプリケーションの構築に用いられるツールですが、開発環境やCI/CDパイプラインなどで利用している場合、あるいはバックエンドチームとの連携で関わる可能性があるため、決して他人事ではありません。

この脆弱性は、Flowiseサーバー上で認証なしで任意のコードを実行できてしまう（Unauthenticated Remote Code Execution, RCE）という極めて危険なものです。つまり、攻撃者は認証情報を必要とせずにサーバーを完全に制御下に置くことができ、情報漏洩やサービス停止、サーバー改ざんといった壊滅的な被害につながります。

脆弱性の詳細：パッチの抜け穴が悪夢の始まり

事の発端は、以前発見されたFlowiseの脆弱性（CVE-2025-8943）に対するセキュリティパッチでした。このパッチは、`npx`コマンドの`-y`や`--yes`といった危険なオプション（ユーザーの確認なしに任意のパッケージが自動インストール・実行される）をブロックすることを目的としていました。これらのコマンドラインオプション自体は、確かに効果的にブロックされていました。

しかし、問題はそのパッチの実装方法にありました。パッチは、子プロセスに渡される環境変数をチェックする仕組みを含んでいましたが、そのチェックはごく限られた4つの環境変数名だけをブロックする「ブラックリスト方式」だったのです。そして、このリストに「ある重要な環境変数」が含まれていませんでした。

それが、`npm_config_yes`です。`npm`は、`npm_config_`というプレフィックスを持つ環境変数から設定を読み込む仕組みを持っています。攻撃者が`npm_config_yes=true`という環境変数を設定すると、`npx`はあたかも`-y`や`--yes`オプションが指定されたかのように振る舞い、自動でパッケージをインストールし、実行してしまいます。これにより、本来パッチが防ごうとしていた危険な挙動が完全に回避されてしまうのです。

さらに悪いことに、この脆弱性はFlowiseのセキュリティ機能である`CUSTOM_MCP_SECURITY_CHECK=true`が有効になっている環境でも機能します。そしてFlowiseのデフォルト設定では認証機能が有効になっていない場合が多く、その環境では**認証されていない攻撃者でも、FlowiseのAPIにアクセスできるだけで、サーバー上で任意のコードを遠隔で実行できてしまいます（Unauthenticated RCE）**。

根本原因：ブロックリスト方式の限界

この脆弱性の根本原因は、問題の本質を「コマンドラインオプションのフィルタリング」として捉えてしまった点にあります。実際には、`--yes`オプションで制御される挙動は、`npm`の環境変数ベースの設定を介しても実現可能です。これは、`node`や`python3`などの他のインタープリタでも同様の問題を引き起こす可能性があります。

`packages/components/nodes/tools/MCP/core.ts`内の`validateEnvironmentVariables`関数には、わずか4つの環境変数しか危険なものとしてリストアップされていませんでした。`npm_config_yes`はこのリストに含まれていなかったため、チェックをすり抜けてしまいます。

危険な変数をブロックリストで列挙する方式では、将来的に新しいインタープリタが追加されたり、新たな環境変数による制御が見つかったりすると、また同様のバイパス手法が生まれる可能性があり、すべての潜在的な危険な環境変数を網羅することは不可能であり、根本的な対策とは言えません。

具体的な攻撃シナリオと追加のバイパス経路

攻撃者は、以下のようなMCPサーバー設定を悪用することで、パッチを容易に回避できます。

```json { "mcpServers": { "bypass": { "command": "npx", "args": ["malicious-package"], "env": { "npm_config_yes": "true" } } } } ```

この設定では、コマンドラインフラグも環境変数もチェックをすり抜け、`npx`は指定された悪意のあるパッケージを自動でインストールし、Flowiseプロセスの権限で実行してしまいます。

また、同様の根本原因により、以下の環境変数もブロックリストになく、他のインタープリタを通じて悪用される可能性があります。

・`npm_config_prefix`: `npx`でパッケージインストール先を攻撃者が制御するパスにリダイレクト。 ・`npm_config_userconfig`: `npx`で攻撃者が制御する`.npmrc`設定ファイルをロード。 ・`NODE_PATH`: `node`でモジュールロードパスを攻撃者が制御するパスに設定。 ・`PYTHONPATH`: `python3`でモジュールロードパスを攻撃者が制御するパスに設定。

もたらされる影響：サーバーが完全に攻撃者の手に

この脆弱性が悪用されると、Flowiseプロセスと同じ権限で、サーバー上で完全にリモートコードが実行されてしまいます。Flowiseのデフォルト設定で認証機能が有効になっていない環境では、攻撃者は何の認証情報も不要で、Flowiseサーバーを乗っ取ることができます。これは、データ漏洩、サービス停止、サーバーの改ざん、さらにはバックドアの設置など、非常に深刻な結果を招きます。

推奨される対策：今すぐできることと根本的な解決策

この脆弱性の影響を受けるバージョンは、**Flowise 3.1.1（2026年3月29日時点の最新版）**です。至急の対応が求められます。

最も根本的な対策は、Flowiseが子プロセスに環境変数を渡す際に、以下のいずれかの方法を取ることです。

1. **環境変数を完全に除去する。** 2. **ホワイトリスト方式を採用する。** すなわち、**明示的に許可された変数のみ**を子プロセスに渡すように変更する。

既存の危険な環境変数（`npm_config_yes`、`npm_config_prefix`、`NODE_PATH`、`PYTHONPATH`など）を現在のブロックリストに追加することは、目先の穴を塞ぐ一時的な措置に過ぎません。将来的に新しいインタープリタが追加されたり、新たな環境変数による制御が見つかったりすると、再度同様のバイパス手法が生まれる可能性があります。Flowiseの開発チームには、根本的な解決策としてホワイトリスト方式への移行が強く推奨されています。

まとめ

FlowiseのUnauthenticated RCE脆弱性は、認証なしでサーバーが完全に攻撃者の手に渡る非常に危険な問題です。開発環境や本番環境でFlowiseを利用している場合は、関連情報に注意を払い、提供され次第、速やかにパッチを適用するか、上記の推奨対策を検討してください。

自身の開発環境やCI/CDパイプラインだけでなく、利用している各種ツールの脆弱性情報にも目を配り、常に最新のセキュリティプラクティスを心がけることが、私たちのシステムの安全を守る上で不可欠です。