CVE-2026-69148: Broken Object Level Authorization (BOLA) in MLflow Model Registry

MLflow is an open-source platform designed to manage the machine learning lifecycle, including experimentation, reproducibility, deployment, and a central model registry. Inside collaborative enterprise environments, access controls must strictly separate user datasets, training parameters, and proprietary model structures. MLflow establishes discrete authorization boundaries between experimental runs and registered models in the registry.

Prior to version 3.15.0, a significant logical flaw existed in the CreateModelVersion API handler. The server validated permissions on the destination registry target but omitted verification on the source run or logged model. This omission exposes a wide attack surface for lateral data access across multi-tenant deployments.

The vulnerability is classified under CWE-862 (Missing Authorization) and represents a classic Broken Object Level Authorization (BOLA) pattern. An authenticated attacker can exploit this weakness to traverse organizational boundaries and extract sensitive training configurations, proprietary model weights, or embedded system secrets from restricted runs.

This gap in authorization enforcement undermines the trust model of distributed AI training environments. Because model files are typically large and contain rich analytical intellectual property, secure storage of these assets is paramount. Failing to enforce source-level validation introduces severe compliance and integrity issues across the platform.

The root cause of CVE-2026-69148 lies in the logical flow of the model version creation process inside MLflow's backend handlers. When a client requests the registration of a new model version via the POST /api/2.0/mlflow/model-versions/create endpoint, the request requires referencing an origin data source. This origin is specified by the run_id or model_id parameter, indicating where the target model's training artifacts reside.

The MLflow authorization engine is designed to intercept REST API requests and evaluate whether the authenticated caller has the permissions required to complete the action. Historically, the route mapping for CreateModelVersion invoked _validate_can_update_registered_model_or_prompt. This validation checked whether the caller possessed either UPDATE or MANAGE privileges over the destination model registry object.

However, the backend completely omitted authorization checks on the origin source specified in the payload. While the validator confirmed that the destination model registry could be modified by the user, it never queried whether the user had read permissions on the run_id or model_id pointing to the source directory. This decoupling of source authorization from destination authorization allowed arbitrary binding of unowned assets to user-controlled model registry nodes.

Because the creation phase lacked cross-validation, the relationship between the registered model and the source files was established based on unverified declarations. This disconnect is highly problematic because subsequent read requests check permissions against the destination registered model. Therefore, once the relationship is established, any user authorized to read the model can also read the associated run artifacts.

The vulnerability was introduced due to the insufficient mapping of permission checks on the CreateModelVersion RPC handler inside mlflow/server/auth/__init__.py. The mapping initially mapped the endpoint directly to model registry updates rather than assessing the origin materials.

# Vulnerable Mapping in mlflow/server/auth/__init__.py
# Only validated that the user possessed permissions to write to the model registry
CreateModelVersion: _validate_can_update_registered_model_or_prompt,

The patch introduced in commit 4bb7474771c3be808cd9e129defef9305f2869be replaces this narrow check with a dedicated validation function, validate_can_create_model_version, which enforces read checks on the referenced source entities.

# Patched Mapping
CreateModelVersion: validate_can_create_model_version,

The implementation of validate_can_create_model_version inspects the incoming JSON payload for the presence of source parameters and evaluates permissions dynamically.

def validate_can_create_model_version():
    # Validate that the caller has UPDATE or MANAGE permissions on the target model registry
    if not _validate_can_update_registered_model_or_prompt():
        return False
    
    body = request.get_json(force=True, silent=True)
    body = body if isinstance(body, dict) else {}
    
    # Enforce READ access check if run_id is supplied in the request body
    if "run_id" in body and not (body["run_id"] and _get_permission_from_run_id().can_read):
        return False
        
    # Enforce READ access check if model_id is supplied in the request body
    if "model_id" in body and not (body["model_id"] and _get_permission_from_model_id().can_read):
        return False
        
    return True

This remediation enforces security consistency. An authenticated user cannot leverage their authorization over an arbitrary target model registry to map and extract metadata or artifacts from run-level objects unless they also possess legitimate read credentials for those specific runs.

Additionally, parsing request bodies safely with request.get_json(force=True, silent=True) prevents unhandled parsing crashes. Forcing standard dictionary coercion ensures that payload structural variations will not cause unexpected handler failures or crash-based denial-of-service conditions.

Exploitation of this vulnerability requires the attacker to be authenticated on the MLflow server and possess update or manage permissions over at least one registered model namespace. This configuration is common in collaborative environments where multiple data scientists share access to a central model registry but maintain private training experiments.

The attacker first identifies a target run_id or model_id associated with a private experiment owned by another user. With this identifier, the attacker sends a crafted POST request to /api/2.0/mlflow/model-versions/create specifying their own model name and mapping the source run parameter to the target's run identifier.

POST /api/2.0/mlflow/model-versions/create HTTP/1.1
Host: mlflow.internal.example.com
Authorization: Bearer <attacker_token>
Content-Type: json
 
{
  "name": "attacker-controlled-model",
  "source": "s3://secure-ml-bucket/experiments/99/run-123456/artifacts",
  "run_id": "run-123456"
}

Once registered, the MLflow server associates the attacker-controlled model version with the target run's cloud storage artifacts. The attacker then issues a request to GET /api/2.0/mlflow/model-versions/get-artifact specifying their model version and path. The backend verifies permissions only for the target model namespace, allowing the attacker to download any sensitive payload, dataset, or configuration file from the victim's storage directory.

This exploitation flow requires zero social engineering or complex interaction from victims. The vulnerability relies solely on the architectural disconnect in MLflow's authorization pipeline. Consequently, any deployment lacking the patch is highly exposed to silent data collection from internal network positions.

The security impact of CVE-2026-69148 is severe in multi-tenant or enterprise-managed MLflow environments. Because MLflow is routinely utilized to train deep learning models on proprietary data, artifacts often contain confidential intellectual property, trade secrets, sensitive personal information, or environment configurations.

An attacker who successfully exploits this vulnerability can systematically bypass administrative and network-level logical boundaries to exfiltrate raw dataset records, model weights, or checkpoint files. This bypass invalidates experiment-level or run-level access controls entirely.

Additionally, many ML systems store configurations containing service keys or API tokens inside run artifact directories. Gaining unauthorized access to these directories provides a high-probability vector for lateral movement across the surrounding cloud infrastructure, mapping directly to MITRE ATT&CK technique T1580 (Cloud Infrastructure Discovery) and T1068 (Exploitation for Privilege Escalation).

The lack of proper isolation of artifacts undermines compliance with standards such as SOC 2 and ISO 27001. In environments hosting regulated healthcare or financial models, such unauthorized cross-tenant data exposures could trigger regulatory reporting duties and significant liability.

The primary mitigation is updating the MLflow server deployment to version 3.15.0 or later. This version replaces the legacy validation mapping with the multi-layered checks present in validate_can_create_model_version.

While this patch addresses the direct logical failure, security teams should analyze potential secondary bypasses. If the backend permits model registration via raw source URIs without defining a run_id or model_id, the authorization helper does not perform verification on the URI. Ensure that underlying AWS IAM or GCP IAM roles assigned to the MLflow service account enforce strict boundaries to prevent cross-account or cross-bucket read operations.

To ensure complete remediation, deployments must configure server authentication and conduct a manual sweep of existing registered models. Any model versions pointing to run IDs not associated with the model's primary developer or project team should be flagged and investigated as potential compromise indicators. Regular configuration auditing of the MLflow database remains a necessary operational baseline.