MLflowのCVE-2026-64849をCISAがKEV追加:認証不要SSRFを実悪用、クラウド認証情報を狙う攻撃

オープンソースのAI・機械学習基盤「MLflow」に存在するサーバーサイドリクエストフォージェリ(Server-Side Request Forgery:SSRF)の脆弱性CVE-2026-64849が、実際の攻撃で悪用されています。

MLflowのGitHub Security Advisoryによると、CVE-2026-64849は認証なしで悪用可能な「full-read SSRF」です。攻撃者がMLflow Tracking Serverへ到達できる場合、本来は外部から直接アクセスできない内部サービスやクラウドのメタデータサービスへMLflowサーバー自身にアクセスさせ、その応答内容を取得できる可能性があります。

セキュリティ企業watchTowrは、CVE番号が割り当てられてから数時間以内に、インターネットへ公開されたMLflow環境を狙う無差別なスキャンと悪用を観測したと公表しました。同社によると、攻撃ではクラウドのメタデータサービスへアクセスし、クラウド認証情報やシークレットを取得しようとする動きが確認されています。

さらに米国サイバーセキュリティ・社会基盤安全保障庁(Cybersecurity and Infrastructure Security Agency:CISA)は2026年8月19日、CVE-2026-64849を既知の悪用が確認された脆弱性カタログ(Known Exploited Vulnerabilities:KEV)へ追加しました。CISAが設定した対応期限は9月2日です。

影響を受けるのはMLflow 3.15.0未満で、修正版は3.15.0です。共通脆弱性評価システム(Common Vulnerability Scoring System:CVSS) v3.1の基本値は9.3(Critical)で、認証不要、利用者操作不要のネットワーク攻撃として評価されています。

CVE-2026-64849の概要

米国国立脆弱性データベース(National Vulnerability Database:NVD)では、CVE番号付与機関(CVE Numbering Authority:CNA)であるGitHubの評価としてCVSS v3.1 9.3(Critical)を掲載しています。ベクトルはAV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:Nです。

これはネットワーク経由、攻撃複雑性が低く、事前権限も利用者操作も不要であることを意味します。また、脆弱なMLflowから別のセキュリティ境界にある内部サービスやクラウド資産へ影響が波及するため、スコープ変更(S:C)として評価されています。

MLflowとは何か

MLflowは、機械学習や生成AIを含むAI開発ライフサイクルを管理するオープンソースのプラットフォームです。実験結果の記録、モデル管理、評価、デプロイなど、機械学習システムの開発から運用までを支援します。

その中心的なコンポーネントの1つがMLflow Tracking Serverです。開発者や機械学習基盤から実験データ、モデル、メトリクスなどを受け取り、Web UIやアプリケーションプログラミングインターフェース(Application Programming Interface:API)を通じて管理できるようにします。

企業や研究組織では、Tracking Serverがクラウド環境やコンテナ基盤、内部ネットワーク上に配置されることがあります。そのため、MLflowそのものに保存されたデータだけでなく、同じ環境に存在するクラウドサービスや内部APIへどの程度アクセスできるかが、侵害時の影響を大きく左右します。

CVE-2026-64849が特に危険なのは、MLflowのサーバーを「踏み台」のように利用し、外部から直接到達できない内部のHTTPサービスへリクエストを送れる点です。

認証不要の「full-read SSRF」

SSRFは、攻撃者が脆弱なサーバーへURLなどを渡し、そのサーバー自身に別のシステムへアクセスさせる脆弱性です。

一般的なSSRFでは「内部サービスへリクエストを送れたかどうか」だけが分かり、応答内容までは攻撃者へ返らない場合があります。このようなケースはblind SSRFと呼ばれることがあります。

CVE-2026-64849はそれより危険で、MLflowのGitHub Security Advisoryは「unauthenticated full-read SSRF」と説明しています。

問題となるウェブフック(Webhook)のテスト処理では、MLflowが接続先から受け取ったHTTPステータスやレスポンス本文を呼び出し元へ返します。そのため、SSRFによって内部サービスへ到達できるだけでなく、取得した内容を攻撃者側が読み取れる可能性があります。

本記事では、攻撃を再現できる具体的なAPIパス、HTTPリクエスト、リダイレクト設定、クラウドメタデータへの具体的なアクセス先などは掲載しません。

既存のSSRF対策を回避できた

今回の問題は「MLflowにSSRF対策が存在しなかった」という単純な脆弱性ではありません。

MLflowには以前から、Webhookの接続先を検証し、ローカルアドレスやプライベートアドレスなどへのアクセスを拒否するSSRF対策が導入されていました。

GitHub Security Advisoryによると、問題はその検証結果が実際の通信先へ確実に固定されていなかったことです。最初に検証したURLが安全でも、その後のHTTPリダイレクトや名前解決の変化によって別の宛先へ接続できる余地が残っていました。

つまり、「最初に見た接続先は安全だった」という確認と、「実際に接続した相手も安全だった」という確認が分離していました。

このため、攻撃者が制御する公開サーバーをいったん安全な宛先として通過させ、その後に内部システムへ通信先を変化させることで、従来の検証を回避できる可能性がありました。

この仕組みは、HTTPリダイレクトに加え、名前解決結果が時間差で変化するDNS再結合(DNS rebinding)と呼ばれる手法にも関係します。ただし本記事では再現手順や具体的な構成方法は扱いません。

クラウド環境で特に危険な理由

クラウド上の仮想マシンやコンテナ環境では、外部インターネットから直接アクセスできない内部向けのメタデータサービスが利用されることがあります。

こうしたサービスは、インスタンス自身が利用する設定情報や、一時的なクラウド認証情報などを提供する場合があります。

通常、インターネット上の第三者はこの内部サービスへ直接アクセスできません。しかしSSRFが成立すると、外部の攻撃者が脆弱なMLflowサーバーを介して内部側からアクセスさせる可能性があります。

さらにCVE-2026-64849はfull-read SSRFであるため、MLflowが取得した応答内容まで攻撃者側へ返る可能性があります。GitHub Security Advisoryは影響例として、クラウドインスタンスのメタデータ、内部限定の管理サービス、内部ホストやポートの探索を挙げています。

watchTowrは実際の攻撃観測について、攻撃者がクラウドのメタデータサービスへ到達し、クラウド認証情報やシークレットを外部へ取得しようとしていたと説明しています。

したがって、MLflowに機密情報を直接保存していない環境でも、「MLflowサーバーがネットワーク的に何へアクセスできるか」を確認する必要があります。

watchTowrがCVE公開直後の実悪用を観測

watchTowrは8月18日、CVE-2026-64849の実悪用を観測していると公表しました。

同社のグローバルハニーポットネットワーク「Attacker Eye」では、CVE-2026-64849の公表直後から数時間以内に、公開されたMLflow環境を無差別に探索する活動を確認したとしています。

watchTowrによると、確認された活動にはクラウド上のMLflowを対象とし、内部のメタデータサービスから認証情報やシークレットを取得しようとするものが含まれていました。

ここで情報源を区別することが重要です。具体的なクラウド認証情報窃取の観測はwatchTowrによる脅威インテリジェンスです。一方、翌8月19日にCISAがKEVへ登録したことで、「CVE-2026-64849が実際に悪用されている」という点については米政府機関からも確認された形になります。

ただしCISAのKEV登録は、攻撃者の具体的なグループ名、被害組織数、侵害されたクラウドアカウント数などを示すものではありません。

CISAが8月19日にKEVへ追加

CISAは2026年8月19日、CVE-2026-64849をKEVへ追加しました。同日付のCISA公式発表では、新たに追加した1件として「MLflow Server-Side Request Forgery Vulnerability」を挙げています。

KEVは、単にCVSSが高い脆弱性を収録する一覧ではなく、実際の攻撃で悪用されていることをCISAが確認した脆弱性をまとめたカタログです。

CVE-2026-64849の追加日は8月19日、対応期限は9月2日です。

NVDのKEV欄では、ベンダーの指示に従って緩和策を適用し、拘束的運用指令(Binding Operational Directive:BOD) 26-04とCISAのフォレンジックトリアージ要件へ従うよう記載されています。

BOD 26-04は米国連邦政府機関向けの指令であり、日本企業や一般の民間企業へそのまま法的義務として適用されるものではありません。しかし、実悪用が確認されたCritical脆弱性であるため、通常の月次メンテナンスまで待つのではなく優先的に対応する根拠になります。

影響を受けるバージョンと修正版

GitHub Security AdvisoryとNVDによると、影響を受けるのはMLflow 3.15.0未満です。

GitHub Security Advisoryでは3.13.0でも脆弱性が確認されており、問題は3.15.0で修正されています。

修正では、接続時に実際の通信相手のIPアドレスを確認する仕組みが追加されました。これにより、最初のURL検証を通過した後にリダイレクトや名前解決の変化によって内部アドレスへ接続する経路を遮断します。

重要なのは「URLを一度確認する」のではなく、「実際に接続するたびに通信先を検証する」ようになったことです。

インターネット公開しているMLflowは優先度を上げる

今回の実悪用で最も優先度が高いのは、MLflow Tracking Serverへインターネットから到達可能な環境です。

デフォルト構成ではWebhook関連機能の一部が認証なしで利用できるため、「管理者用のMLflowだから一般ユーザーはログインできない」という認識だけでは十分ではありません。

リバースプロキシ、ロードバランサー、KubernetesのIngress、クラウドのセキュリティグループなどを経由して、Tracking Serverが外部から到達できる状態になっていないか確認してください。

また、社内ネットワーク限定の場合でも更新は必要です。すでに侵害された端末や別のシステムから内部ネットワークへアクセスできる攻撃者が存在する場合、内部向けMLflowが次の侵害経路になる可能性があります。

パッチだけでなく認証情報漏えいの確認も必要

watchTowrが観測した攻撃は、クラウドメタデータから認証情報やシークレットを取得することを目的としていました。

そのため、インターネット公開していた脆弱なMLflowを3.15.0へ更新しただけで対応を終了するのは不十分な場合があります。

修正前に外部公開していた環境では、MLflowやリバースプロキシのアクセスログ、クラウド監査ログ、異常なAPI利用、想定外の認証情報使用などを確認してください。

クラウド環境で一時認証情報やシークレットが取得された可能性がある場合は、影響範囲を確認したうえで認証情報の失効やローテーションを検討します。

特にMLflowを動かすインスタンスやコンテナへ広いクラウド権限を付与している環境では、SSRFから取得された認証情報の権限範囲がそのまま被害の大きさにつながる可能性があります。

MLflowサーバーの権限を見直す

今回の脆弱性は、アプリケーションの脆弱性だけでなく、クラウド権限設計の重要性も示しています。

MLflowを実行する仮想マシンやコンテナへ、業務上必要以上に強い権限を持つロールやサービスアカウントを割り当てていると、認証情報が取得された場合の影響が大きくなります。

そのため、パッチ適用と並行して最小権限の原則に基づき、MLflowが本当に必要とするクラウドAPIだけへアクセスできる状態になっているか確認してください。

また、MLflowサーバーから内部管理サービスやメタデータサービスへの通信をネットワークレベルで制御できる場合は、不要なアウトバウンド通信を制限することも多層防御として有効です。

ただし、ネットワーク制限や認証追加は3.15.0へのアップデートの代替ではありません。脆弱性そのものを修正することが最優先です。

管理者が優先して実施すべきこと

1.MLflowのバージョンを確認する

MLflow 3.15.0未満を使用している場合はCVE-2026-64849の影響を受けます。自己管理しているTracking Serverのバージョンを確認してください。

2.MLflow 3.15.0以降へ更新する

GitHub Security Advisoryが示す修正版は3.15.0です。実悪用が確認済みであるため、公開環境では特に優先して更新してください。

3.外部公開状態を確認する

Tracking Serverがインターネットから直接またはリバースプロキシなどを通じて到達可能になっていないか確認します。

4.ログを調査する

修正前に外部公開していた場合は、MLflow、Webプロキシ、クラウド監査ログなどを確認し、不審なWebhook操作や内部サービスへのアクセスにつながる挙動がなかったか調査してください。

5.クラウド認証情報を確認する

侵害の可能性がある場合は、MLflowホストに付与されたクラウドロール、サービスアカウント、取得可能だったシークレットの範囲を確認し、必要に応じて失効・ローテーションしてください。

6.最小権限とネットワーク制御を見直す

MLflowサーバーが不要な内部管理サービスやクラウドAPIへアクセスできないよう、ネットワーク経路とクラウド権限を見直します。

今回のニュースで誤解しやすい点

第一に、CVE-2026-64849は「攻撃可能性が理論上示された」だけの脆弱性ではありません。watchTowrが実悪用を観測し、CISAもKEVへ追加しています。

第二に、CISAが「クラウド認証情報を何件盗まれた」と公表したわけではありません。クラウドメタデータを狙った攻撃と認証情報・シークレット取得の観測はwatchTowrによる情報です。CISAが確認しているのは、このCVEが既知の悪用対象になっていることです。

第三に、SSRFだから影響が軽いとは限りません。今回の脆弱性では内部サービスへ到達するだけでなく、その応答内容まで取得できるfull-read SSRFであることが重要です。

第四に、MLflow自体に重要データを保存していなくても安全とは限りません。MLflowサーバーからクラウドメタデータや内部サービスへアクセスできる場合、それらが攻撃対象になります。

第五に、インターネットへ公開していない環境でも更新は必要です。外部公開環境の方が緊急度は高いものの、内部侵入後の横展開に利用される可能性は残ります。

まとめ

CVE-2026-64849は、MLflowのWebhook処理に存在する認証不要のSSRF脆弱性です。CVSS v3.1は9.3(Critical)で、MLflow 3.15.0未満が影響を受け、3.15.0で修正されています。

この脆弱性では、MLflow Tracking Serverを介して本来外部から到達できない内部サービスやクラウドメタデータへアクセスし、その応答内容まで取得できる可能性があります。

watchTowrはCVE公開直後からインターネット上のMLflowを狙う悪用を観測し、クラウド認証情報やシークレットを狙う活動を報告しました。CISAも8月19日にCVE-2026-64849をKEVへ追加し、対応期限を9月2日に設定しています。

MLflowを自己管理している組織は、まず3.15.0以降へ更新してください。特に修正前にTracking Serverをインターネットへ公開していた場合は、パッチ適用だけでなくログ調査を行い、クラウド認証情報やシークレットが取得された可能性も確認する必要があります。

また、MLflowサーバーへ過剰なクラウド権限を与えないこと、内部サービスへの不要な通信を制限することも重要です。今回の事例は、AI・機械学習基盤そのものがクラウド環境への新たな攻撃経路になり得ることを示しています。

参考情報

• GitHub Security Advisory:GHSA-7gwp-5pfp-969j
• MLflow:Release 3.15.0
• CISA:Adds One Known Exploited Vulnerability to Catalog
• CISA:Known Exploited Vulnerabilities Catalog – CVE-2026-64849
• NVD:CVE-2026-64849
• watchTowr:In-the-wild exploitation of CVE-2026-64849