MLflow脆弱性が悪用中、クラウド認証情報が標的

米CISAが2026年8月19日、機械学習基盤「MLflow」の脆弱性 CVE-2026-64849 を「悪用が確認された脆弱性カタログ（KEV）」に追加しました。認証なしでMLflowサーバを踏み台にし、クラウドのメタデータサービスから認証情報を読み出せる深刻な欠陥です（CVSS 3.1 基本値 9.3・緊急）。修正版は 3.15.0 で、すでに 2026年7月31日に公開されています。

データサイエンスチームが社内に立てたMLflowサーバは、情シスの資産台帳に載っていないことが少なくありません。今すぐ確認すべきは「社内にMLflowが動いていないか」「そのバージョンは 3.15.0 以上か」の2点です。

この記事でわかること

  • MLflowとは何をするもので、どこで動いているのか
  • CVE-2026-64849 で何が起き、なぜ「未認証」で成立してしまうのか
  • 影響を受けるバージョンと、修正版・公表のタイムライン
  • 自社に該当するかを現場で確認する具体的な手順
  • すぐに更新できない場合の緩和策と、参照すべき公的指針

MLflowとは何者か — 「うちは使っていない」と即断しないために

MLflowとは、機械学習・生成AIの実験結果やモデルを記録・管理するためのオープンソースのプラットフォームです。Databricks社が開発を始め、現在はLinux Foundation傘下のプロジェクトとして開発が続いています。

使うのは主に、社内のデータサイエンスチームやAI開発チームです。「どのデータとパラメータで学習させたら精度がいくつだったか」を実験ごとに記録し（Tracking）、良かったモデルに版番号を付けて管理する（Model Registry）用途で導入されます。最近は生成AIアプリの動作トレースの記録にも使われています。

問題はどこで動いているかです。MLflowは pip install mlflow で入り、mlflow server の一行でトラッキングサーバが起動します。この手軽さゆえに、以下のような形で「情シスが把握していないMLflow」が社内に存在しがちです。

  • データサイエンスチームが自前で立てたサーバ：GPUサーバや検証用のクラウドVM上に、申請なしで立ち上がっているケース。
  • クラウドのマネージドサービスの中身：Amazon SageMaker AI は「フルマネージドMLflow」としてMLflowそのものをホストしています（AWSの公式ドキュメントでは、トラッキングサーバとして MLflow 3.0 / 2.16 / 2.13、MLflow App として 3.10 が案内されています）。
  • 他のMLツールの依存パッケージ：MLパイプラインのテンプレートやサンプルコードが、既定でMLflowを一緒に入れることがあります。

なお、マネージドサービス側の修正適用はクラウド事業者の更新方針に従います。本記事で扱うのは、自組織で mlflow server を動かしている「セルフホスト」の構成です。マネージド版を使っている場合は、各事業者の告知を確認してください。

何が起きたのか

MLflowのモデルレジストリには「Webhook」機能があります。モデルが登録されたときなどに、指定したURLへHTTPで通知を飛ばす仕組みです。この機能には、通知先URLが正しく届くかを試す POST /api/2.0/mlflow/webhooks/{id}/test というエンドポイントが用意されており、試行先から返ってきたHTTPステータスとレスポンス本文を、そのまま呼び出し元に返します。

ここが攻撃に使われました。GitHub Security Advisory（GHSA-7gwp-5pfp-969j）に記載された流れは次のとおりです。

  1. 攻撃者が、公開IPを持つ自分のHTTPSサーバを用意する（これはMLflow側の検証を通過する）。
  2. そのURLを指すWebhookを、認証なしでMLflowサーバに登録する。
  3. /test エンドポイントを叩く。MLflowが攻撃者のサーバへ接続すると、302 Location: http://169.254.169.254/... というリダイレクトが返る。
  4. MLflowはリダイレクトをそのまま追いかけ、転送先を再検証しない。結果、クラウドのインスタンスメタデータサービス（IMDS）の応答が、そのまま攻撃者に返る。

MLflowにもSSRF対策のガード（_validate_webhook_url、3.10.0で導入）はありました。登録されたURLのホスト名を名前解決し、プライベートIPやループバック、リンクローカルであれば弾く実装です。しかし検証した時点のIPアドレスを実際の接続に固定（ピン留め）していなかったため、リダイレクト追跡とDNSリバインディングの両方ですり抜けられました。「入口だけチェックして、その後を見ていない」という典型的な検証漏れです。

どのくらい速く悪用されたのですか

CVEが採番された当日のうちに、探索が始まっていました。採番とGitHub Advisoryの公開はいずれも2026年8月17日です。セキュリティ企業watchTowrは、同社のハニーポット網でCVE採番から数時間のうちにクラウド上のMLflowを狙う探索を観測したと公表しました。CISAがKEVに追加したのは、その2日後の8月19日です。

なお、KEVカタログ上でランサムウェアキャンペーンでの利用有無は「Unknown（不明）」とされています。現時点で報じられているのは、探索とクラウド認証情報の窃取を狙う動きです。

影響を受ける環境

項目 内容
CVE番号 CVE-2026-64849
対象 MLflow（pipパッケージ mlflow）
影響バージョン 3.15.0 より前
修正版 3.15.0（2026年7月31日公開）／最新は 3.15.1（2026年8月3日）
CVSS 3.1 基本値 9.3（緊急）
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N
脆弱性種別 CWE-918（サーバサイドリクエストフォージェリ／SSRF）
攻撃条件 ネットワーク到達性のみ。認証・利用者操作ともに不要
KEV登録日／対応期限 2026年8月19日／2026年9月2日（米国連邦機関向け）

成立の前提は「MLflowサーバに認証が掛かっていないこと」です。MLflowのトラッキングサーバは、既定では認証がありません。ユーザー名／パスワードによる基本認証はオプション機能で、mlflow server --app-name basic-auth のように明示的に有効化する必要があります。Advisoryも「既定構成のMLflowサーバ（mlflow server、認証なし、既定のSQLiteバックエンド）」を前提として記述しています。

裏を返せば、認証プラグインを有効にしている環境ではWebhook APIの呼び出しに認可が掛かるため、未認証での悪用は成立しません。とはいえ、社内ネットワーク内での使用を前提に認証なしで運用している例は多いはずです。

自社に該当するか、どう確認するか

資産台帳に「MLflow」と書かれていない可能性が高いので、実地で探すのが確実です。

1. 動いているMLflowを探す

  • 既定のポートは 5000。社内ネットワークとクラウドのVPCに対し、5000番でHTTPが応答するホストを洗い出す。
  • ブラウザでアクセスするとMLflowのUI（実験一覧の画面）が表示されるので、それで判別できる。
  • クラウド側では、セキュリティグループ／ネットワークセキュリティグループで5000番がインターネットに開いていないかを最優先で確認する。

2. バージョンを確認する

  • サーバ上で pip show mlflow もしくは mlflow --version。3.15.0 未満なら更新対象。
  • コンテナで動かしている場合は、イメージのタグではなくコンテナ内のパッケージ版を見る（タグが実体とずれていることがある）。

3. 該当機能が生きているか確認する

  • Webhook APIは比較的新しい機能で、3系に入っています（実装のマージは2025年夏）。/api/2.0/mlflow/webhooks が応答するかどうかで、該当機能の有無を実地で判定できます。
  • 認証の有無も同時に確認する。認証なしでAPIが応答するなら、そのサーバは優先度が高いと判断してよいでしょう。

4. 侵害の痕跡を探す

  • MLflowサーバのアクセスログに、/api/2.0/mlflow/webhooks への身に覚えのないPOSTがないか。
  • 登録済みWebhookの一覧に、知らないURLが混じっていないか。
  • クラウド側の監査ログ（AWS CloudTrail等）で、そのインスタンスのIAMロールが普段と違うAPIを呼んでいないか。認証情報が抜かれていれば、外部IPからの利用として記録される可能性があります。

現場目線の課題 — 「知らないサーバ」をどう守るか

正直なところ、この種の脆弱性がいちばん厄介なのは、技術的な難しさではなく「その存在を情シスが知らない」点にあります。

MLflowは、データサイエンティストにとっては「実験ノート」に近い道具です。手元で mlflow server と打てば動いてしまうので、悪意なく、申請という発想すら持たずに立ち上がります。しかもGPUサーバやクラウドの検証環境は、予算を別の部署が持っていることも多い。結果として、強い権限のIAMロールが付いたクラウドVMの上で、認証なしのWebアプリが動いているという構図ができあがります。

今回の攻撃が狙ったのは、まさにその構図です。MLflow自体を壊すのではなく、MLflowが乗っているクラウドインスタンスの権限を盗む。被害の本体はMLflowの外側にあります。実験データが多少見られること以上に、そのロールでS3やKMSに何ができるかのほうが深刻です。

同じ形の問題は、AI・機械学習の周辺で繰り返し起きています。分散処理基盤Rayの脆弱性も、ワークフロー基盤Apache Airflowの脆弱性も、根っこは「開発チームが自由に立てた基盤が、内部利用の前提のまま外を向いている」ことでした。関連記事もあわせてご確認ください。

情シスはどうすべきか

最優先はMLflowを 3.15.0 以上に更新することです。修正はすでに公開されており、更新以外に根本的な解決はありません。そのうえで、すぐに更新できない場合の緩和策を挙げます。

  • ネットワークで閉じる：MLflowサーバをインターネットから切り離し、必要な開発者のセグメント／VPNからのみ到達可能にする。これは更新後も続けるべき恒久対策です。
  • 認証を掛ける：MLflowの基本認証を有効にするか、認証付きのリバースプロキシを前段に置く。
  • リバースプロキシで該当パスを遮断する：/api/2.0/mlflow/webhooks 配下へのアクセスを拒否する。Webhookを使っていない環境なら副作用は小さいはずです。
  • IMDSv2を必須にする（AWSの場合）：IMDSv2はメタデータ取得の前に PUT でセッショントークンを取得し、それをヘッダに載せる方式です。今回のような「POSTのリダイレクトを追わせて読み出す」攻撃はトークンを取得できないため、成立しにくくなります。AWS自身もIMDSv2をSSRF対策の多層防御として位置づけています。ただし万能ではないため、更新の代替にはしないでください。
  • 権限を絞る：MLflowサーバに付与しているIAMロールの権限を、必要最小限（成果物用のストレージへの読み書き程度）まで削る。奪われた前提で被害範囲を縮める考え方です。

どこから手を付ければよいですか

まず「インターネットに露出しているMLflowを止める・閉じる」ことです。更新作業より先に、外向きの到達性を断つほうが速く効きます。悪用はすでに始まっており、探索は自動化されているためです。

組織全体の底上げには公的指針を使う

個別の脆弱性対応と並行して、「勝手に立ったサーバ」を減らす取り組みが必要です。自前でチェックリストを作り込むより、公的機関の指針を土台にしたほうが社内への説明も通しやすくなります。

あわせて、開発チームに対しては「検証用でも社外に出さない」「認証を切ったまま放置しない」という地道な周知が効きます。禁止するより、安全に立てられる手順（認証付きのテンプレート、社内向けのプロキシ）を情シス側から提供するほうが定着しやすいでしょう。

中長期の視点

AI開発基盤の脆弱性は、今後も同じ形で出続けると考えたほうが現実的です。急速に機能追加が進むOSSでは、Webhookのような外部連携機能が短期間で入り、検証が追いつかないことがあります。今回のケースも、SSRFガード自体は導入されていたのに、リダイレクト追跡という抜け道が残っていました。

情シスとしては、個々のCVEを追うだけでなく、「AI・データ基盤も通常のIT資産として棚卸しの対象に含める」という運用の変更が必要になります。棚卸しの対象外にしている限り、次の脆弱性でも同じ後手を踏むことになります。

まとめ

  1. CVE-2026-64849は、MLflowの未認証SSRF（CVSS 9.3）。認証不要でクラウドのメタデータサービスを読み出され、認証情報を盗まれる恐れがあります。2026年8月19日にCISAのKEVへ登録され、悪用がすでに確認されています。
  2. 対処は 3.15.0 以上への更新。修正版は7月31日に公開済みです。すぐに更新できない場合は、インターネットからの到達性を断ち、Webhook APIのパスを遮断してください。
  3. まず「社内にMLflowがあるか」を探すこと。データサイエンスチームが立てたサーバは資産台帳にないことが多く、そこに強い権限のIAMロールが付いている構図が最大のリスクです。

出典

タイトルとURLをコピーしました