Database/AI/ML frameworks & serving
MLflow: missing permission check on runs/log-inputs lets any user forge another run's lineage
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
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.