MLflow CVE-2026-64849, 69146 and 69148: webhooks, lineage and artifacts cross boundaries

Three MLflow CVE records were published on 17 August 2026. CVE-2026-64849 describes unauthenticated SSRF in webhook testing that could bypass validation through HTTP redirects or repeated DNS resolution. CVE-2026-69146 let an authenticated user add dataset-lineage metadata to another user’s run without UPDATE permission. CVE-2026-69148 allowed a model version to reference artifacts from another user’s run and then expose those files through a different API path.

All three issues are fixed in MLflow 3.15.0. The upstream advisories appeared earlier in August; publication of the CVE records was the development on 17 August. They should not be presented as one exploit chain or evidence of an active campaign. Together, however, they demonstrate that an ML platform’s trust boundary extends beyond the model to webhooks, tracking, lineage, the registry, artifacts and the policy connecting them.

The highest-priority issue is CVE-2026-64849, scored 9.3 under CVSS 3.1. Its affected webhook test endpoint could be unauthenticated on a default tracking-server configuration. The other two issues require an account and affect deployments using basic-auth with separated permissions for runs, experiments and models.

CVE-2026-64849: validating the first URL does not control the connection

MLflow supports model-registry webhooks. Before sending a request, its validator resolved the hostname and rejected private, loopback and link-local addresses. That sounds reasonable, but it covered only the original URL. The HTTP client could later follow a redirect and resolve a destination again without checking the actual connection address.

This creates a time-of-check/time-of-use gap. A safe public host can redirect to an internal service. DNS can also return a public address during validation and a different result at connection time. Neither string validation nor one DNS lookup is therefore a complete SSRF boundary.

The webhook test endpoint made the issue more consequential by returning the upstream status and response body. Blind SSRF became readable SSRF. From MLflow’s network position, a request could reach loopback, an internal administration service or cloud instance metadata. Actual impact depends on segmentation, metadata configuration and the permissions assigned to the workload.

MLflow 3.15.0 adds enforcement when each connection is established. The peer address is checked before HTTP exchange, including connections created for redirects, closing both redirect destination changes and DNS races. This is stronger than repeatedly parsing Location because it governs the endpoint the socket actually reaches.

Why egress remains necessary after updating

Application validation is one layer. An MLflow server needs an egress policy blocking cloud metadata, management networks, databases, orchestrator APIs and local administrative ports. Where webhooks only target approved systems, a domain allowlist or outbound broker is stronger still.

The reverse proxy should authenticate administrative and webhook APIs. “The tracking server is internal” is not a control when a mistaken ingress rule, developer tunnel or temporary environment can expose it. Inventory notebooks, experimental copies and demo deployments as well as the official production service.

Telemetry should record the original host, redirect chain, normalised destination and policy decision without retaining secrets from query strings. Alert on attempts to reach non-public addresses, unusual ports and repeated anonymous webhook tests.

CVE-2026-69146: a missing handler removes UPDATE enforcement

MLflow basic-auth maps request classes to permission validators. Normal operations writing metrics, parameters and tags check whether the user may modify a run. LogInputs was absent from that map. A missing validator meant execution continued rather than failing closed.

The CVE-2026-69146 advisory describes adding attacker-controlled DatasetInput records to another user’s run. This does not expose weights or execute code, but it violates lineage integrity. In systems using provenance for compliance, reproducibility or promotion decisions, false lineage can materially change trust in a model.

The flaw is a fail-open route-registry pattern. A new endpoint should not become reachable until an explicit policy exists. Safer design denies requests or prevents startup when an authorisation mapping is missing. A completeness test should compare every mutating operation with the validator table.

After updating, review lineage changes made by an identity other than the run owner, especially where no other legitimate UPDATE operations exist. An audit record is not trustworthy merely because it resides in an MLflow table.

CVE-2026-69148: a safe path is not an authorised source

When creating a model version, MLflow checked whether its artifact path remained inside the directory of a specified run or model. That controls path traversal. It did not establish whether the caller had READ permission on the referenced run_id or model_id.

The CVE-2026-69148 advisory illustrates the difference between path integrity and object authorisation. A user managing their own model could create a version referencing a valid artifact directory belonging to another user’s run. The model-version artifact endpoint then trusted the new relationship and returned files without reapplying the experiment’s access decision.

Potentially exposed files include weights, training samples, evaluation reports and other run artifacts. The issue matters most where teams actually have separated experiments. If every user already has READ everywhere, the CVE adds no new read, although it still reveals a broken policy contract.

Authorisation must be enforced when a reference is created and when it is followed. Persisting a relationship must not launder the origin of a resource. A robust design preserves source ownership and makes a fresh policy decision on every artifact download.

An action plan for MLflow owners

Upgrade all tracking and registry servers to MLflow 3.15.0 or a later supported release. Inspect container images, notebook-launched servers and standalone processes. A client library’s version does not prove the server version.

Require edge authentication, restrict webhook APIs and deny internal-address egress. Review the cloud identity assigned to the MLflow workload; it should have no broader access than the artifact store needs. Enable token-requiring metadata-service modes as another barrier where available.

Review the experiment–run–model–artifact permission matrix. Negative tests must prove that user A cannot add lineage to B’s run or create a model version leading to B’s artifacts. SSRF regression testing belongs in an isolated environment and should assert controlled denial across redirects without targeting real sensitive services.

If telemetry indicates metadata or artifact access, handle it as an incident. Revoke potentially exposed cloud credentials, analyse file downloads and verify lineage integrity behind production decisions.

Facts and Breachroad conclusions

It is a fact that the three records published on 17 August cover unauthenticated SSRF, lineage mutation without the required UPDATE permission and artifact reads caused by missing source-run authorisation. MLflow 3.15.0 contains fixes. The sources do not demonstrate widespread active exploitation.

Breachroad’s conclusion is that an ML platform is a multi-tenant system holding code, data and credentials. URL validation, path containment and authentication each protect a different boundary. Without object authorisation and network controls, combining them still leaves exploitable gaps.

MLOps and development teams can build these practices through our AI security training for organisations. Platform architecture and permissions can also be examined through AI red teaming and API testing.