JVN（Japan Vulnerability Notes）は、flowiseaiが開発する対話型AIプラットフォームFlowiseにおけるサーバサイドリクエストフォージェリ（SSRF）の脆弱性を公表した。外部からの入力により、Flowiseを稼働させているサーバが意図しない通信を行うおそれがあり、内部ネットワークやクラウド環境の情報が外部から取得されるリスクがある。現時点で公表されている情報によれば、Flowiseの一部コンポーネントに実装されているHTTP通信機能やSSRF防御機構の不備に起因して、攻撃者がサーバに対して任意のHTTPリクエストを実行させることが可能になるとされている。
脆弱性の詳細
一般的に、Flowiseのようなワークフロー型のAIプラットフォームでは、外部APIやWebページから情報を取得するためのノードやコンポーネントが多数用意されている。これらの機能のうち、URLやエンドポイントを外部入力に基づいて決定するものについて、SSRF対策が不十分な場合、攻撃者が細工したリクエストを送ることで、対象サーバに「攻撃者の代わりに」別の宛先へ通信させる問題が生じる。SSRFは、攻撃者が指定したURLに対してサーバ側がHTTPリクエスト等を実行してしまうことで、以下のような影響につながる可能性がある。
- 本来外部から到達できない内部ネットワーク上のサービスへのアクセス
- クラウド環境のメタデータサービスへのアクセスによるインスタンス情報や一時認証情報の取得
- 管理者が意図していない外部サイトへの接続や、外部サービスへの不正な要求送信
Flowiseに関しては、HTTP通信を行うノードやコンポーネントにおいて、SSRF防御用のdenyリスト（アクセスを禁止する宛先の一覧）の扱いが不十分であることや、Node.jsの組み込みモジュール（http、https、netなど）を利用した通信経路が防御対象から漏れていることが指摘されている。これにより、運用者が「内部向けやクラウドメタデータなどの宛先はブロックされている」と想定していたにもかかわらず、攻撃者が特定のノードや機能を経由して内部ネットワークやクラウドメタデータサービスにアクセスできてしまう状況が生じ得る。
SSRFに関するCVE番号やCVSSスコア（基本値、深刻度）、影響を受ける具体的なコンポーネントや攻撃成立条件については、JVN（Japan Vulnerability Notes）および各種脆弱性情報データベース、開発元FlowiseAIが公開するアドバイザリやセキュリティ情報を根拠として整理する必要がある。現時点でFlowiseに対して複数のSSRF関連CVEが登録されており、対象バージョンや攻撃の前提条件（認証の有無、公開チャットフローの存在など）、内部ネットワークおよびクラウドメタデータへの到達可能性は、それぞれのCVEごとに異なる場合がある。自組織で利用しているFlowiseのバージョンと構成がどのCVEの影響範囲に該当するかを確認し、CVSSスコアと合わせて、優先度を踏まえた対応が求められる。
注意：本脆弱性群に関する個別のCVE番号・CVSSスコア、攻撃成立条件や具体的影響の範囲は、JVN（Japan Vulnerability Notes）の当該アドバイザリおよび開発元・各種脆弱性情報サイトに記載された内容をもとに精査する必要がある。日本の中小企業では、Flowiseをインターネットに公開しているかどうか、社内ネットワーク（オンプレミス環境）への到達範囲、利用しているクラウドサービスとメタデータ経由の情報取得リスクによって被害の大きさが変わるため、まずは自社の配置状況と公開形態を確認することが重要である。
影響を受ける製品・バージョン
- flowiseai Flowise および関連コンポーネント（HTTPノードやflowise-componentsなど）、JVN（Japan Vulnerability Notes）および開発元が公表するアドバイザリに記載された影響範囲に該当するバージョン（例：3.0.x系および3.1.0未満など、一部のSSRF対策が不十分なバージョン）。具体的な影響バージョンは、各CVE・アドバイザリの記載に従って判定する必要がある。
推奨される対策
- 修正版へのアップデート：FlowiseAIおよびJVN（Japan Vulnerability Notes）が示す修正状況に従い、影響を受けるバージョンを利用している場合は、SSRF対策が反映された修正版（例：3.0.13以降や3.1.0以降など、各アドバイザリで推奨されるバージョン）へ更新する。特に、HTTPノードやfetch-links API、httpSecurity.tsなどSSRF防御に関連するコンポーネントについて、最新版でdenyリストやメタデータ宛先の制御が適切に実装されていることを確認する。
- 公開範囲の見直し：インターネットからFlowiseの管理画面やAPI、公開チャットフローに直接到達できる構成はリスクを高めるため、業務要件を満たす範囲でアクセス元を制限する。特に、URL取得ノードやHTTPノードなど、外部入力に基づいて任意のURLへアクセスできる機能を含むフローについては、公開範囲を最小限にし、認証やIP制限、VPNなどで接続元を絞り込むことが望ましい。
- ネットワーク到達性の制御：Flowiseを稼働させているサーバから、内部ネットワークやクラウドのメタデータサービス宛先（例：クラウドベンダーが提供するメタデータIPアドレス）へ到達できると、SSRF攻撃により被害が拡大し得る。ファイアウォールやクラウドのセキュリティグループなどを用いて、Flowiseサーバからの外向き通信先を必要最小限の宛先のみ許可し、メタデータサービスや管理系ネットワークへの経路を遮断することが重要である。
- ログ監視の強化：外向き通信（HTTPリクエスト）の異常、短時間の大量接続、通常利用しない宛先へのアクセスの有無を点検し、兆候があれば調査する。Flowiseのアプリケーションログやリバースプロキシ／APIゲートウェイのアクセスログ、ファイアウォールログなどを統合して監視し、内部IPレンジやクラウドメタデータサービスへのアクセスがないかを確認することで、SSRF攻撃の早期検知につながる。
日本の中小企業が今すぐ取るべき行動
- 優先1：設置場所と公開状況を棚卸し：Flowiseの稼働サーバの設置場所（クラウド／オンプレミス）、インターネット公開の有無、アクセス制御（IP制限・VPN・認証方式）を一覧化する。特に、社外から直接アクセス可能なチャットフローやAPIエンドポイントが存在するかどうか、外部入力からURL指定が可能なノードを含むフローが公開されていないかを確認する。
- 優先2：バージョン確認と影響判定：稼働中のFlowiseおよび関連コンポーネント（flowise-componentsなど）のバージョンを確認し、JVN（Japan Vulnerability Notes）および各CVEのアドバイザリに記載された影響範囲に該当するかを判定する。複数のSSRF関連CVEが存在するため、自社環境に関係するCVEとその対象バージョンを洗い出し、優先度をつけて対応する。
- 優先3：修正版へ更新計画を立て即時適用：業務影響の少ない時間帯を決め、更新と動作確認（主要フローの実行、認証、外部連携、URL取得ノードの挙動など）までをセットで実施する。更新後は、SSRF対策が有効になっているか（denyリストが機能しているか、メタデータサービスなどへのアクセスがブロックされるか）をテスト環境も含めて確認することが望ましい。
- 優先4：暫定的な防御策の適用：更新まで時間がかかる場合は、アクセス元制限やサーバの外向き通信制限を先に適用し、悪用される経路を狭める。具体的には、Flowise管理画面・APIへのアクセスをVPN経由や社内IPアドレスに限定する、Flowiseサーバからの外向きHTTP通信をプロキシ経由に統一しプロキシ側で宛先制御を行う、メタデータサービスや内部管理ネットワーク宛先への通信を遮断する、といった暫定対策を検討する。
- 優先5：関連ログの保全：更新前後の通信ログやアプリログを保全し、不審な外部接続や内部宛先アクセスがないかを確認する。SSRF攻撃は、通常の利用と似た形でHTTPリクエストが行われることが多いため、過去のログを一定期間さかのぼって調査し、内部IPレンジやクラウドメタデータサービスへのアクセスがなかったかを確認するとともに、今後のインシデント対応に備えてログ保全ポリシーを整備する。
CSRIからの現場アドバイス
実際のペネトレーションテストでは、外部入力をそのままURLとして扱う機能や、外部連携のための「取得・検証」処理が弱い箇所からSSRFが見つかることが多い。Flowiseのようなプラットフォームでも、チャットフロー／エージェントフローの中で、ユーザ入力や外部ドキュメントの内容をもとにHTTPリクエストを組み立てるノードやカスタム関数機能が存在する場合、それらの入力検証や宛先制御が不十分だと、診断報告書でSSRFとして指摘されることがある。よく問題となるのが、サーバの外向き通信が無制限で、内部宛先やメタデータ宛先へ到達できてしまう構成である。
例えるなら、受付が「この住所に手紙を届けて」と頼まれると、相手が誰でも社内便で社内の重要部署に届けてしまうようなものだ。つまり攻撃者は、自分では入れない社内ネットワークの奥やクラウドの設定情報へ、サーバを踏み台にして問い合わせできるということで、情報漏えいや追加侵入のきっかけになり得る。FlowiseにおけるSSRFも、表面的にはユーザがURLを指定して情報を取得しているように見えるが、裏側ではサーバが内部ネットワークやクラウドメタデータサービスにアクセスしている可能性があるため、設計段階から外部入力と通信先の関係を厳密に制御することが求められる。
まずFlowiseが稼働しているサーバとバージョンを確認し、JVN（Japan Vulnerability Notes）および各CVEアドバイザリの影響範囲に該当するかを判断する。次に担当者（または運用ベンダー）に、修正版への更新可否と実施日程の提示を依頼する。あわせて今週中に、サーバの外向き通信を必要な宛先に限定できるか、ネットワーク担当と確認して暫定対策を進めたい。なお、具体的な攻撃経路や既存のインシデント事例については、現時点で公開されている情報の範囲内で判断するしかなく、詳細な悪用状況や実際の被害事例については「詳細は現時点で不明」であることに留意しつつ、公開されている技術的情報をもとに予防的な対策を講じることが現場では重要となる。