LLMアプリ開発基盤Difyに複数のクリティカル脆弱性、CVE-2026-41948/41947でテナント越境のリスク

「社内でDifyを使ってLLMアプリを作っているけど、安全に運用できているの？」
「テナント越境って、他社の会話が見えちゃうってこと？」

チップス

ボス、DifyってLLMアプリの開発基盤でしゅよね？ そこにクリティカルな脆弱性が出たって本当でしゅか？

ボス

うむ、5月19日に2件公表された。CVE-2026-41948のパストラバーサルと、CVE-2026-41947の認可バイパスだ。

本記事ではLLMアプリ開発基盤「Dify」に判明した2件の脆弱性を整理し、テナント越境がもたらすリスクと優先対応を解説します。
マルチテナントでLLMサービスを運用する企業にとって、見過ごせない事案です。

続きを読めば、Difyを社内導入している組織が今すぐ確認すべき点と、マルチテナント設計の落とし穴が見えてきます。

2件の脆弱性が示すマルチテナントの脆さ

どちらの脆弱性も、本来テナント単位で隔離されるべき情報や操作が越境してしまう構造的な問題です。
LLMサービス特有のリスクが顕在化したケースとして注目されます。

CVE-2026-41948：Pluginデーモンのパストラバーサル

PluginデーモンのREST APIで、転送リクエストの操作が可能となるパストラバーサル脆弱性です。
テナントUUIDを把握している攻撃者が、タスク識別子やファイル名を細工することで、本来公開されない内部エンドポイントへアクセスできます。
テナント分離が前提のSaaS型運用では、テナントUUIDの漏洩自体が即座に攻撃成立条件になり得る点が深刻です。

2件の脆弱性の概要は次のとおりです。

CVE-2026-41947：会話ログが第三者に流れる

編集者権限レベルで、トレース設定エンドポイントにおけるテナント所有権の確認に不備があります。
他テナントのアプリケーションのトレース設定を変更でき、LLMとのメッセージが第三者のLLMトレースプロバイダに転送される構造です。
顧客との対話履歴や社内向けFAQの問い合わせ内容など、機密性の高い文字列がそのまま外部に流出するシナリオが現実に存在します。

チップス

会話の内容がまるごと外に流れるって、業務利用だとかなり怖いでしゅ…

ボス

うむ、社内ヘルプデスクや顧客対応に組み込んでいると、個人情報や契約情報まで漏れかねない。

Dify運用者が今やるべき防御

セルフホスト型のLLM基盤は、便利な反面、運用責任が利用者側に強くのしかかります。
今回の脆弱性を機に、運用体制を見直すきっかけにしましょう。

最新版へのアップデートとログ点検

Dify 1.14.1以前を運用している場合は、まず最新版へのアップデートを最優先で進める必要があります。
同時に、トレース設定エンドポイントへの過去アクセスログを点検し、不審なテナント間操作の痕跡がないか確認するべきです。
LLMトレース転送先（Langfuse、LangSmithなど）の設定が改ざんされていないかも、テナントごとに確認するのが安全です。

当面の対応事項を整理します。

LLM基盤特有のサプライチェーン視点

LLMアプリの開発基盤は、外部のLLM API・ベクターデータベース・トレース基盤など複数の外部サービスと密結合しています。
今回のように設定の改ざんで「正規の外部サービス」に情報を流す経路を作れば、検知が極めて難しくなります。
ログ収集対象を社内資産だけでなく、SaaS連携先の設定変更履歴まで広げる発想が求められる時代に入っています。

チップス

外部のLLMトレースサービスまで監視するって、結構大変でしゅね…

ボス

うむ、しかしAI時代のセキュリティは、自社の境界の外にも視野を広げる必要がある。

まとめ：LLM基盤も「テナント分離」を疑え

マルチテナント型LLM基盤は、ひとつの設計ミスが全顧客に波及します。
Dify利用者が押さえるべきポイントを整理します。

チップス

テナントUUIDも秘密扱いにしなきゃダメなんでしゅね。勉強になりまし​た！

ボス

うむ、設計時の「公開してよい識別子」と「内部のみで使う識別子」を分けて考える癖をつけよ。

詳しい情報はSecurity NEXTの報道とDify公式のセキュリティアドバイザリを参照してください。