MLflowトラッキングサーバーにおける認証不要のRCE（CVE-2026-116692）

エグゼクティブサマリー（TL;DR）

• CVE-2026-116692は、MLflow自体の機械学習トラッキングサーバーにおけるリモートコード実行（RCE）です。サーバーに到達できるHTTPの呼び出し元であれば誰でも、Pythonモジュールをアップロードし、サーバーにそれをインポートして実行させることができます。デフォルトのデプロイでは認証情報は不要です。GitHubのアドバイザリはこれをCritical、CVSS v3.1 9.8（AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）と評価しています。
• 影響を受けるのはMLflow 3.12.0から3.16.xまでと、リリース候補版3.12.0rc0です。最初の修正版は2026年10月7日にリリースされた3.17.0です。
• このバグはチェーンになっています。サーバーのサードパーティscorerのデシリアライゼーションは、許可リストにあるパッケージのプレフィックスで始まるモジュールパスであれば何でも受け入れます。そしてサーバー自身の実験とアーティファクトのエンドポイントにより、呼び出し元は実験のアーティファクトの保存先をそのようなパッケージに向け、その配下にPythonファイルをアップロードできます。scorerはLLMアプリケーションやエージェントの出力を評価するMLflowの評価関数で、サードパーティscorerはRagas、DeepEval、TruLens、Phoenixなどのライブラリの評価指標をラップしたものです。公式のMLflow v3.14.0イメージではプロセスがrootとして実行されるため、コードはrootとして実行されます。
• 在野での悪用は確認されておらず、このCVEはCISAのKEVカタログに掲載されていません。無害な概念実証（PoC）がアドバイザリに添付されています。
• 3.17.0に更新し、サーバーのコンテナを再作成してください。今日中に更新できない場合は、サーバーに到達できる相手を制限してください。ベーシック認証では、実験を作成しアーティファクトをアップロードできる認証済みユーザーを止められません。

影響を受けるか

3.12.0以降3.17.0未満のMLflowトラッキングサーバーを運用しており、実験の作成やアーティファクトのアップロードを許されるべきでない呼び出し元からHTTPで到達でき、かつそのプロセスがインストール済みのscorerパッケージのいずれかの内部に書き込める場合、影響を受けます。 以下の3つすべてに当てはまる必要があります。

• バージョン3.12.0（そのリリース候補版を含む）以降、3.17.0未満のMLflowトラッキングサーバーを運用している。このバグを含むサードパーティscorer機能は3.12.0で初めて登場しました。
• サーバーのHTTPエンドポイント（実験、run、アーティファクトのアップロード、scorer呼び出しのルート）に、本来は実験の作成やアーティファクトのアップロードができるべきでない呼び出し元が到達できる。認証はデフォルトで無効です。mlflow serverは別の--host（0.0.0.0など）を指定して起動しない限り127.0.0.1にバインドされます。ループバック以外で待ち受けている場合、またはプロキシがリクエストを転送している場合は、そのポートに到達できる誰もが該当します。ベーシック認証を有効にしている場合は、実験とrunを作成しアーティファクトをアップロードできる、認証済みのあらゆるプリンシパルが該当します。
• サーバープロセスが、インストール済みのscorerパッケージのいずれかの配下に書き込める。アドバイザリによれば、これは公式のMLflowイメージと、同じOSユーザーがインストールして実行する仮想環境で成り立ちます。読み取り専用のコンテナファイルシステムや、サーバープロセスが書き込めないscorerパッケージディレクトリであれば、この配置チェーンそのものは阻止されます。

規模の目安として、PyPIは2026年10月28日までの1週間にmlflowのダウンロードを4,880,597件記録しています。これはトラッキングサーバーに限らず、すべてのダウンロードを数えたものです。

まず稼働中のサーバーに問い合わせ、そのデプロイにインストールされたパッケージと比較してください。パッケージのメタデータだけでは、更新後にプロセスが再起動したことは確認できません。

# Running server process (include your deployment authentication if required)
curl -fsS http://<server>:<port>/version

# Installed package: run inside the deployment with the server interpreter/user
docker exec <container> python -c "import mlflow; print(mlflow.__version__)"
python -c "import mlflow; print(mlflow.__version__)"

# On-disk package metadata only; this does not inspect the running process
python -m pip show mlflow | grep Version

# Dependency files (the advisory lists only the mlflow package, not mlflow-skinny)
grep -iE "^mlflow([^a-z0-9._-]|$)" requirements*.txt
grep -A10 '"mlflow"' Pipfile.lock | grep '"version"'

修正方法

サーバーのパッケージを3.17.0にアップグレードし、サーバーのコンテナを再作成してください。そうすることで、ディスク上のイメージだけでなく、稼働中のプロセスが置き換わります。

pip install -U "mlflow>=3.17.0"

pip install -Uが置き換えるのはディスク上のファイルだけです。アップグレード前に起動したサーバープロセスは、再起動するまで脆弱なコードをメモリ上に保持し続けます。サーバープロセスを再起動し（たとえばそのユニットに対するsystemctl restart、またはお使いのプロセス管理ツールの同等の操作）、その後、稼働中のサーバーに/versionエンドポイントでバージョンを問い合わせてください。3.17.0以降が返る必要があります。

curl -s http://<server>:<port>/version

コンテナ化されたサーバーの場合は、イメージのタグを変更してpullし、コンテナを再作成してください。古いコンテナを再起動しただけでは、古いコードがそのまま残ります。その後、新しいコンテナに対して上記のdocker execによるバージョン確認を実行し、3.17.0以降と表示されることを確かめてください。

同じリリースでは、関連する2つの問題も修正されています。

• CVE-2026-116690：認証なしのサーバーにおける、プロンプトとしてタグ付けされたモデルバージョンのソースパスを介した任意のファイル読み取り（CVSS v3.1 7.5、3.10.0から3.16.xが影響を受ける）。仕組みは下のFAQで説明します。
• CVE-2026-116691：CrewAIのautologgingが、記録されるトレーススパンにLLMプロバイダーのAPIキーを記録してしまいます（CVSS v3.1 6.5、2.19.0から3.16.xが影響を受ける）。

今日中にアップグレードできない場合、次の3つの緩和策で危険な期間を縮められます。ただし、いずれにも限界があります。

• トラッキングサーバーへのネットワーク到達性を制限する（ループバックへのバインド、VPN、認証付きのイングレス、IP許可リスト）。限界：アタックサーフェスは縮小しますが、何も修正されません。境界の内側にいる呼び出し元は、依然としてこのエンドポイントを悪用できます。
• MLflowのベーシック認証を有効にする。限界：scorer呼び出しエンドポイントはリソース単位の権限チェックで保護されていないため、実験、run、アーティファクトへのアクセス権を持つ認証済みプリンシパルは引き続き脅威となります。
• 読み取り専用のコンテナファイルシステムでサーバーを実行するか、scorerパッケージのディレクトリをサーバープロセスが書き込めない状態にする。限界：このファイル配置チェーンそのものは阻止できますが、根本にあるデシリアライゼーションの挙動は修正されません。

根本原因

scorerのデシリアライザーは文字列のプレフィックスを出所の境界として扱い、そのうえでリクエストが指定したモジュールを何でもインポートします。一方で、サーバー自身のアーティファクト用エンドポイントにより、呼び出し元はその境界の内側にモジュールを配置できます。 MLflow 3.12.0では、オープンソース版MLflowにサードパーティscorerの登録とデシリアライゼーションのサポートが導入されました（コミット02eea260、プルリクエスト#22634）。v3.14.0のリリースコミットの時点で、mlflow/genai/scorers/scorer_utils.pyは許可されるルートを次のように定義しています。

THIRD_PARTY_SCORER_ALLOWED_MODULES = frozenset({
    "mlflow.genai.scorers.ragas",
    "mlflow.genai.scorers.deepeval",
    "mlflow.genai.scorers.trulens",
    "mlflow.genai.scorers.phoenix",
})

mlflow/genai/scorers/base.pyでは、デシリアライザーはルートと完全一致するもの、またはその任意の子孫を受け入れ、その後リクエストで制御される値を使って3つの操作を実行します。

module_path == m or module_path.startswith(m + ".")
...
module = importlib.import_module(module_path)
scorer_class = getattr(module, class_name, None)
scorer_instance = scorer_class(**init_kwargs)

パッケージ名のプレフィックスは出所の境界にはなりません。サーバープロセスが許可されたパッケージの配下に書き込める場合、攻撃者が作成した子孫モジュールは文字列チェックを満たし、インポート可能なコードになります。

チェーンのもう半分は、アーティファクトのレイアウトです。実験作成エンドポイントはartifact_locationを受け付け、MLflowは各runのアーティファクトディレクトリを<artifact_location>/<run_id>/artifacts/として導出します。公式のMLflow v3.14.0イメージでは、呼び出し元は実験のアーティファクトの場所をfile:///usr/local/lib/python3.10/site-packages/mlflow/genai/scorers/trulensに設定できます。続いて呼び出し元がrunアーティファクト用エンドポイントからモジュールをアップロードすると、ファイルはインポートパスmlflow.genai.scorers.trulens.<run_id>.artifacts.<module>、つまり許可リストのプレフィックスの内側に置かれます。

最後に、mlflow/server/handlers.pyの_invoke_scorer_handler()は、指定されたトレースIDを検証または解決する前にscorerをデシリアライズして構築するため、攻撃者が制御するコンストラクターが先に実行されます。再現されたデフォルト構成のように認証が無効であれば、認証情報は一切必要ありません。

どのように悪用されるか

サーバーに到達できる呼び出し元は、MLflow自身の実験、run、アーティファクトのエンドポイントを使って許可済みscorerパッケージ内にPythonモジュールを書き込み、scorer呼び出しルートにそのモジュールをインポートさせ、そこからクラスを構築させます。 アドバイザリに添付された概念実証は、これらのエンドポイントを最初から最後までつなぎ合わせます。

1. artifact_locationが書き込み可能な許可済みscorerパッケージを指す実験を作成する。公式イメージでは、たとえばfile:///usr/local/lib/python3.10/site-packages/mlflow/genai/scorers/trulens
2. runを作成する。これによりMLflowは<artifact_location>/<run_id>/artifacts/を割り当てる
3. runアーティファクトのアップロード用エンドポイントから、Pythonモジュールaudit_<token>.pyをそのrunのアーティファクトディレクトリにアップロードする
4. moduleパスがアップロードしたファイルに解決される、シリアライズ済みのサードパーティscorerを送信する：mlflow.genai.scorers.trulens.<run_id>.artifacts.audit_<token>
5. POST /ajax-api/3.0/mlflow/scorer/invokeを通じてインポートとクラスの構築をトリガーする

その後、攻撃者が制御するコンストラクターがMLflowサーバープロセス内で実行されます。概念実証（PoC）では、コンストラクターが自身のアップロード済みアーティファクトの隣にランダムなマーカーファイルを書き込み、続いてPoCがそのファイルをrunアーティファクト用エンドポイントからダウンロードして完全一致を確認することで、実行を実証します。その後に発生するトレース処理の失敗とHTTP 500は、コンストラクターがすでに実行された後に起きるものであり、500が返っても悪用が否定されるわけではありません。

アドバイザリのリモート再現では、同じチェーンを、マニフェストダイジェストで固定した公式v3.14.0イメージを実行する使い捨てのクラウドホストに対して実行しました。プロセスはuid 0で動作しており、マーカーファイルにはwhoami: rootと記録されていました。

攻撃者に何ができるか

再現された標準の認証なしデプロイでは、トラッキングサーバーに到達できるネットワーク上の呼び出し元であれば誰でも、認証情報もユーザー操作もなしに、MLflowプロセスとしてPythonコードを実行できます。アドバイザリは影響範囲を明記しています。サーバープロセスが利用できるすべてのデータ、認証情報、ネットワークアクセス、ファイルシステム上の場所に対して、機密性、完全性、可用性への全面的な影響があります。公式イメージはプロセスをrootとして実行するため、コンテナレベルの影響は大きくなります。ホストへの影響は、引き続きコンテナランタイムの構成、マウントされたパス、付与されたケーパビリティ、ソケットの露出に左右されます。

2026年10月28日時点で、武器化されたエクスプロイトは公開されていません。

修正が有効な理由

修正であるコミットa732443e（「Match third-party scorer modules exactly instead of by package prefix」、プルリクエスト#25906、2026年9月16日マージ）は、プレフィックス一致を完全一致に置き換えます。

-            if not any(
-                module_path == m or module_path.startswith(m + ".")
-                for m in THIRD_PARTY_SCORER_ALLOWED_MODULES
-            ):
+            if module_path not in THIRD_PARTY_SCORER_ALLOWED_MODULES:

許可リスト自体も、mlflow.genai.scorers.ragas.scorers.rag_metricsのように具体的なscorerモジュールをすべてそのまま列挙する形に拡張されたため、正規のインポートは引き続き動作します。mlflow.genai.scorers.trulens.<run_id>.artifacts.audit_<token>のような呼び出し元が配置した子孫モジュールはリストのどれとも一致しなくなり、アーティファクト配置のチェーンは断ち切られます。さらに3つのゲートが、リクエストから到達しうる残りのインポート経路を塞ぎます。

• MLflowのRagasとDeepEvalのscorerラッパーは、未知のメトリクス名をragas.metrics.collections.<metric_name>やdeepeval.metrics.<metric_name>のようなインポートパスに組み込んで解決するため、metric_nameは単純なPython識別子でなければならない
• kwargsで、検証済みのmetric_nameを上書きすることはできない
• インポート後、取得したクラスはインスタンス化の前にScorerのサブクラスでなければならない

これらを組み合わせることで、デシリアライザーはMLflow自身が同梱するモジュールだけをインポートするようになり、それが本来の設計意図でした。

侵害されたかどうかを確認するには

公開されている資料は概念実証を説明するものであり、攻撃者の侵害指標（IOC）を示すものではないため、公開されたIOCリストは存在しません。アドバイザリ自体の仕組みから、影響を受けるデプロイでは、このチェーンが残す痕跡を確認できます。

• インストール済みのscorerパッケージ内で、MLflow自身の__init__.pyより新しい.pyファイルを探してください。$MLFLOW_ROOTがサーバーのインポート元のパスになるよう、コマンドはサーバーのインタープリターで実行してください。

# Files placed inside installed scorer packages (run with the server's interpreter)
MLFLOW_ROOT=$(python -c "import mlflow, os; print(os.path.dirname(mlflow.__file__))")
find "$MLFLOW_ROOT/genai/scorers/" -type f -name '*.py' -newer "$MLFLOW_ROOT/__init__.py"

• トラッキングストアを監査し、artifact_locationがPythonのインストール先内部、特にsite-packages/mlflow/genai/scorers/配下のfile://パスになっている実験を探してください。概念実証はまさにこのパターンを使っています。SQLのバックエンドストアではexperimentsテーブルを照会してください（以下のSQLiteの例はpsqlやmysqlでも同じように使えます）。ファイルベースのmlrunsストアでは、各実験のmeta.yamlにartifact_locationが記録されています。

# Experiments whose artifact location points into the scorer packages
sqlite3 mlflow.db "SELECT experiment_id, name, artifact_location FROM experiments WHERE artifact_location LIKE '%/mlflow/genai/scorers%';"
grep -l 'mlflow/genai/scorers' mlruns/*/meta.yaml

• サーバーのアクセスログから、/ajax-api/3.0/mlflow/scorer/invokeへのPOSTリクエストのうち、ペイロードに.artifacts.セグメントを含むmoduleパスを持つthird_party_scorer_dataが含まれているものを探してください。このチェーンが生成するパスは常にmlflow.genai.scorers.<package>.<run_id>.artifacts.<module>という形で、32文字の16進数のrun IDが.artifacts.の直前に入ります。MLflowが同梱するモジュールにこのセグメントを含むものはありません。
• サーバーのアクセスログから.pyファイルのアップロードを探してください。MLflowのrunアーティファクトのアップロードルートPOST /ajax-api/2.0/mlflow/upload-artifactは、保存先のファイル名をクエリパラメーターpathで受け取るため、アップロードされたファイル自体が削除された後でもこの確認は有効です。

grep -E 'POST /ajax-api/2\.0/mlflow/upload-artifact\?[^ ]*path=[^ &]*\.py' access.log

ログレビューで何も見つからなくても、弱い保証にすぎません。 影響を受けるバージョンで、サーバーが認証を無効にしたまま開かれたネットワーク上で稼働していた期間が少しでもある場合は、特にそうです。すべての手順はMLflow自身の実験、run、アーティファクト、scorerのエンドポイントを経由するため、通常とは異なるエンドポイントを狙うリクエストはなく、上記のような細部だけがこれらのリクエストを正当な利用と区別します。残る痕跡は、file://のartifact_locationを持つ実験レコードと、アップロードされたモジュールを保持するrunディレクトリです。概念実証では、モジュールの隣にマーカーファイルも置かれます。サーバープロセスとして実行されるコードは、これらの痕跡をすべて削除できます。

これらの痕跡のいずれかが見つかった場合は、その場でアップグレードするだけで済ませず、サーバーが侵害されたものとして扱ってください。アドバイザリは、サーバープロセスが利用できるすべてのデータ、認証情報、ネットワークアクセス、ファイルシステム上の場所を影響範囲に含めています。そのため、サーバーを隔離し、そのプロセスが読み取れたすべての認証情報をローテーションし、3.17.0以降のクリーンなイメージからサーバーを再作成してください。

タイムライン

• 2026-07-12：アドバイザリのサニタイズ済みリモート再現出力にこの日付がサーバー時刻として記録されており、アドバイザリはこの日付の時点で修正済みリリースは確認されていなかったと述べている（GitHubアドバイザリ、概念実証のトランスクリプト）
• 2026-09-16：修正コミットa732443eがプルリクエスト#25906を通じてmasterにマージされる。完全一致によるモジュール照合に加え、識別子、kwargs、サブクラスのゲート（GitHubコミット）
• 2026-10-07：修正を含むMLflow 3.17.0がリリースされる（GitHubリリース）
• 2026-10-09：MLflowがリポジトリアドバイザリGHSA-26p8-2jq9-3vq9を公開（08:20 UTC）。Critical、CVSS v3.1 9.8と評価（GitHubセキュリティアドバイザリ）
• 2026-10-27：GitHub Advisory DatabaseがGHSA-26p8-2jq9-3vq9を掲載（21:26 UTC）
• 2026-10-28：本記事

修正自体は、7月の再現から2か月以上後に行われました。7月から露出しており、10月7日にアップグレードされなかった影響を受けるサーバーにとって、10月9日のアドバイザリより前に存在した公開シグナルは、9月16日の修正コミットと、3.17.0のリリースノートにある1行の記載だけでした。どちらも「Match third-party scorer modules exactly instead of by package prefix (GHSA-26p8-2jq9-3vq9)」というタイトルです。依存関係スキャナーが反応するまでには、さらに時間がかかりました。DependabotのアラートはGitHub Advisory Databaseに基づいており、同データベースがこのアドバイザリを掲載したのは10月27日で、OSVのエントリも同じ日付です。そのため、これらのアラートに頼るパッチ運用には、アドバイザリから18日間、修正版のリリースから20日間、何のシグナルも届きませんでした。

よくある質問

MLflowクライアントもリスクになるのか、それともセルフホストのサーバーだけか

サーバー側だけです。このチェーンには、トラッキングサーバー自身のHTTPエンドポイントが必要です。具体的には、任意のartifact_locationを指定した実験の作成、runの作成、アーティファクトのアップロード、scorerの呼び出しです。他者が運用しパッチを適用しているサーバーに対してMLflowをクライアントとして使っているだけであれば、クライアントのバージョンがこのリスクを生むことはありません。

認証を有効にすれば防げるのか

認証不要の攻撃パターンは防げますが、認証済みのパターンは残ります。アドバイザリによれば、scorer呼び出しエンドポイントはvalidate_gateway_proxyに割り当てられており、これは実験やscorerレベルのリソース権限チェックを行わずにtrueを返します。そのため、実験の作成、runの作成、アーティファクトのアップロードができる認証済みプリンシパルであれば、依然としてコンストラクターに到達できます。

読み取り専用ファイルシステムで防げるのに、なぜCVSSが9.8なのか

9.8のベクター（AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）は、アドバイザリが再現したデフォルトのデプロイを評価したものです。すなわち、ネットワークから到達可能で、認証もユーザー操作も不要であり、機密性、完全性、可用性への影響が全面的である構成です。読み取り専用ファイルシステムという条件は、この特定のチェーンの一つのリンクをたまたま断ち切るハードニング策であり、ソフトウェアのデフォルト構成の性質ではありません。

3.17.0で修正された関連する問題は、それ単体でもパッチを適用する価値があるか

CVE-2026-116690は、認証なしのサーバーにおける任意のファイル読み取りです（CVSS v3.1 7.5、3.10.0以降3.17.0未満が影響を受ける）。プロンプトとしてタグ付けされたモデルバージョンが../../../tmpのようなスキームなしの相対パスをソースとして持つことができ、サーバーがそのパスからファイルを配信してしまいます。これはRCEより2つ古いマイナーバージョンのデプロイにまで及びます。

CVE-2026-116691（CVSS v3.1 6.5、2.19.0以降3.17.0未満が影響を受ける）は、CrewAIのautologgingが有効な場合に、記録されるトレーススパンにLLMプロバイダーのAPIキーを記録してしまうもので、トレースを共有するあらゆるデプロイにおけるデータ露出の問題です。

3.17.0への1回のアップグレードで、3つすべてに対応できます。

公開されたエクスプロイトはあるか

アドバイザリには概念実証が添付されていますが、意図的に無害なものになっています。マーカーファイルを書き込み、それをダウンロードして一致を確認するだけです。武器を公開することなく、実行を実証しています。2026年10月28日時点で、在野での悪用は確認されておらず、このCVEはKEVカタログに掲載されていません。

Ostorlabで露出したMLflowサーバーを見つける

OstorlabのWebおよびAPIスキャンを実行して、自社の各環境を確認してください。露出しているMLflowトラッキングサーバーのエンドポイントと、それらが実行しているバージョンを特定し、すべてのデプロイが3.17.0以降であること、そして認証なしのインスタンスがインターネットから到達できないことを確認できます。

参考文献

• GitHubアドバイザリGHSA-26p8-2jq9-3vq9、CVE-2026-116692、CVSS v3.1 9.8、2026年10月9日公開、2026年10月27日にGitHub Advisory Databaseに掲載。完全な技術分析と概念実証の添付ファイルを含む：https://github.com/mlflow/mlflow/security/advisories/GHSA-26p8-2jq9-3vq9（2026年10月28日確認）
• 修正コミットa732443e、「Match third-party scorer modules exactly instead of by package prefix」、2026年9月16日：https://github.com/mlflow/mlflow/commit/a732443e695c3c677680c54320efc394c81654ab（2026年10月28日に全文を確認）
• 導入変更 02eea260, "Enable third-party scorer registration in OSS MLflow (#22634)", PR #22634: https://github.com/mlflow/mlflow/pull/22634 (2026年10月28日確認)
• MLflow 3.17.0リリース、2026年10月7日：https://github.com/mlflow/mlflow/releases/tag/v3.17.0
• 関連するアドバイザリ：GHSA-m65p-9j7q-6w33（CVE-2026-116690）とGHSA-j7qq-vr8c-xvw3（CVE-2026-116691）：https://github.com/advisories/GHSA-m65p-9j7q-6w33, https://github.com/advisories/GHSA-j7qq-vr8c-xvw3（2026年10月28日確認）
• ダウンロード規模、PyPIの週間ダウンロード数4,880,597件：https://pypistats.org/packages/mlflow（2026年10月28日確認）
• CISAのKnown Exploited Vulnerabilitiesカタログ。CVE-2026-116692が掲載されていないことを確認：https://www.cisa.gov/known-exploited-vulnerabilities-catalog（2026年10月28日確認）