Dify Enterprise 3.9.13がAnyIOの修正を取り込み、デプロイ時にはイメージの差異を確認

Difyは9月23日、Enterprise 3.9.13をリリースし、コミュニティ版のLTSブランチにおける依存パッケージの修正を企業向けデプロイに取り込んだ。新版ではAPIイメージ内のAnyIOを4.11.0から4.14.2に引き上げ、ベースイメージも更新した。公式によると、今回はデータベースのマイグレーションや機能変更はない。RAGやエージェントのワークフローを運用するチームにとって、焦点は既存の接続とバックグラウンドジョブの安全性にある。[リリースノート](https://ee.dify.ai/releases/v3.9.13/)

AnyIOのTLS脆弱性は国際化ドメイン名に関わる。一部の接続経路ではIDNA 2003エンコーディングが使われており、別のドメインの正規の証明書が検証を通過する可能性がある。ただし、攻撃が成立するには、接続があらかじめ別の手段で乗っ取られるか、悪意あるサーバーに誘導されている必要がある。これは基盤となるライブラリでの成立条件であり、現時点のアドバイザリは、すべてのDifyワークフローでこの問題が発生し得ることを実証しておらず、Difyでの悪用事例も示していない。[メンテナーのアドバイザリ](https://github.com/agronholm/anyio/security/advisories/GHSA-82r6-8w77-94w6)

同じアップグレードで対処したもう一つの問題は、プロセスプールのブロッキングだ。旧版ではワーカープロセスの標準エラー出力をパイプに接続していたものの、継続的に読み取っていなかった。プログラムが大量に出力するとパイプがいっぱいになり、結果を待つ呼び出しがブロックされたままになる可能性があった。上流プロジェクトが説明しているのは可用性のリスクであり、デプロイ担当者は「パッケージのバージョンが影響を受けること」と「アプリケーションが実際にその実行経路を通ること」を区別すべきだ。[プロセスプールの脆弱性に関する説明](https://github.com/agronholm/anyio/security/advisories/GHSA-5p39-cfhj-2xmp)

デプロイの検証という観点では、この二つの修正はそれぞれ、接続先の信頼性と、バックグラウンドジョブが正常に結果を返せるかに関わる。チームはまず、国際化ドメインにアクセスするツールと、プロセスプールを使うタスクを洗い出し、そのうえでコンテナ内の実際の依存パッケージのバージョンを照合するとよい。これは上流プロジェクトが示した発生条件に基づく確認方針だ。モデルが正常に応答したり、一般的な対話テストに合格したりするだけでは、これらの経路が検証対象に含まれていることを確認するには不十分だ。

フロントエンドもNext.js 16.3.6に更新された。公開されているDifyのコミットでは、パッケージの宣言とロックファイルが併せて変更されており、ビルド内容を照合する根拠となる。企業版とコミュニティ版ではバージョン番号が異なるため、今回の更新を、コミュニティ版のすべてのデプロイで修正が完了したという意味に捉えてはならない。[LTSのコミット](https://github.com/langgenius/dify/commit/75bbcffec01362d7a727758ebc21ee0b490d38d6)

公式のスキャンによると、デフォルトのイメージ構成ではCriticalレベルの項目がなくなった一方、高リスクの検出項目は残っている。オプションのapi-insecureイメージは別集計となる。ChromaDB、W&B tracing、ClickZettaは引き続きデフォルトのAPIイメージから除外されており、この制限は前版から継続している。技術面では、実際に使用するイメージ、仮想環境内のパッケージ、連携要件を照合し、未修正のnltkの問題も追跡すべきだ。APIスキャンの詳細にはベースイメージのパッケージも含まれるため、そのパッケージがアプリケーションの実行環境に含まれるかも判断する必要がある。脆弱性の総数だけで悪用可能性を判断することはできない。[リリースのリスクに関する説明](https://ee.dify.ai/releases/v3.9.13/)、[APIスキャンの詳細](https://ee.dify.ai/reports/v3.9.13/scout/api/)