GPU VulnDB

Database/AI/ML frameworks & serving

MLflow: missing permission check on runs/log-inputs lets any user forge another run's lineage

CVSS 6.5CVE-2026-69146AI/ML frameworks & servingcurated

Impact

LogInputs was never registered in BEFORE_REQUEST_HANDLERS, so the auth plugin performs no permission check on POST /api/2.0/mlflow/runs/log-inputs. Any authenticated user can name someone else's run_id and write attacker-chosen DatasetInput records into its dataset_inputs lineage without holding UPDATE on that run. On a shared cluster where MLflow is the multi-tenant record of which data trained which model, that makes provenance untrustworthy — for audit, for reproducing a run, and for model-governance sign-off. Any pipeline that reads dataset URIs back out of run lineage is then acting on strings another tenant supplied. Integrity only: no read access to other runs and no service disruption.

Who can reach it

Any user already authenticated to the MLflow tracking server with the auth plugin enabled, over the network. No permission on the target run is needed; run IDs are the only thing to guess, and they are widely visible within a workspace.

What to do

Upgrade to MLflow 3.15.0 and restart the tracking server; versions 3.13.0 up to 3.15.0 are affected. Patching stops new writes but does not clean up old ones, so review dataset_inputs on runs that matter for audit or reproducibility, particularly on any multi-tenant tracking server. No GPU node work.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-69146https://github.com/mlflow/mlflow/security/advisories/GHSA-3p64-6gvh-82v5https://github.com/mlflow/mlflow/commit/5c34aec5669e2386b38b5ee0855cd61174e27693https://github.com/mlflow/mlflow/releases/tag/v3.15.0

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.