AI Threat Alert
CVE-2026-69148: MLflow: missing authz check leaks private artifacts
GHSA-gqch-g4w5-7qcw HIGH CISA: TRACK*MLflow's model registry lets an authenticated user create a model version that points at another user's run or model artifacts, because the source-validation check only confirms the path is contained within the expected root and never verifies the caller actually owns that run or model — the attacker then simply calls the artifact-download endpoint to read files they were never granted READ access to. This matters because MLflow is a shared, multi-tenant backbone for MLOps: it has 683 downstream dependents and a package risk score of 81/100 in our tracking, and the flaw requires nothing more than a low-privileged authenticated account, no user interaction, and low attack complexity (CVSS 7.1, C:H). There's no public exploit or Nuclei template yet, it isn't in CISA KEV, and no EPSS score has been published, so this isn't under active mass exploitation today — but any organization running a shared MLflow tracking server across teams or business units should treat this as a live cross-tenant data exposure risk, not a theoretical one. Patch to MLflow 3.15.0 immediately; until then, audit CreateModelVersion logs for run_id/model_id values that don't belong to the calling user and consider artifact-store-level ACLs (e.g., bucket policies keyed to run ownership) as a compensating control.
What is the risk?
High severity (CVSS 7.1) driven almost entirely by ease of exploitation: network-reachable, low attack complexity, only low privileges required, and zero user interaction. Confidentiality impact is High (arbitrary read of another user's artifact directory contents), integrity impact is Low (creation of a spurious model version metadata record), and availability is unaffected. The absence of a KEV listing, EPSS score, public PoC, or Nuclei template means there is no evidence of active exploitation today, which tempers urgency for internet-facing scanning campaigns — but the bug requires only a legitimate low-privilege account on a shared MLflow instance, which is precisely the deployment pattern most enterprise MLOps platforms use. Any multi-tenant or multi-team MLflow deployment (shared tracking server, shared artifact store) should treat this as a realistic insider/cross-tenant threat rather than a low-probability edge case.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| MLflow | npm | < 3.15.0 | 3.15.0 |
Do you use MLflow? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
Upgrade to MLflow 3.15.0 or later immediately — this is the only complete fix. Until patched, restrict who can call CreateModelVersion (e.g., require review/approval workflows for cross-experiment model registration) and add a compensating access-control layer at the artifact store itself (S3/GCS bucket or blob policies scoped to the run's owning user/team) rather than relying solely on MLflow's application-layer checks. For detection, review CreateModelVersion audit/API logs for run_id or model_id values that reference artifact paths outside the calling user's own experiments, and flag subsequent GET /model-versions/get-artifact calls against those newly created versions. In shared deployments, treat any secrets or credentials that may have been stored inside MLflow artifact directories as potentially exposed and rotate them as a precaution.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-69148?
MLflow's model registry lets an authenticated user create a model version that points at another user's run or model artifacts, because the source-validation check only confirms the path is contained within the expected root and never verifies the caller actually owns that run or model — the attacker then simply calls the artifact-download endpoint to read files they were never granted READ access to. This matters because MLflow is a shared, multi-tenant backbone for MLOps: it has 683 downstream dependents and a package risk score of 81/100 in our tracking, and the flaw requires nothing more than a low-privileged authenticated account, no user interaction, and low attack complexity (CVSS 7.1, C:H). There's no public exploit or Nuclei template yet, it isn't in CISA KEV, and no EPSS score has been published, so this isn't under active mass exploitation today — but any organization running a shared MLflow tracking server across teams or business units should treat this as a live cross-tenant data exposure risk, not a theoretical one. Patch to MLflow 3.15.0 immediately; until then, audit CreateModelVersion logs for run_id/model_id values that don't belong to the calling user and consider artifact-store-level ACLs (e.g., bucket policies keyed to run ownership) as a compensating control.
Is CVE-2026-69148 actively exploited?
No confirmed active exploitation of CVE-2026-69148 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-69148?
Upgrade to MLflow 3.15.0 or later immediately — this is the only complete fix. Until patched, restrict who can call CreateModelVersion (e.g., require review/approval workflows for cross-experiment model registration) and add a compensating access-control layer at the artifact store itself (S3/GCS bucket or blob policies scoped to the run's owning user/team) rather than relying solely on MLflow's application-layer checks. For detection, review CreateModelVersion audit/API logs for run_id or model_id values that reference artifact paths outside the calling user's own experiments, and flag subsequent GET /model-versions/get-artifact calls against those newly created versions. In shared deployments, treat any secrets or credentials that may have been stored inside MLflow artifact directories as potentially exposed and rotate them as a precaution.
What systems are affected by CVE-2026-69148?
This vulnerability affects the following AI/ML architecture patterns: model registry, MLOps pipelines, model serving, experiment tracking.
What is the CVSS score for CVE-2026-69148?
CVE-2026-69148 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.37%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0025 Exfiltration via Cyber Means AML.T0035 AI Artifact Collection AML.T0049 Exploit Public-Facing Application Compliance Controls Affected
What are the technical details?
Original Advisory
MLflow is an open source AI engineering platform for agents, large language models, and machine learning models. Prior to 3.15.0, CreateModelVersion accepts a run_id or model_id after _validate_source_run() or _validate_source_model() in mlflow/server/handlers.py verifies only path containment, allowing authenticated users to create a model version that references another user's artifact directory and read files through GET /model-versions/get-artifact without the required READ permission. This issue is fixed in version 3.15.0.
Exploitation Scenario
An attacker with a low-privilege authenticated account on a shared MLflow tracking server enumerates or guesses run_id/model_id values belonging to other teams (via the UI's experiment listing, API responses, or predictable identifiers). They call CreateModelVersion supplying that foreign run_id/model_id — MLflow's _validate_source_run()/_validate_source_model() checks only confirm the path stays within the expected root directory, not that the caller owns the run or model, so the request succeeds and a new model version is created under the attacker's control pointing at the victim's artifact directory. The attacker then issues GET /model-versions/get-artifact against their newly created model version, which serves files straight from the victim's directory without re-checking READ permission on the original run or model, exfiltrating model weights, training configs, or other sensitive artifacts belonging to a team the attacker has no legitimate access to.
Weaknesses (CWE)
CWE-862 Missing Authorization
Primary
CWE-862 Missing Authorization
Primary
CWE-862 Missing Authorization CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
- [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N References
Timeline
Related Vulnerabilities
CVE-2025-15379 10.0 MLflow: RCE via unsanitized model dependency specs
Same package: mlflow CVE-2023-3765 10.0 MLflow: path traversal allows arbitrary file read
Same package: mlflow CVE-2023-2780 9.8 MLflow: path traversal allows arbitrary file read/write
Same package: mlflow CVE-2026-2635 9.8 mlflow: security flaw enables exploitation
Same package: mlflow CVE-2023-1177 9.8 MLflow: path traversal allows arbitrary file read/write
Same package: mlflow