はじめに：Flowiseの深刻なSSRF脆弱性について

AIアプリケーションをノーコードで構築できるFlowiseは、その手軽さから多くの開発者に利用されています。しかし、この度、Flowiseのカスタム関数において、深刻度「High」と評価されるServer-Side Request Forgery（SSRF）の脆弱性（GHSA-xhmj-rg95-44hv / CVE-2026-41270）が報告されました。この脆弱性は、社内ネットワークやクラウド環境の重要な情報に、認証済みの攻撃者が不正アクセスする可能性を秘めています。日本のフロントエンドエンジニアの皆さんにも影響が及ぶ可能性があるため、技術的な詳細と推奨される対策を解説します。

脆弱性の概要：SSRF保護の盲点

Flowiseのカスタム関数には、外部への不正なリクエストを防ぐためのSSRF保護機能が導入されています。これは、`HTTP_DENY_LIST`という設定で、内部ネットワークのアドレスなどアクセスを禁止したいIPアドレスや範囲を指定することで機能します。本来であれば、Flowiseがリクエストを送信する際にこのリストと照合し、危険なアクセスをブロックするはずでした。

しかし、この保護機能には大きな盲点がありました。`axios`や`node-fetch`といった特定のHTTPクライアントライブラリを使った通信にのみSSRF保護が適用されており、Node.jsに標準で組み込まれている`http`、`https`、`net`といった通信用モジュールが、この保護の対象外とされていたのです。

結果として、認証済みのユーザー（攻撃者）がカスタム関数内で、保護されていないこれらの組み込みモジュールを直接利用すると、設定された`HTTP_DENY_LIST`を完全に迂回し、禁止されているはずの内部アドレスに対して任意のHTTPリクエストを実行できてしまう状態でした。

具体的な脅威と影響：クラウドや社内ネットワークへの侵入

この脆弱性が悪用された場合、以下のような深刻な影響が想定されます。

1. **クラウドインスタンスの認証情報（IAMクレデンシャル）窃取**: FlowiseがAWS、GCP、Azureなどのクラウド環境で稼働している場合、攻撃者はSSRFを悪用して、そのクラウドインスタンスのメタデータサービスにアクセスできます。これにより、一時的な認証情報（IAMクレデンシャルなど）を盗み出すことが可能になり、クラウド上の他のリソース（データベース、ストレージ、APIなど）への不正アクセスへと繋がります。

2. **社内ネットワークのスキャンと不正アクセス**: 攻撃者はFlowiseサーバーをプロキシとして利用し、企業の内部ネットワークをスキャンして、脆弱なシステムやアクセス可能なサービスを探すことができます。通常は外部からアクセスできないはずの管理画面や内部APIが狙われ、さらなる攻撃の足がかりとされる危険性が高まります。

3. **機密情報の漏洩**: データベースのバックエンド、Redisキャッシュ、あるいは他の内部サービスに保存されている機密情報（顧客データ、APIキー、設定情報など）がSSRF経由で取得される可能性があります。

この攻撃にはFlowiseインスタンスへの認証（有効なAPIキーやセッション）が必要ですが、認証されているからといって安全ではありません。一度侵入を許せば、内部ネットワークが危険に晒されます。また、そもそもSSRF保護が設定されていない環境では、この問題はさらに深刻な内部リソースへの不正アクセスを許す原因となります。

フロントエンドエンジニアにとっての留意点

Flowiseは主にバックエンド寄りのAIアプリケーション構築ツールですが、フロントエンドエンジニアの皆さんも、以下のような点でこの脆弱性を意識しておく必要があります。

1. **AI機能の連携とセキュリティ**: あなたが開発するフロントエンドアプリケーションがFlowiseを介してAI機能を利用している場合、Flowiseのセキュリティは間接的にあなたのアプリケーションのセキュリティにも影響します。利用しているFlowiseインスタンスが最新かつ安全な状態であることを確認してください。

2. **APIキーや認証情報の管理**: FlowiseのAPIキーや認証情報をフロントエンドから直接扱うことは稀ですが、万が一そのようなケースがある場合、厳重な管理が求められます。この脆弱性は「認証済みの攻撃者」が悪用するため、認証情報の漏洩が攻撃のトリガーになり得ます。

3. **一般的なSSRF対策の知識**: SSRFはフロントエンドからは直接発生しにくい脆弱性ですが、バックエンドとの連携においてそのリスクを理解しておくことは非常に重要です。Node.jsの組み込みモジュールが特定のセキュリティ保護を迂回できるという今回の事例は、ライブラリやフレームワークの内部動作を理解することの重要性を示唆しています。

4. **開発環境・CI/CD環境**: ローカル開発環境やCI/CDパイプラインでFlowiseを利用している場合も、内部リソースへのアクセスが発生し得るため、本番環境と同様に注意が必要です。

いますぐ取るべき対策

この脆弱性への対策は、迅速に行う必要があります。

1. **Flowiseのバージョンアップ**: 最も推奨される対策は、Flowiseを公式パッチが適用された最新バージョンに速やかにバージョンアップすることです。最新のリリース情報を確認し、適用可能なアップデートがあればすぐに適用してください。

2. **緩和策（緊急時）**: もしバージョンアップがすぐにできない場合、以下の緩和策を検討してください。

* **カスタム関数での組み込みモジュール利用制限**: カスタム関数内で`http`、`https`、`net`といったNode.jsの組み込みモジュールの利用を可能な限り制限または禁止することを検討してください。Flowiseのセキュリティ設定で、不必要なモジュールの利用を制限できるか確認することも有効です。

* **厳格なアクセス制御**: Flowiseをインターネットに公開している場合、アクセス制御を厳格に行い、認証されていないユーザーからのアクセスを不可能にしてください。信頼できるIPアドレスからのアクセスのみを許可するなどの制限も有効です。

* **ネットワークレベルでの防御**: ファイアウォールやWAF（Web Application Firewall）を導入し、不正なリクエストをブロックする設定を検討してください。

3. **セキュリティ監視の強化**: Flowiseが稼働するサーバーやクラウド環境のログを監視し、異常なネットワーク通信やアクセスパターンがないか注意を払ってください。

まとめ

Flowiseのカスタム関数におけるSSRF脆弱性は、クラウド環境や社内ネットワークに深刻な脅威をもたらす可能性があります。フロントエンドエンジニアの皆さんも、利用しているツールチェーン全体におけるセキュリティ意識を高め、特にバックエンドサービスとの連携においては、このような脆弱性がないか常に注意を払うことが重要です。

この脆弱性への最も効果的な対策は、Flowiseの最新バージョンへの迅速なアップデートです。情報システム部門やバックエンドエンジニアと連携し、早急な対応を進めてください。日頃から最新のセキュリティ情報をキャッチアップし、安全な開発を心がけましょう。