Difyのログイン後フローに存在したオープンリダイレクト脆弱性：TrendAI™ Researchによる発見から修正まで

概要

TrendAI™ Researchは、Difyのログイン後の認証フローにオープンリダイレクト脆弱性（ZDI-26-452 / CVE-2026-18266、CVSS 5.4）を発見しました。この脆弱性を悪用すると、未検証のURLパラメータを指定することで、サインイン直後の認証済みユーザを攻撃者の管理する宛先へリダイレクトさせることができます。攻撃者は認証トークンを取得し、ユーザになりすまして操作できるようになります。Difyは7月13日に修正をリリースしました。

Difyとは何か、なぜ重要なのか

脆弱性そのものの説明に入る前に、Difyとは何か、そしてなぜここでのバグが重い意味を持つのかを押さえておきましょう。DifyはいつのまにかAIアプリ構築の定番プラットフォームの1つとなっており、サインインフローのようなありふれた箇所の欠陥でも、驚くほど多くのユーザに影響が及ぶ可能性があります。

Difyは、AIワークフロー、チャットボット、エージェントを構築するためのオープンソースのLLMOpsプラットフォームで、ビジュアルビルダー、RAGパイプライン、モデル管理、可観測性の機能を備えています。GitHubのスター数は14万件超、APIイメージのDockerプル数は1,000万回超に達し、数十の業界で導入されるなど、最も広く利用されているAIアプリプラットフォームの1つです。セルフホスト型の展開とマルチテナント型クラウドサービス（cloud.dify.ai）の両方で提供されているため、1つのバグがテナント間にまたがるリスクを伴う可能性もあります。

その人気はアジア太平洋地域に集中していますが、顧客向けのAIチャットウィジェットを構築する欧米企業の間でも導入が広がりつつあります。今回のバグが影響するのは、まさにこのウィジェットのサインイン経路（Difyの埋め込み型「webapp」サインインフロー）です。また、Difyは、TrendAI™ ResearchがAI関連CVEの最も急成長している発生源として特定した「LLMツール・アプリケーション」カテゴリの中心に位置しています。このカテゴリでは、コードインジェクション、SSRF、パストラバーサルに加え、今回のように古典的なWeb認証の欠陥が新しいAIツールで再び姿を現しています。

脆弱性の詳細：検証されないログイン後リダイレクト

ログイン後フローは、リダイレクト先を十分に検証しないまま信頼していました。しかも、その宛先はURLパラメータから取得されるため、細工されたリンクによって本来向かうべきでない場所を指定できてしまいます。つまり実際には、認証直後のセッションがトークンごと、攻撃者の管理するサイトへ送られてしまうおそれがあったということです。

影響箇所: 標準のサインインフォーム、SSO認証、メール＋コード認証、そしてチャットウィジェットをサードパーティのサイトでホストする際に使われる埋め込み型webappサインインフローにまたがる、Difyのログイン後リダイレクト処理。
内容: ログイン後のリダイレクト先の検証が不十分だったため、認証直後のセッションが外部の攻撃者管理オリジンへ送信される可能性がありました。
影響: セッションおよびトークンが攻撃者のオリジンに漏洩し、認証済みユーザのセッションを乗っ取られるおそれがあります（CVSS 5.4）。
開示経路: TrendAI™ Zero Day Initiative™（ZDI）が、標準の責任ある開示プロセスに基づいてDifyへの報告を調整しました。本件はZDI-26-452（CVE-2026-18266）として管理されています。

修正内容：リダイレクト検証を一元化する大規模改修

Difyは局所的なパッチではなく、36ファイル・約1,850行に及ぶ大規模な改修（PR #38864、feat/login-redirect-security）を実施しました。主な内容は以下のとおりです。

すべての認証エントリポイント（標準サインイン、SSO、メール＋コード認証、埋め込み型webappサインイン、招待フロー、トークンリフレッシュ）で使用される、リダイレクト検証の一元化ユーティリティ（login-redirect.ts）の新設。
オープンリダイレクトのバイパス手法として最も一般的な、プロトコル相対形式（//）およびバックスラッシュ形式（/\）のリダイレクト先の明示的な拒否。
二重・三重にURLエンコードされたペイロードを検出する再帰的なデコード処理。
認証情報を埋め込んだホスト（user@evil.com のようなトリック）の拒否。
絶対URLのリダイレクト先に対する許可リスト方式の導入。dify.aiおよび*.dify.aiのみを、HTTPSかつデフォルトポートに限って許可し、それ以外はすべて安全なデフォルトにフォールバックします。
リダイレクトセキュリティのリグレッションを今後カバーする、新しいエンドツーエンドテストスイート（e2e/features/auth/redirect-security.feature）。

開示までの経緯：報告から公開修正まで

報告は約4か月をかけて、非公開の開示から公開修正へと進みました。主な日付は以下のとおりです。

2026年3月25日：TrendAI™ ResearchがオープンリダイレクトをTrendAI™ ZDIに報告し、追跡ID「ZDI-CAN-29196」が割り当てられました。
2026年3月25日：ZDIが同日中にDifyへ通知し、標準の責任ある開示期間が始まりました。
2026年7月13日：Difyが修正（PR #38864）をGitHub上で公開の形でマージしました。マージ時点では、CVE、GHSAアドバイザリ、クレジットのいずれも発行されていませんでした。
2026年7月23日：ZDIの120日間の開示期限が到来しました。この時点以降、ZDIはベンダーの対応状況にかかわらずアドバイザリを公開できます。
2026年7月29日：ZDIがアドバイザリ（ZDI-26-452）を公開し、CVE-2026-18266が割り当てられました（CVSS 5.4、CWE-601 オープンリダイレクト）。

Difyにとどまらない意味

本件は、TrendAI™ Researchが「TrendAI™ AIセキュリティレポート2026 ～AIエコシステムの断層～」で詳しく報告した、より大きなパターンに合致します。同レポートの分析では、330,239件のCVEを対象として、2018年から2025年の間に開示されたAIシステムに影響する固有の脆弱性6,086件を特定しました。うち2,130件は2025年の1年間だけで開示されたもので、前年比34.6%の増加です。これは、CVE全体の開示件数の増加率17.9%の2倍近い伸びにあたります。予測では、2026年はさらに2,800〜3,600件のAI関連CVEが開示されるペースで推移しています。

このデータセットの中で本件に直接関係するのが「LLMツール・アプリケーション」カテゴリです。これは、ChatGPT登場以降に爆発的に増えたRAG・エージェント・チャットボット構築プラットフォーム群（Difyのほか、Langflow、vLLM、AnythingLLMなど）を指す本リサーチ上の分類で、追跡対象全体の20.4%にあたる1,243件のCVEを占めています。このカテゴリで支配的なバグの種類は、メインストリームのWebアプリケーションで長年見られてきたものと同じ、コードインジェクション、SSRF、パストラバーサルです。今回のDifyの発見は、このリストに4つ目となる「オープンリダイレクトとログイン後フローの堅牢化」を加えるものです。同時に、同レポートの中心的な主張、すなわち、この分野では機能開発の速度がセキュリティレビューの成熟度を上回っているため、成熟したフレームワークが10年前に解決したWebセキュリティの基本をこれらのプラットフォームが再発見（そして再修正）し続けている、という指摘を改めて裏付けるものでもあります。

また、Difyがセキュリティ研究の対象として取り上げられるのは、今年に入ってこれが初めてではありません。2月には別の研究者が、Difyのログインエンドポイントにおけるユーザ列挙の欠陥（GHSA-9qpf-wcv3-w3qx）を開示しました。6月にはZafran Securityの「DifyTap」リサーチが、Difyのトレーシング、プラグインデーモン、ファイルアクセスの各サブシステムに4件の脆弱性（うち2件はクリティカル）を開示し、Difyのマルチテナント型クラウドでテナント間のデータ漏洩が可能になることを示しました（CVE-2026-41947〜41950）。本リサーチの発見は、2026年に開示されたDifyに関するセキュリティ研究としては3件目にあたり、DifyTapとの対比という点でも示唆に富みます。Zafranの発見が、Difyのマルチテナント型SaaSの構造に固有のアーキテクチャレベルのテナント分離の不備だったのに対し、本件は、完全にセルフホストされたシングルテナント環境でも存在しうる古典的な認証の欠陥です。両者を合わせれば、インフラレベルの分離バグからアプリケーションレベルの認証バグまで、プラットフォームのアタックサーフェスのほぼ全体像が、同じ半年間のうちに明らかになったことになります。

本件は、AIツールスタック全体でこの種の問題を追跡してきたチームの幅広い調査活動の延長線上にも位置づけられます。MCPサーバに関するリサーチでは、クライアント認証も通信の暗号化もまったくない、認証なしの公開状態が増加傾向にあることが判明しています。また、今年ZDIが調整した開示だけでも、LiteLLM（6月に報告されたCVSS 8.8の事例を含む）、mcp-kubernetes-server（CVSS 9.8）、そして今回のDifyに及びます。プロジェクトは異なっても、根底にある構図は同じです。急速に開発され広く採用されているAIインフラが、その土台となることの多いフレームワークが備えるセキュリティレビューの厳格さに達しないまま、リリースされ続けているのです。

Dify運用者への推奨事項

Difyを運用している組織は、以下の対応によって本脆弱性を塞ぎ、修正前に悪用されていなかったかを確認できます。

PR #38864のリダイレクト検証改修を含むDify v1.16.0以降にアップグレードしてください。影響を受けるすべての認証エントリポイントで欠陥を根本から塞ぐことができるため、これが最も効果的な対策です。
カスタムのリバースプロキシを経由してセルフホストしている場合は、未検証のリダイレクトパラメータを外部の宛先へ転送していないか、プロキシの設定を確認してください。パラメータをそのまま通すプロキシがあると、アプリケーション側を修正しても同じオープンリダイレクトの挙動が再発するおそれがあります。
あわせて、認証ログとリダイレクトログに悪用の兆候がないかを確認してください。見覚えのない外部ドメインへのログイン後リダイレクトや、サイト外を指す想定外のoauth_redirect_url値などが手がかりになります。

参考記事

How TrendAI™ Research Helped Close an Open Redirect in Dify's Post-Login Flow

By David Fiser, Alfredo Oliveira

翻訳：与那城務（Platform Marketing, TrendAI Research）