A vulnerability in mlflow/mlflow versions prior to 3

Based on the vendor metadata you supplied, CVE-2026-4035 affects mlflow/mlflow versions before 3.11.0 and is classified under CWE-201 with a vector of AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L. That combination strongly suggests an authenticated information-disclosure flaw with some cross-scope impact: a logged-in user can likely retrieve data they should not see, and may be able to make limited unauthorized changes around that data plane. In MLflow terms, the realistic blast radius is usually the tracking / tracing / experiment metadata layer rather than full server takeover.

The vendor's CRITICAL 9.1 overstates operational reality for most enterprises. The biggest downgrade factor is PR:L: the attacker needs a valid account first, which means this is usually post-initial-access or insider abuse, not opportunistic pre-auth compromise. The second downgrade factor is deployment shape: MLflow is commonly internal, team-scoped, and fronted by a reverse proxy or VPN, which sharply limits reachable population. That said, if your traces or experiment artifacts contain prompts, secrets, model inputs, evaluation data, or regulated content, the confidentiality impact is still very real, so this lands in HIGH, not MEDIUM.

Why this verdict

• Start at 9.1, then cut for PR:L — requiring a valid account means the attacker is already past initial access, so this is not a mass-exploitation edge bug.
• Cut again for deployment reachability — many MLflow servers are internal, VPN-gated, or reverse-proxied, so only a fraction of enterprise fleets expose a reachable target population.
• Hold at HIGH because of data sensitivity — in real MLflow estates, traces and experiment metadata can contain prompts, user content, model outputs, URLs, and sometimes credentials or tokens, making confidentiality loss materially important.

Why not higher?

I do not buy CRITICAL without pre-auth access, active exploitation, or proven code execution. The vendor vector already admits the core friction: the attacker needs privileges first, which compounds with the fact that many MLflow deployments are not broadly internet-exposed.

Why not lower?

I also would not drop this to MEDIUM by default because the confidentiality impact can be severe in AI/ML environments. A low-privilege user crossing tenant or experiment boundaries in MLflow can expose operationally sensitive data that becomes a springboard for larger compromise, even if the bug itself does not directly grant RCE.

1. Fence MLflow behind trusted access paths — Put affected MLflow servers behind VPN, private ingress, or a reverse proxy with SSO/MFA and block direct internet reachability. For a HIGH verdict, deploy this containment within 30 days if the patch is not already in flight.
2. Reduce low-privilege account sprawl — Audit local MLflow users, service accounts, default roles, and stale automation tokens; remove dormant users and tighten least privilege so a compromised low-priv account has less room to exploit the flaw. Do this within 30 days.
3. Sanitize trace and experiment logging — Strip secrets, prompts with customer data, bearer tokens, cloud keys, and internal URLs from tags, trace metadata, and evaluation payloads. This directly lowers blast radius if exploitation occurs and should be enforced within 30 days.
4. Watch for cross-project access anomalies — Alert on users reading experiments, traces, or metadata outside their normal workspace or service role. This is a practical detective control to stand up within 30 days while patch rollout proceeds.

Run this on the target host or container image where MLflow is installed. Invoke it with python3 verify_mlflow_cve_2026_4035.py or point it at a different interpreter environment with python3 verify_mlflow_cve_2026_4035.py --python /venv/bin/python; no admin privileges are required unless your Python environment is access-restricted.

#!/usr/bin/env python3
"""
verify_mlflow_cve_2026_4035.py

Best-effort local verification for CVE-2026-4035 based on the vendor-supplied
fixed version boundary (< 3.11.0 vulnerable, >= 3.11.0 patched).

Outputs exactly one of:
  VULNERABLE
  PATCHED
  UNKNOWN

Exit codes:
  0 = PATCHED
  1 = VULNERABLE
  2 = UNKNOWN
"""

import argparse
import os
import re
import subprocess
import sys


def parse_version(v):
    if not v:
        return None
    m = re.findall(r"\d+", v)
    if not m:
        return None
    parts = tuple(int(x) for x in m[:4])
    while len(parts) < 4:
        parts = parts + (0,)
    return parts


def get_version_from_current_python():
    try:
        try:
            from importlib.metadata import version
        except ImportError:
            from importlib_metadata import version  # type: ignore
        return version("mlflow")
    except Exception:
        return None


def get_version_from_other_python(python_path):
    code = (
        "try:\n"
        "    from importlib.metadata import version\n"
        "except Exception:\n"
        "    from importlib_metadata import version\n"
        "try:\n"
        "    print(version('mlflow'))\n"
        "except Exception:\n"
        "    pass\n"
    )
    try:
        out = subprocess.check_output([python_path, "-c", code], stderr=subprocess.DEVNULL, text=True, timeout=15)
        out = out.strip()
        return out or None
    except Exception:
        return None


def main():
    parser = argparse.ArgumentParser(description="Check whether local MLflow install is below 3.11.0")
    parser.add_argument("--python", help="Path to alternate Python interpreter to inspect")
    args = parser.parse_args()

    fixed = parse_version("3.11.0")
    installed = None

    if args.python:
        installed = get_version_from_other_python(args.python)
    else:
        installed = get_version_from_current_python()

    if not installed:
        print("UNKNOWN")
        return 2

    parsed = parse_version(installed)
    if not parsed:
        print("UNKNOWN")
        return 2

    if parsed < fixed:
        print("VULNERABLE")
        return 1

    print("PATCHED")
    return 0


if __name__ == "__main__":
    sys.exit(main())

Sources

1. MLflow basic authentication documentation
2. MLflow tracking server security documentation
3. MLflow tracking server deployment documentation
4. MLflow releases page
5. CISA Known Exploited Vulnerabilities catalog
6. FIRST EPSS API documentation
7. FIRST EPSS report/data documentation
8. MITRE CWE-201 definition