CVE-2026-69146: 
JavaScript vulnerability analysis and mitigation

CVE-2026-69146 is a missing authorization vulnerability in MLflow's built-in basic-auth plugin that allows any authenticated user to inject arbitrary dataset records into another user's run via the POST /api/2.0/mlflow/runs/log-inputs endpoint. It affects MLflow versions 3.13.0 through 3.14.x (fixed in 3.15.0) and was published on August 17, 2026. The vulnerability carries a CVSS v3.1 base score of 6.5 (Medium) (Github Advisory, MLflow Security Advisory).

The root cause is CWE-862 (Missing Authorization): the LogInputs protobuf request class was absent from the BEFORE_REQUEST_HANDLERS dictionary in mlflow/server/auth/__init__.py. MLflow's basic-auth plugin gates all HTTP handlers through a _before_request hook that looks up a permission validator in BEFORE_REQUEST_VALIDATORS; when a handler class is missing from the map, get_before_request_handler returns None, causing the authorization branch to be skipped entirely (since None is falsy). As a result, the /api/2.0/mlflow/runs/log-inputs endpoint (and its /ajax-api/ variant) accepted any valid credential without checking whether the caller had UPDATE permission on the target run, while sibling write endpoints like LogMetric, LogBatch, SetTag, and LogParam correctly enforced access controls. A proof-of-concept demonstrating the bypass was included in the security advisory (MLflow Security Advisory, Fix PR #24291).

Successful exploitation allows any authenticated MLflow user to corrupt the dataset lineage metadata (dataset_inputs) of any other user's run without requiring elevated permissions. In ML compliance and governance workflows, dataset provenance records serve as audit evidence for model reproducibility and regulatory review; injecting fake or misleading DatasetInput records can silently invalidate audit trails, cause misattribution of model training data, and introduce confusion about which datasets were used to train a model. There is no confidentiality or availability impact — the vulnerability is limited to integrity of run metadata (MLflow Security Advisory, Github Advisory).

A proof-of-concept was included in the official security advisory, demonstrating the bypass with a simple HTTP POST request using any valid credential. No evidence of in-the-wild exploitation has been reported, and no threat actor attribution is available. The EPSS score is approximately 0.221% (12th percentile), indicating low near-term exploitation probability. The vulnerability is not listed in the CISA KEV catalog. Qualys has published a detection (ID: 532214) for this vulnerability (Github Advisory, Feedly).

1. Identify target: Locate an MLflow instance running version 3.13.0–3.14.x with the basic-auth plugin enabled (--app-name basic-auth). Obtain valid credentials for any user account on the instance.
2. Identify target run: Enumerate accessible runs or obtain a run_id belonging to another user (e.g., via GET /api/2.0/mlflow/runs/search or GET /api/2.0/mlflow/experiments/list).
3. Craft malicious request: Construct a POST request to the unprotected endpoint with attacker-controlled dataset metadata:

POST /api/2.0/mlflow/runs/log-inputs HTTP/1.1
Authorization: Basic <base64(attacker:password)>
Content-Type: application/json

{"run_id": "<victim_run_id>", "datasets": [{"dataset": {"name": "ATTACKER_injected", "digest": "evil123", "profile": "attacker_controlled"}}]}

4. Confirm injection: Verify the injected record persisted by fetching the victim's run: GET /api/2.0/mlflow/runs/get?run_id=<victim_run_id> — the dataset_inputs array will contain the attacker-controlled entry.
5. Impact: The injected DatasetInput records corrupt the run's lineage metadata, potentially invalidating audit trails or causing misattribution of training data in compliance workflows (MLflow Security Advisory).

• Network: Unexpected POST /api/2.0/mlflow/runs/log-inputs or POST /ajax-api/2.0/mlflow/runs/log-inputs requests where the authenticated user does not own the target run_id; cross-user API calls from unusual source IPs or at unusual times.
• Logs: MLflow access logs showing HTTP 200 responses to /api/2.0/mlflow/runs/log-inputs for run_id values belonging to a different user than the authenticated caller; absence of corresponding HTTP 403 responses that would be expected for other write endpoints.
• Application Data: Unexpected or anomalous DatasetInput records (e.g., with suspicious name, digest, or profile values) appearing in the dataset_inputs lineage metadata of runs, particularly records not matching the run owner's known workflow (MLflow Security Advisory).

Upgrade MLflow to version 3.15.0 or later, which adds LogInputs (and LogOutputs) to BEFORE_REQUEST_HANDLERS mapped to validate_can_update_run, enforcing consistent authorization with all other run-write endpoints (MLflow v3.15.0 Release, Fix PR #24291). If immediate patching is not possible, restrict network access to the MLflow API to trusted users only, or disable the basic-auth plugin until the patch can be applied. Review MLflow audit logs for unauthorized log-inputs calls targeting other users' runs to assess potential impact (Github Advisory).

The vulnerability was reported by security researcher geo-chen and published by MLflow maintainer PattaraS on August 4, 2026, with the fix merged the same day via PR #24291. The fix also addressed a related gap for the LogOutputs endpoint, which was identified during code review by an automated reviewer. No significant broader media coverage or notable community commentary beyond the GitHub advisory and standard vulnerability database entries has been observed (MLflow Security Advisory, Fix PR #24291).