MLflow EUVD-2026-60474

Exploitation requires a valid authenticated account on the target MLflow server with at least UPDATE/EDIT permission on one registered model (to invoke CreateModelVersion). The MLflow deployment must be running in multi-user authentication mode with per-user permission enforcement active - the confusion only arises when users share a single MLflow instance with isolated permissions. The attacker must also possess or enumerate a run_id or model_id belonging to a victim; MLflow's experiment and run search APIs may expose these identifiers depending on permission configuration. Limiting factors: authentication is mandatory (PR:L - no unauthenticated exploitation path exists); single-user or non-auth-enabled deployments have no cross-user trust boundary to violate; and artifact content is limited to what the referenced run or model actually contains. There is no required non-default configuration beyond multi-user auth being enabled, which is the expected production posture for shared deployments.

The CVSS 3.1 score of 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N) accurately reflects the real-world risk profile: network-accessible exploitation with low complexity, requiring only a valid authenticated account. The high confidentiality impact is substantiated - an attacker can exfiltrate trained model weights, dataset artifacts, logged metrics files, and any other run artifacts belonging to co-tenants. The low integrity impact reflects the ability to create spurious model versions anchored to another user's artifact path. Scope is unchanged (S:U), containing the blast radius to data within the MLflow instance rather than enabling lateral movement to underlying infrastructure. No EPSS data was provided in available intelligence, but the full exploit technique is now publicly documented via GitHub security advisory GHSA-gqch-g4w5-7qcw and PR #24293, significantly lowering the barrier to exploitation; even a mid-sized ML engineering team operating a shared MLflow deployment in malbork should treat this as an urgent patching priority rather than a deferred item. The CVE is not in the CISA KEV catalog and no independent confirmation of active exploitation exists, but the attack is straightforward for any insider or low-privileged tenant with knowledge of a victim's run ID.

An authenticated MLflow user on a shared multi-tenant instance calls POST /api/2.0/mlflow/model-versions/create supplying a run_id belonging to a co-tenant (obtained through experiment search or out-of-band knowledge) and a source path pointing into that run's artifact directory. The path containment check passes, the model version is created under the attacker's own registered model, and the attacker then calls GET /model-versions/get-artifact against their own model version to retrieve the victim's trained model weights, datasets, or other logged artifacts without ever holding READ permission on the source run. The full exploit flow is publicly documented in the PR diff at https://github.com/mlflow/mlflow/pull/24293, including working test cases that demonstrate the 403 bypass.