Skip to main content
VulnerabilityPublished

CVE-2026-116692: mlflow · Code Injection

Affects mlflowSource CVE Database V5

0

Not known to be exploited · CVSS 9.8 Critical : upgrade to 3.17.0 as a priority.

Data as of 27 Oct 2026, 20:42 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.
Patch
Available – fixed in 3.17.0
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 27 Oct 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade mlflow to 3.17.0.

Affected software

ProductAffectedFixed in
mlflowmlflowAffected
  • >=3.12.0rc0 <3.17.0
Fixed in
  • 3.17.0
PyPImlflowpkg:pypi/mlflowOther threatsAffected
  • >=3.12.0rc0 <3.17.0
Fixed in
  • 3.17.0

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

Upgrade MLflow to version 3.17.0 or later, where this vulnerability is fixed. Until then, ensure that the allowed scorer packages are not writable by the server process and restrict deployment configurations to require authentication with least privilege. No other mitigations are documented. Patch status is confirmed fixed in 3.17.0.

Description

MLflow versions from 3.12.0rc0 up to but not including 3.17.0 contain a critical code injection vulnerability. This flaw allows an attacker to execute arbitrary Python code by placing a malicious module within a writable allowed package and invoking it via MLflow's artifact endpoints. The vulnerability arises because the deserialization process accepts subclasses of allowed modules rather than strictly enforcing exact module matches. Authentication-disabled deployments are fully exposed, while basic-auth deployments require elevated privileges. The issue is resolved in version 3.17.0.

References

Community reviews

Loading reviews…