MLflow の CVE-2026-64849 の脆弱性は、Webhook エンドポイントでの認証チェックの欠如により、重大なセキュリティ上の欠陥を露呈しています。これにより、認証されていないリクエストがサーバーサイドリクエストフォージェリ (SSRF) をトリガーできるようになり、NVD スコアは 9.3 です。この欠陥により、攻撃者は MLflow サーバーに任意の URL をフェッチさせることができ、リダイレクトおよび DNS リバインディング機能により、許可リストのような一般的な緩和策を回避できます。MLflow がデータベース、アーティファクトストア、モデルレジストリの機密性の高い認証情報を格納する中央ハブとしての役割を担っていることから、その影響は深刻です。攻撃者はこの SSRF を悪用して、クラウドメタデータエンドポイント、内部 Kubernetes API、管理アーティファクトストレージ、および Pod ネットワークポートにアクセスできます。重要なのは、攻撃者はトークンまたは署名付き URL を流出させるために、完全なシェルではなく GET リクエストのみを必要とすることです。この CVE を必要としない関連する脆弱性として、MLflow のモデルゲートウェイ構成に API キーが格納される問題があります。攻撃者がゲートウェイ構成を書き込める場合、SSRF なしでこれらのプロバイダーキーを流出させることができます。どちらの問題も、MLflow がシークレットを格納し、認証されていない可能性のあるユーザーに代わってアウトバウンドコールを開始することを示しています。バージョン 3.15.0 へのアップグレードに加えて、組織は MLflow のアウトバウンドネットワークアクセスを制限するために、堅牢な egress ポリシーを実装する必要があります。メタデータアクセスの強化とサービス認証情報の定期的なローテーションも、リスクを軽減するための重要なステップです。疑わしい api_key 参照および api_base 値についてゲートウェイ構成を監査することが不可欠です。最後に、MLflow トラッキングサーバーは内部ツールであるため、シングルサインオンソリューションの背後に配置し、公開しないようにする必要があります。MLflow インスタンスの広範な公開は、多くのチームが機密性の高い認証情報を保持する公開可能な内部ツールのリスクを見落としていることを示しています。