MLflow CVEs: Why 2.14.1 Still Fails Your Scanner

If a dependency scanner just handed you a page of MLflow findings and several of them say “no fixed version available”, nothing is broken in your tooling. As of 18 August 2026 the GitHub Advisory Database lists 80 distinct advisories against the pip package mlflow — 23 critical, 43 high — and 17 of them record no patched version at all. Ten of those seventeen are a single cluster whose affected range stops at 2.14.1, which is why that exact version string turns up in searches over and over. Upgrading past 2.14.1 does not clear them, because there is nothing to upgrade to. They are a design property of loading a model, not a bug that got fixed.

That distinction is the whole job here. MLflow’s CVE record splits cleanly into vulnerabilities you close by bumping a version and vulnerabilities you close by changing where the server sits and what it is allowed to load. Treating them as one list is how teams end up with a permanently red scanner and no actual risk reduction.

The three MLflow CVE families

1. Pre-authentication file access on the tracking server. By volume this is the dominant family: path traversal, local file inclusion, arbitrary file write, and SSRF reachable on the tracking server’s HTTP surface. CVE-2023-1177 is the canonical entry — remote file access in mlflow server and mlflow ui at or below 2.2.0, fixed in 2.2.1, scored 9.3 by the reporting CNA. The pattern repeated through 2023 and 2024 in the 2.3.0, 2.9.0, 2.9.2, 2.10.0 and 2.12.1 fix lines, and it is still producing entries in the 3.x series. This family is genuinely patchable and should be treated as an application-tier upgrade obligation.

2. Authentication and authorization weaknesses. The tracking server’s auth layer has been bypassed, defaulted, and under-enforced repeatedly. CVE-2023-6014 allowed arbitrary account creation without meeting the authentication requirement (fixed 2.8.0); later entries cover default-password authentication bypass, unauthenticated FastAPI routes, and gateway secret enumeration by any authenticated user. Also patchable, and also a strong argument that MLflow’s auth should never be the only thing between an attacker and your artifact store.

3. Model and artifact loading that executes code. This is the unpatchable family, and the one the 2.14.1 searches are about.

The 2.14.1 cluster: ten advisories, zero fixed versions

On 4 June 2024, ten advisories landed at once. Each describes the same defect wearing a different model flavour: deserialization of untrusted data during model load, so a maliciously uploaded artifact runs arbitrary code on the machine that loads it. Every one is scored CVSS 8.8 and every one records first_patched_version: None.

CVE	Artifact type that triggers it	Affected range	Patched
CVE-2024-37052	scikit-learn model	>= 1.1.0, <= 2.14.1	none recorded
CVE-2024-37053	scikit-learn model (second path)	>= 1.1.0, <= 2.14.1	none recorded
CVE-2024-37054	PyFunc model	>= 0.9.0, <= 2.14.1	none recorded
CVE-2024-37055	pmdarima model	>= 1.24.0, <= 2.14.1	none recorded
CVE-2024-37056	LightGBM scikit-learn model	>= 1.23.0, <= 2.14.1	none recorded
CVE-2024-37057	TensorFlow model	>= 2.0.0rc0, <= 2.14.1	none recorded
CVE-2024-37058	LangChain AgentExecutor model	>= 2.5.0, <= 2.14.1	none recorded
CVE-2024-37059	PyTorch model	>= 0.5.0, <= 3.4.0	none recorded
CVE-2024-37060	crafted Recipe	>= 1.27.0, <= 2.14.1	none recorded
CVE-2024-37061	improper input validation on load	>= 1.11.0, <= 2.13.1	none recorded

Two details in that table matter more than the rest.

First, 2.14.1 is not a fix line, it is a publication date. It was the newest MLflow release when the advisories were written, so the upper bound records “everything up to here”, not “fixed in the next one”. Nine of the ten still carry that ceiling more than two years later.

Second, CVE-2024-37059 has been re-ranged to 3.4.0. The PyTorch-flavoured entry was extended upward as the advisory was maintained, which tells you the ceiling on the other nine is stale bookkeeping rather than evidence that 2.14.2 fixed anything. Anyone reading “affected <= 2.14.1” as “safe on 2.15” is reading a maintenance artifact, not a security boundary.

The root cause is the one this site keeps coming back to: MLflow’s flavour loaders hand serialized artifacts to the underlying framework’s deserializer, and for most of those frameworks the deserializer is pickle. If you have read the pickle problem behind ML CVEs, the mechanics are identical — __reduce__ on a crafted object, code execution at load, no exploit chain required. MLflow is not doing anything unusual. It is providing a registry-shaped delivery mechanism for a format that was never safe to load from an untrusted source.

What “no patch” actually obligates you to do

You cannot remediate this family with a version bump, so the control has to move to the artifact and the boundary around the loader.

Treat the model registry as a code repository with commit access. Anyone who can push an artifact your serving path loads has, functionally, remote code execution on your serving hosts. Apply the same review, provenance, and access controls you would apply to a deploy pipeline. Most organisations discover during this exercise that registry write access is far broader than deploy access.
Pin the loader, not just the version. Restrict which MLflow flavours your serving path is allowed to load. A platform that only ever serves sklearn and pyfunc artifacts should reject the other eight flavours at ingest rather than leaving the whole loader surface reachable.
Prefer formats that cannot execute. Where the framework supports it, store weights as safetensors and refuse pickle-backed artifacts on the registry ingest path. The malicious model file detection stack — picklescan, fickling, ModelScan — belongs in that ingest gate, not in a nightly report nobody reads.
Isolate the loading process. Load in a container with no cloud credentials mounted, no egress by default, and no access to the artifact store beyond the object it was handed. A payload that runs but cannot reach its command-and-control or read a token is a contained incident.
Record the exception, do not suppress it. These findings will never go green. Write them up once as accepted risk with the compensating controls named, and re-review when the advisory ranges change. Suppressing the rule instead means the day one of them gets a patched version, nobody notices.

The findings you should still be patching

The unpatchable cluster tends to eat all the attention, and that is a mistake, because the patchable families are the ones with a genuine pre-authentication remote attacker in the threat model. Recent 3.x entries are not a legacy problem — MLflow shipped a critical unauthenticated full-read SSRF in webhook delivery, fixed in 3.15.0, on 17 August 2026. Critical entries also cover unauthenticated access to multipart upload endpoints, command injection in model serving, environment-variable injection in AI Gateway secrets, and unauthenticated FastAPI job endpoints.

So the triage order is:

Anything unauthenticated and reachable from your network perimeter. Path traversal, SSRF, unauthenticated route, command injection. Patch on application SLAs, not data-science SLAs.
Anything in the auth layer. Bypass, default password, missing authorization check. Patch, then verify the server is not relying on MLflow auth as its only control.
The model-loading cluster. Not patchable. Handle with registry access control, format policy and process isolation as above.
Local privilege escalation, insecure temp files, resource exhaustion. Real, lower priority on a server you already treat as sensitive.

The scoring caveat applies throughout. A CVSS 8.8 that requires an authenticated user to upload an artifact you already control is a very different problem from a CVSS 7.5 unauthenticated file read on an internet-facing tracking server, and the numbers will not tell you which is which. That argument is worked through in full in reading an ML library CVE beyond the CVSS score, and the decision procedure is in the ML-stack CVE triage workflow.

Checking your own exposure

Three questions answer most of it.

Is the tracking server reachable from anywhere it should not be? MLflow was built for a trusted internal network and then deployed on the open internet constantly. The exploited Ray clusters in the ShadowRay campaign were not zero-days, they were exposed instances of a tool everyone assumed was internal, and MLflow has exactly the same failure mode. Scan your own perimeter for it rather than assuming the answer, as covered in ML model CVE tracking.

Who can write to the model registry? Enumerate the accounts, service principals and CI jobs with artifact write access, and compare that list to the list of people you would let push to production. The gap is your real exposure to the 2024-370xx cluster.

Which flavours does your serving path actually load? Most platforms load one or two. Every other flavour in that table is surface you can remove for free.

To see the MLflow entries alongside the rest of your stack — filtered to the packages you actually run, with severity, fix availability and affected-version range — use the ML stack CVE filter and paste in a requirements.txt. It answers “which of these apply to me” faster than reading eighty advisories in order.