Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach unauthenticated scorer/invoke endpoint
-
DeliveryCraft trulens scorer JSON with attacker kwargs
-
ExploitReflective instantiation routes to LiteLLM fallback
-
ExecutionServer sends outbound request to chosen host
-
ImpactSSRF reaches internal/metadata services
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V15 - Secure Coding and Architecture Reflection safety, class allowlisting
|
| Exploitation Conditions | Requires three concrete conditions, all drawn from the advisory: (1) the MLflow tracking server (3.12.0rc0-3.16.x) must be network-reachable with no authentication configured - the handler _invoke_scorer_handler is guarded only by @catch_mlflow_exception/@_disable_if_artifacts_only, so no auth is needed against default server deployments; (2) the optional, not-bundled trulens AND trulens-providers-litellm packages must be installed in the server venv (a documented GenAI-eval setup) - without them the exploitable LiteLLM fallback branch is unreachable; (3) the attacker must supply a model URI outside MLflow's native provider registry (e.g. openai:/gpt-4o) to force the LiteLLM fallback that forwards raw api_base/api_key kwargs. The primary limiting factor is condition (2): absent the optional trulens providers, the SSRF sink cannot be reached. No user interaction and no authentication are required. |
| Impact | This is a genuine, prioritize-this-cycle issue rather than inflated-CVSS noise, but its blast radius is gated by one precondition. The CVSS vector (AV:N/AC:L/PR:N/UI:N) is corroborated by the GHSA advisory: the endpoint POST /ajax-api/3.0/mlflow/scorer/invoke carries no auth decorator and reflectively instantiates an attacker-named class with unconstrained kwargs, so PR:N (unauthenticated) is confirmed and consistent with the description. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with the moderate 6.5 base score. No CISA KEV listing and no EPSS score are present in the input, so there is no signal of active or probabilistic widespread exploitation - exploitation status is therefore 'no confirmed active exploitation'. However, a complete, working proof-of-concept is published directly in the vendor GHSA advisory, which materially raises practical risk versus a theoretical bug. The decisive constraint: exploitation only reaches the SSRF sink when the optional, not-bundled trulens + trulens-providers-litellm packages are installed; without them the reflective instantiation still occurs but the LiteLLM fallback that forwards api_base/api_key is unreachable. The SSRF reaching internal services and cloud-metadata endpoints is the real concern on exposed, unauthenticated tracking servers. Net: treat as an urgent patch where MLflow 3.12.0rc0-3.16.x is network-reachable AND the trulens providers are installed; lower urgency where those packages are absent. |
| Exploit ScenarioDerived | An attacker who can reach an unauthenticated MLflow tracking server (versions 3.12.0rc0-3.16.x) with the optional trulens and trulens-providers-litellm packages installed sends a crafted POST to /ajax-api/3.0/mlflow/scorer/invoke whose serialized scorer selects mlflow.genai.scorers.trulens with a model URI (e.g. openai:/gpt-4o) that routes to the LiteLLM fallback. The attacker-supplied api_base and api_key kwargs cause the server to issue a server-originated outbound HTTP request to an attacker-chosen or internal host with fully attacker-controlled headers and body, enabling SSRF against internal services or cloud-metadata endpoints. A full working proof-of-concept is published in the vendor GHSA advisory. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 23, 2026
Unauthenticated server-side request forgery in MLflow 3.12.0rc0 through 3.16.x lets remote attackers make the tracking server issue outbound HTTP requests to an arbitrary attacker-chosen host, including internal services or cloud-metadata endpoints, with attacker-controlled headers and body. The flaw is reachable through the scorer invoke, register, and GenAI evaluate endpoints (notably POST /ajax-api/3.0/mlflow/scorer/invoke), and is only exploitable when the optional trulens and trulens-providers-litellm packages are installed in the server environment; a model URI outside MLflow's native provider registry forces the LiteLLM fallback that forwards raw api_base and api_key values. It is fixed in MLflow 3.17.0. No CISA KEV listing or confirmed active exploitation exists, and the vendor advisory ships a public proof-of-concept script that has not been independently verified here as working exploit code; the vuln.today decision label places it in the current month's remediation cycle rather than the emergency queue.
RemediationAI
Vendor-released patch: upgrade MLflow to 3.17.0 (release https://github.com/mlflow/mlflow/releases/tag/v3.17.0, via PR https://github.com/mlflow/mlflow/pull/25890 and commit bac30b4148c4f40045b4d4db07ae60ab3838803f), which adds server-side validation that rejects third-party scorer kwargs capable of steering the judge's outbound requests, applied to both inline request payloads and scorers resolved from the tracking store. If upgrading immediately is not possible, the decisive compensating control is to remove the optional trulens and trulens-providers-litellm packages from the tracking server's virtual environment, since without them the LiteLLM fallback branch - and therefore the SSRF sink - is unreachable; the trade-off is that TruLens-based GenAI evaluation on that server stops working. Additionally, restrict outbound network egress from the tracking server host so it cannot reach internal services or cloud-metadata endpoints, which limits what an SSRF can touch but does not remove the vulnerable deserialization path, and place authentication or network ACLs in front of the /ajax-api/3.0/mlflow/scorer endpoints (invoke, register) and the GenAI evaluate endpoint so unauthenticated callers cannot reach them. Updating to 3.17.0 is the complete fix; the vendor advisory does not describe any configuration change other than the version upgrade that fully closes the issue while keeping the optional scorer providers installed.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-470: use of externally-controlled input to select classes or code. MLflow's Scorer.model_validate_json() reads a serialized payload's third_party_scorer_data, imports the module named in the 'module' field, and reflectively instantiates the class named in 'class' with a kwargs dictionary taken verbatim from the request. The allowlist in mlflow/genai/scorers/scorer_utils.py only constrains which module paths may be imported (mlflow.genai.scorers.ragas, .deepeval, .trulens, .phoenix); it never constrains the selected attribute, the constructor arguments, or the model URI. When a trulens scorer is chosen with a model URI outside MLflow's native provider registry (for example openai:/gpt-4o), the routing logic in mlflow/genai/scorers/trulens/models.py falls through to the LiteLLM branch and passes the attacker's kwargs straight to trulens.providers.litellm.LiteLLM, which forwards api_base and api_key into litellm.completion() - turning reflective deserialization into an SSRF sink (CWE-918) with header injection. The vulnerable reconstruction happens synchronously before any tracking-store lookup or job submission, and the invoke handler (mlflow/server/handlers.py) carries no authentication decorator, only @catch_mlflow_exception and @_disable_if_artifacts_only. The upstream fix in PR #25890 introduces _validate_serialized_scorer_payload() and _validate_third_party_scorer_data(), which reject gateway destination keys (api_base and aliases such as completion_kwargs/model_kwargs) at any nesting depth and across wrapping scorers such as ensembles and MemAlign judges, and applies the check both to caller-supplied payloads and to scorers resolved from the tracking store. The same change also server-side-enforces the existing block on decorator scorers carrying a call_source field that would otherwise be executed via exec() during deserialization.
Know when Mlflow gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Unauthenticated network reach confirmed by the no-auth endpoint (PR:N, AV:N, AC:L); SSRF yields a forced server-originated request with limited confidentiality/integrity impact and no availability loss (C:L/I:L/A:N, S:U).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.org
MLflow is an open source AI engineering platform for agents, large language models, and machine learning models. From 3.12.0rc0 until 3.17.0, the scorer invoke, register, and GenAI evaluate endpoints, including unauthenticated POST /ajax-api/3.0/mlflow/scorer/invoke, accept serialized third-party scorer data that Scorer.model_validate_json resolves using a module-path allowlist without constraining the selected class or its constructor arguments. When optional trulens and trulens-providers-litellm packages are installed, an attacker can select mlflow.genai.scorers.trulens, choose a model URI outside MLflow's native provider registry so execution uses the LiteLLM fallback, and supply api_base and api_key values that cause the server to send an outbound request to an attacker-chosen or internal host with attacker-controlled headers and body. The vulnerable deserialization occurs before a tracking-store lookup or job submission. This issue is fixed in version 3.17.0.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs.
Insecure deserialization occurs when an application converts serialized data (a stream of bytes representing an object's state) back into a living object without proper validation.
Server-side request forgery in MLflow before 3.15.0 lets remote unauthenticated attackers coerce the server into making
A path traversal vulnerability exists in mlflow/mlflow version 2.15.1. Rated high severity (CVSS 7.5), this vulnerabilit
Absolute Path Traversal in GitHub repository mlflow/mlflow prior to 2.5.0. Rated critical severity (CVSS 10.0), this vul
Unauthenticated remote code execution in MLflow 3.12.0rc0 through 3.16.x lets any network caller reach the tracking serv
MLflow's FastAPI job endpoints bypass basic-auth entirely, allowing network attackers to submit and execute jobs without
A malicious user could use this issue to get command execution on the vulnerable machine and get access to data & models
A malicious user could use this issue to access internal HTTP(s) servers and in the worst case (ie: aws instance) it cou
An attacker is able to arbitrarily create an account in MLflow bypassing any authentication requirment. Rated critical s
An attacker can overwrite any file on the server hosting MLflow without any authentication. Rated critical severity (CVS
Path Traversal: '\..\filename' in GitHub repository mlflow/mlflow prior to 2.3.1. Rated critical severity (CVSS 9.8), th
Path Traversal: '\..\filename' in GitHub repository mlflow/mlflow prior to 2.2.1. Rated critical severity (CVSS 9.8), th
Insufficient sanitization in MLflow leads to XSS when running a recipe that uses an untrusted dataset. Rated critical se
EUVD-2026-109184
GHSA-2wqp-q3c6-ccj5
NVD
CVE.org
EPSS
Exploit-DB