Flowise の Python コード検証を正規表現で迂回でき、未認証の予測 API 経由でプロンプトインジェクションからコード実行に至る（3.1.3 未満）

Critical（CVSS 9.8）に分類されるFlowiseAI Flowise（LLM アプリを GUI で組み立てるオープンソースのローコード基盤）。NVD の記述は「3.1.3 より前」、CPE の適用範囲は 3.1.4 以下となっている。の脆弱性です。NVD の記述はこうである。「Flowise の 3.1.3 より前のバージョンは、CSV および Airtable の Agent ノードに**正規表現ベースの Python コード検証の迂回**を含んでおり、未認証の攻撃者がプロンプトインジェクションを介して悪意あるコードを注入できる。攻撃者は `pd.read_json()` のようなブロックされていない pandas の関数を悪用して、**データセットを外部へ持ち出す、内部サービスに対して SSRF を行う、あるいは未認証の予測 API を通じてコード実行を達成する**ことができる」。 **この案件が示しているのは、拒否リスト方式の限界である。**Flowise は生成された Python コードを実行する前に、危険な関数を正規表現で弾こうとしていた。ところが pandas のように広い機能を持つライブラリでは、**ファイルやネットワークに触れる入口が1つではない**。`pd.read_json()` は名前のうえでは「JSON を読む」だけの関数だが、URL を受け取れるので、そのままネットワークアクセスの手段になる。拒否リストに載っていない同等機能が1つ残っていれば、検証は通過する。 **もう1つの要点は、攻撃の入口がプロンプトであることである。**通常のコードインジェクションと違い、ここでは攻撃者がソースコードを送り込むわけではない。**LLM に渡る自然言語のプロンプトを操作して、LLM に問題のあるコードを書かせる。**生成されたコードは Flowise の検証を通り、実行される。つまり、入力検証の対象が「人間が書いたコード」から「LLM が書いたコード」へ移っているのに、検証の方法が従来のままだったという構図である。**LLM を組み込んだアプリ全般に横展開して考える価値のある型である。** **未認証の予測 API（prediction API）から届くという点が深刻さを決めている。**CVSS 9.8（AV:N / AC:L / PR:N / UI:N、C:H / I:H / A:H）で、権限も利用者の操作も要らない。Flowise のチャットフローを外部に公開している構成では、**その公開エンドポイントがそのまま攻撃面になる**。 **被害の形は3つ挙げられている。**①CSV / Airtable ノードが扱っているデータセットの外部持ち出し。②内部サービスに対する SSRF。ここにはクラウドのメタデータエンドポイントも含まれうる。③コード実行。①と②は「LLM アプリの脆弱性」というより、**Flowise が動いているネットワークの内側へ手が届く**という話である。 CVSS を採点しているのは NVD 自身（nvd@nist.gov、Primary）で、NVD の状態は Analyzed、最終更新は 2026-09-03。**CISA KEV には 2026-09-04 時点で収載されていない。**参照には FlowiseAI の GitHub Security Advisory（GHSA-w7x8-q2gp-5cgg）と VulnCheck のアドバイザリが挙がっている。

対応は **Flowise を 3.1.3 以上へ更新する**ことである。ただし1点ややこしい事情がある。**NVD の記述は「3.1.3 より前」だが、CPE の適用範囲は「3.1.4 以下」になっている。**この2つは食い違っている。判断がつくまでは、**入手できる最新版へ上げたうえで、下の緩和策も併せて残しておく**のが安全である。上げた版が対象外だと断定するには、FlowiseAI の Security Advisory（GHSA-w7x8-q2gp-5cgg）で修正コミットを確認する必要がある。 **更新までのあいだ、まず未認証の予測 API を閉じる。**この欠陥は権限不要で成立するので、公開しているチャットフローのエンドポイントが直接の攻撃面になる。Flowise には API キーによる保護の設定があるので、**未認証で叩けるチャットフローが残っていないかを一覧で確認する**。社内利用しかしていないなら、そもそもインターネットに出す理由がない。 **CSV / Airtable の Agent ノードを使っていないなら、その経路を止める。**問題が起きるのはこの2種類のノードの Python コード検証である。フローの中で使っていないなら、有効なままにしておく理由はない。 **SSRF への備えは Flowise の外側で行う。**クラウド上で動かしているなら、**インスタンスメタデータへの到達を塞ぐ**のがいちばん効く。AWS なら IMDSv2 を必須にする、GCP / Azure ならメタデータサーバへの egress をコンテナから遮断する。Flowise のプロセスから出ていく通信を、必要な宛先だけに絞るのが本筋である。 **侵害の確認は3点を見る。**①Flowise が扱っているデータソース（CSV、Airtable の資格情報）が外部へ送られた形跡が無いか。プロセスから外向きに出た通信のログを見る。②内部サービスやクラウドのメタデータエンドポイントへのアクセスが無いか。③予測 API への未認証リクエストのうち、想定外のプロンプトを含むものが無いか。**Flowise に登録した各種 API キー（LLM プロバイダ、データソース）は、疑いがあるなら再発行する。**

FlowiseAI Flowise（LLM アプリを GUI で組み立てるオープンソースのローコード基盤）。NVD の記述は「3.1.3 より前」、CPE の適用範囲は 3.1.4 以下となっている。 を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-73487）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。