[解説] Flowiseセルフホスト環境におけるOAuthトークン漏洩の脆弱性 (CVE-2026-41273)
はじめに：Flowiseユーザーが直面する高深刻度脆弱性
Flowiseは、LLM（大規模言語モデル）ベースのアプリケーションを簡単に構築・デプロイできるローコード/ノーコードツールとして、多くの開発者や企業に利用されています。特にセルフホスト環境で運用されている場合、システム全体の柔軟性が高まる一方で、セキュリティ対策は利用者に委ねられます。今回、Flowiseのセルフホスト環境において、その根幹を揺るがしかねない深刻度「High」の脆弱性（GHSA-6f7g-v4pp-r667 / CVE-2026-41273）が報告されました。
この脆弱性は、Flowiseが外部サービス（Gmail、Salesforceなど）と連携するために使用する「OAuth 2.0アクセストークン」が、未認証の第三者によって簡単に窃取されてしまうというものです。フロントエンドエンジニアの皆さんにとって、公開APIの設計と認証の重要性を改めて認識するきっかけとなるでしょう。
脆弱性の技術的詳細：OAuthトークンはなぜ盗まれるのか？
この脆弱性の核心は、Flowiseの複数のAPIエンドポイントにおける認証・認可の不備にあります。具体的には、以下の二つのステップが組み合わさることで、悪意ある第三者がOAuthトークンを取得できてしまいます。
Flowiseには、ウェブサイトへの埋め込みや公開URLを通じて、認証なしで誰でもアクセスできる「公開チャットフロー」機能があります。この公開チャットフローの設定情報を取得するためのAPIエンドポイント <code>/api/v1/public-chatbotConfig/<chatflowId></code> が、認証なしで内部のワークフローデータ（<code>flowData</code>）を公開していました。問題なのは、この<code>flowData</code>の中に、外部サービス連携に不可欠な「OAuthクレデンシャルのID」が含まれてしまっていた点です。
フロントエンドから見れば、ウェブサイトに埋め込まれたチャットボットが特定のIDを持つAPIを叩く際、そのレスポンスに、本来ならば秘匿されるべきバックエンドの設定情報が混入していたとイメージできます。この<code>chatflowId</code>は、公開URLなどから容易に特定可能です。
さらに深刻な問題は、別のAPIエンドポイント <code>/api/v1/oauth2-credential/refresh/<credentialId></code> が存在することです。このAPIは、前述のステップ1で取得した「OAuthクレデンシャルID」を受け取ると、認証や認可のチェックを一切行わずに、新しいOAuth 2.0アクセストークンを生成し、そのまま攻撃者に返してしまいます。
つまり、攻撃者は公開されているチャットフローのIDを足がかりに、わずか2回のAPI呼び出しだけで、Flowiseが連携している外部サービスへの「アクセス許可証」を、何の認証もなしに手に入れることができてしまうのです。
フロントエンドエンジニアが知るべき影響とリスク
この脆弱性が悪用された場合、その影響は甚大です。攻撃者は不正に入手したOAuth 2.0アクセストークンを利用して、Flowiseで設定された以下のサードパーティサービスに対して、Flowiseインスタンス自身と同じ権限でアクセスできてしまいます。
例えば、Gmailへの連携が設定されていれば、メールの読み取り、送信、アドレス帳へのアクセスなどが可能になります。SalesforceのようなCRMツールと連携していれば、顧客データへの不正アクセス、改ざん、削除といった被害も考えられます。最悪の場合、これらのサービスにおけるアカウントが乗っ取られる可能性も否定できません。
この問題は、特に公開チャットフローをインターネットに公開しているセルフホストのFlowiseインスタンスに大きな影響を及ぼします。フロントエンド開発者は、自身が構築するUIの裏側で動くAPIがどのような情報を公開し、どのような認証・認可メカニズムを持っているかを常に意識し、バックエンドチームとの連携を密にすることが、こうしたリスクからシステムを守る上で不可欠です。
いますぐ取るべき対策
この深刻な脆弱性からシステムを保護するためには、迅速な対応が求められます。
システムを常に最新の状態に保ち、定期的にセキュリティ脆弱性情報を確認する習慣は、フロントエンドに限らず全てのエンジニアにとって極めて重要です。
まとめ
Flowiseのセルフホスト環境におけるOAuthトークン漏洩の脆弱性 (CVE-2026-41273) は、公開APIの設計における認証・認可の重要性、そしてローコード/ノーコードツールといえどもその内部のセキュリティメカニズムを理解することの必要性を示しています。フロントエンドエンジニアの皆さんには、ユーザーインターフェースの向こう側にあるAPIやバックエンドのセキュリティにも意識を向け、安全なシステム構築に貢献いただければ幸いです。すぐに推奨される対策を実施し、システムの安全を確保してください。