CVE-2026-70473 Flowiseの認証不足による情報漏洩リスクとAI Security対策ガイド for LLMエンジニア

結論

• 危険度: 情報なし
• 対象: flowise <= 3.1.2
• 修正: 3.1.3
• KEV: No (NVD Critical由来。CISA KEVには未登録)

最終更新: 2026-08-04 ｜ 本記事は公式情報をもとに作成しています。最新情報はベンダー公式アドバイザリを必ずご確認ください。

STEP 1: 何が起きているか

一言でいうと

CVE-2026-70473はFlowiseで、認証なしのAPIから管理情報が丸ごと漏れる脆弱性です。LLMフローを運用するユーザーには優先的に対応が必要です。攻撃者はユーザーやテナントの制限をすり抜けて、重要な設定情報を盗めます。

やさしく説明すると

Flowiseはドラッグ＆ドロップでAIの動作を組み立てるツールです。この脆弱性は、玄関の鍵がかかっていないのに近い状態で、誰でも管理者だけが見られるはずの設定情報を全部見られてしまいます。合鍵を持っていなくても、勝手に他人の部屋の情報を全部見られるようなものです。これにより、次の攻撃につながる情報が簡単に漏れてしまいます。

技術的な原因

この問題はCWE-200（情報漏洩）、CWE-202（認可バイパス）、CWE-862（アクセス制御の不備）に該当します。具体的には、FlowiseのGET /api/v1/upsert-history APIが要求したユーザーやワークスペースに限定せずサーバ全体のアップサート履歴を返します。認可チェックやテナント間の分離、データ取得制限（ページングや制限）が欠如しているため大量かつ機密性の高い情報が漏れます。

影響を受けると何が困るか

• 攻撃者はAPIキーや認証情報を取得して、OpenAIやAnthropicなどのLLM APIを悪用できる
• テナントやワークスペースの境界がなくなるため顧客データやプロンプトコンテキストが漏洩する
• ベクトルストアの接続情報(Qdrant Server URLやコレクション名)が露見し、RAG（Retrieval-Augmented Generation）データの改ざんや不正検索が可能になる
• Agent（AIエージェント）フレームワークの乗っ取りにつながる恐れがある
• 請求コストが不正に増大する可能性がある
• AI駆動のコーディングツール(Cursor、Cline、Copilotなど)が情報漏洩経路となりうる

もっと詳しく調べたい人へ — 公式情報源マップ

本記事は以下の公式・準公式の情報源から内容を集約しています。一次情報を確認したい場合や英語で詳細を読みたい場合は、各リンクから直接アクセスできます。

掲載しているのは無料でアクセスできる情報源のみです。CVEによっては掲載がないサイトもあります（特にJVN iPediaは日本国内で報告された脆弱性のみ掲載）。

STEP 2: 急ぎ対応すべきか判断する

結論: 低

判断根拠

• CVSSスコアはNVDに未掲載。GitHub AdvisoryではHigh評価だが、世界的な詳細スコアは不明
• EPSS（悪用予測スコア）は提供されていない
• CISA KEVには登録されておらず、ランサムウェアによる悪用は未確認
• 公開のPoCコードは存在せず、現時点での武器化は確認されていない
• 攻撃には認証なしでエンドポイントにアクセス可能という条件が必要。ただし認可の欠如により深刻な情報漏洩が起きている

誰が動くべきか

• Flowiseを使ってLLMフローを開発・運用するエンジニア・SRE・SecOpsチーム
• エージェントフレームワーク開発者（LangChainやAutoGenなど）でFlowiseを連携している場合
• AI GatewayやLLM Proxy環境にFlowiseを組み込んでいる運用者
• バイブコーダー開発者でFlowise連携のカスタムAI開発基盤を利用している場合

STEP 3: 自分の環境が対象か確認する

影響を受けるバージョン

バージョン確認コマンド

Node.js（npm）

npm list flowise

出力例:

└── flowise@3.1.2

判定: 出力に 3.1.2 以下が含まれる場合は脆弱。3.1.3 以上なら安全。

設定確認

この脆弱性は特定の設定によるものではなく、APIの認可チェック不足によるため、設定確認は不要です。バージョン確認が主な検出手段です。

Nucleiテンプレートでの検出

本CVEに対応した公開Nucleiテンプレートは現時点で提供されていません。必ずバージョン確認で対象を検出してください。

STEP 4: 修正を適用する

パッチ適用

Node.js（npm）

npm install flowise@3.1.3

判定: バージョンが 3.1.3 以上になれば脆弱性は修正されています。

注意: パッチ適用前に必ずバックアップを取得し、ステージング環境で動作確認してください。運用中のサービス停止時間などを考慮した計画的な更新を推奨します。

パッチ即時適用ができない場合の暫定対応

2026年8月時点で公式の暫定対応策は公表されていません。APIエンドポイントへのアクセス制限やWAFでのルール設定を検討してください。

STEP 5: 修正されたことを確認する

STEP 3で実行したバージョン確認コマンドを再度実行します。

期待される出力

Node.js（npm）

npm list flowise

出力例:

└── flowise@3.1.3

判定: バージョンが 3.1.3 以上ならOK。

追加で確認すべきこと

公式または独自にAPIリクエストのログを調査し、不審なアクセスが無いかを確認してください。公開されたNucleiテンプレートが将来提供されれば、再検査に利用しましょう。

補足: 悪用観測状況

現時点でランサムウェアや攻撃者による悪用は確認されていません。公開PoCもありません。GitHub Advisoriesでは高リスク評価ですが、実際の悪用は報告されていません。

補足: CVSSメトリクス詳細

• AV（攻撃元のアクセスベクター）: 未公開だが、ネットワーク経由のAPIアクセスが必要
• AC（攻撃の難易度）: 中程度（認証なしのAPIのためアクセスは簡単だが、APIの存在が必要）
• PR（特権要件）: なし（認証無しで利用できるエンドポイント）
• UI（ユーザーの関与）: なし（攻撃者は自動で実行可能）
• S（スコープ）: 拡大（システム全体の情報が漏洩する）
• C（機密性への影響）: 完全（機密情報が漏出）
• I（完全性への影響）: 部分的（この脆弱性は情報漏洩だが、その後の攻撃で改ざんが起きる可能性あり）
• A（可用性への影響）: なし（直接の可用性障害はない）

よくある質問（FAQ）

Q. このCVEに対応するために最低限すべきことは何ですか？

A. STEP 3のバージョン確認を実施し、該当バージョンならSTEP 4で3.1.3以上へのアップデートを行ってください。

Q. パッチが適用できない場合、どうすればよいですか？

A. 公式の暫定対応はありませんが、APIアクセス制限やWAF設定で通信を制限し、さらに監視強化で対応することを推奨します。

Q. 既に攻撃を受けているか確認する方法はありますか？

A. APIアクセスログに不審な大量リクエストや大量レスポンスがあったかを調査してください。GitHub Advisoryなどで追加情報が出る場合もあります。

Q. なぜEPSSスコアが重要なのですか？

A. CVSSは脆弱性の深刻度を示しますが、EPSSは実際に悪用される確率を示します。両者を合わせることで対応優先度判断がより正確になります。

Q. このCVEと類似の脆弱性は他にもありますか？

A. CWE-200やCWE-202に分類される認可欠如や情報漏洩の脆弱性は他にも多く存在し、特にAI/LLM関連APIでは注意が必要です。

参考文献

• NVD – CVE-2026-70473
• GitHub Advisory – Flowise 情報漏洩
• Flowise 修正コミット
• Flowise 3.1.3 リリース

関連トピック・タグから探す

本記事に関連するキーワードから、他のAIセキュリティ記事を探せます。

• 情報漏洩 に関するCVE・脆弱性記事一覧
• authz-missing に関するCVE・脆弱性記事一覧
• LLM に関するCVE・脆弱性記事一覧
• Vector DB に関するCVE・脆弱性記事一覧
• AIフレームワーク に関するCVE・脆弱性記事一覧

2026-08-05 追記

本記事の公開後、以下の重要な変化が確認されました（公開からの経過: 0日）。

CVSSスコア変化

初回公開時点で「9 (low)」と記載されていたCVSSスコアが、NVD（National Vulnerability Database）による再評価により「8.3 (HIGH)」へと下方修正されました。この修正は、本脆弱性の危険度が「Critical（9.0以上）」から「High（7.0〜8.9）」相当に見直されたことを意味します。システム管理者やセキュリティ担当者は、引き続き優先度高く対応すべきですが、初報から若干リスク評価が緩和された点に留意してください。既に対策済みの組織では、改めて現時点での公的評価を参照し、対応方針が過剰防御となっていないか再検討するのも良いでしょう。

タイトルプレフィックス未付与

記事公開時点では、タイトルに危険度プレフィックス（例：「【高】」「【重大】」）が付与されていませんでしたが、最新のCVSS評価に基づき「【高】」プレフィックスの付与が妥当であると判明しました。これは記事作成時の基準適用漏れに対する補正となります。組織内でリスク管理や情報伝達のフローを運用している場合、「【高】」プレフィックスの有無が通知やエスカレーション条件となっているケースも考えられます。今後は本脆弱性を「High」クラスとして認識し、システム上もラベリングや優先順位付けを見直してください。