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 DatasetInput records into another user's run lineage metadata without UPDATE permission. It affects MLflow versions 3.13.0 through 3.14.x (fixed in 3.15.0) when deployed with the --app-name basic-auth flag. The vulnerability was reported by researcher geo-chen, published to the GitHub Advisory Database on August 4, 2026, and assigned CVE-2026-69146 on August 17, 2026. It carries a CVSS v3.1 base score of 6.5 (Medium) (Github 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 write operations through a _before_request hook that looks up a permission validator for each request class; when no entry exists (i.e., the value resolves to None), the if validator: branch is skipped and the request is allowed to proceed for any authenticated user. The vulnerable endpoint POST /api/2.0/mlflow/runs/log-inputs (and its /ajax-api/ variant) therefore bypasses the validate_can_update_run check that sibling endpoints like LogMetric, LogBatch, SetTag, and LogParam correctly enforce. The fix, merged in PR #24291, adds LogInputs: validate_can_update_run (and also LogOutputs: validate_can_update_run) to BEFORE_REQUEST_HANDLERS (Github Advisory, Fix PR).

Successful exploitation allows any authenticated MLflow user to silently corrupt the dataset lineage metadata (dataset_inputs) of any other user's run, injecting attacker-controlled DatasetInput records with arbitrary names, digests, and profiles. There is no confidentiality or availability impact, but the integrity impact is high: in ML compliance and regulatory workflows, dataset provenance records serve as audit evidence for model reproducibility, and injecting fake entries can invalidate audit trails, cause misattribution of training data, and introduce confusion about which datasets were used to train a model. No elevated permissions are required beyond a valid credential, making the attack accessible to any user on a shared MLflow deployment (Github Advisory).

The vulnerability requires only a valid MLflow credential and network access to the API — no special privileges or user interaction are needed. A proof-of-concept is included in the security advisory itself, demonstrating the full attack flow with HTTP requests. As of the disclosure date, there is no evidence of in-the-wild exploitation or threat actor attribution. The EPSS score is 0.0, and the vulnerability is not listed in the CISA KEV catalog (Github Advisory).

1. Identify target: Locate an MLflow instance (version 3.13.0–3.14.x) running with --app-name basic-auth and obtain valid credentials for any user account on that instance.
2. Enumerate target run IDs: Use the MLflow API (e.g., GET /api/2.0/mlflow/runs/search) with your own credentials to discover run_id values belonging to other users or experiments you do not own.
3. Verify the bypass: Confirm the authorization gap by attempting a write to a protected endpoint (e.g., POST /api/2.0/mlflow/runs/log-metric) against a target run — this should return HTTP 403.
4. Inject malicious dataset records: Send a crafted POST request to the unprotected endpoint:

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"}}]}

The server responds with HTTP 200 and an empty body, confirming the injection succeeded. 5. Verify persistence: Retrieve the victim's run via GET /api/2.0/mlflow/runs/get?run_id=<victim_run_id> (using any valid credentials) and confirm the injected DatasetInput record appears in the dataset_inputs array (Github Advisory).

• Network: Unexpected POST requests to /api/2.0/mlflow/runs/log-inputs or /ajax-api/2.0/mlflow/runs/log-inputs from users who do not own the referenced run_id; HTTP 200 responses to such requests on MLflow versions 3.13.0–3.14.x.
• Logs: MLflow access logs showing POST /api/2.0/mlflow/runs/log-inputs calls where the authenticated user's username does not match the experiment/run owner; repeated calls from a single user targeting multiple distinct run_id values.
• Data Integrity: Unexpected or anomalous DatasetInput entries (e.g., unusual name, digest, or profile values) appearing in the dataset_inputs lineage metadata of runs belonging to users who did not log those datasets.

Upgrade MLflow to version 3.15.0 or later, which adds LogInputs (and LogOutputs) to BEFORE_REQUEST_HANDLERS with the validate_can_update_run validator, enforcing consistent authorization across all run-write endpoints (MLflow v3.15.0 Release). 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. After patching, review MLflow audit logs for unauthorized log-inputs calls targeting runs not owned by the calling user to assess whether any dataset lineage records were tampered with (Github Advisory).