Download the latest Vulnerability & Exploitation Report

Download now

MLflow Authentication Bypass (CVE-2026-2652): When “Login Required” Only Applies to Half the Doors

The CrowdSec Network is tracking steady exploitation of CVE-2026-2652, a CVSS 8.6 authentication bypass in MLflow, the open-source platform most data science teams use to track experiments and ship machine learning models. Servers running with authentication switched on still leave part of their API open to anyone who can reach them.

Key Findings

  • Fixed in February, published in May, attacked since July: MLflow’s maintainers patched the flaw on February 18, 2026, and shipped it in version 3.10.0 two days later, but the CVE was only published on May 15. CrowdSec released a detection rule on June 24 and recorded the first in-the-wild attempt on July 20. That gap between a quiet code fix and public awareness is the window attackers work in.
  • 129 unique IP addresses, and the curve is turning up: Across our observation window, we logged 352 exploitation signals, averaging around 21 per day with a peak of 67. The CVE sits in our “Limited Exploitation” phase, yet the final days on the graph are the highest of the entire period.
  • The public exploit is a single request: A Nuclei detection template published by DhiyaneshDk shows the whole attack: send an empty POST to /ajax-api/3.0/jobs/search and see whether the server answers with a job list. No credentials, no exploit chain, no skill required.
  • Attackers want the machine, not the models: 79% of the attempts we observe map to infrastructure takeover, 17% to ransomware staging, and only 5% to data theft. The MLflow server is the prize, not the experiments inside it.

What is MLflow?

MLflow is the open-source tool teams use to keep machine learning work organized. It records experiments, stores model artifacts, maintains a registry of which model version runs in production, and more recently runs jobs and collects traces from AI applications. Data scientists, ML engineers, and MLOps teams live in it daily.

Why it matters: An MLflow server rarely stands alone. To do its job, it holds credentials for object storage, a backing database, and often the compute that trains and serves your models, wired into data pipelines, CI/CD, and production inference. Whoever reaches the job API is not looking at a tracking dashboard; they are standing at a junction with connections into several parts of your infrastructure. That is a blast radius well out of proportion to what the tool appears to be. Our data backs this up on the exposure side: 55% of targeted organizations are in commerce, and 34% are small offices, which describes MLflow running on a box someone spun up for a project rather than a hardened cluster.

How does CVE-2026-2652 work?

MLflow ships an optional basic authentication mode, enabled with --app-name basic-auth. The application is a hybrid: older routes are served by Flask, newer ones by FastAPI. When the server runs behind uvicorn, the FastAPI permission middleware only enforces credentials on routes beginning with /gateway/. Everything else on the FastAPI side is served with no check at all, including the Job API under /ajax-api/3.0/jobs/* and the trace ingestion endpoint /v1/traces.

The root cause is small with large consequences. The helper responsible for picking the right permission validator, _find_fastapi_validator(), returned nothing for paths it did not recognize, and “no validator found” ended up being treated as “no restriction to apply” (CWE-305). It is the kind of gap that appears when two frameworks are stitched together, and each assumes the other is handling the door.

For an administrator, the effect is worse than having no authentication at all. You enable basic auth, you get a login prompt in your browser, and you reasonably conclude the server is protected. Meanwhile, anyone who can reach it over the network can list jobs, submit new ones, read their results, cancel running work, and push fabricated traces into your experiments.

That last one deserves a moment. Trace injection sounds cosmetic next to code execution, but traces are what teams use to evaluate whether a model behaves correctly. Poisoning them poisons the evidence a business uses to decide whether its AI system is working.

The vulnerability was reported through huntr, the bug bounty platform dedicated to AI/ML projects, which also acted as the CVE assigner.

This flaw has relatives. CVE-2026-0545 (CVSS 9.1) covers the same unprotected job endpoints and goes further: where job execution is enabled, and a job function is allowlisted, an unauthenticated attacker can reach code execution. MLflow also patched an unauthenticated arbitrary file read (CVE-2026-2614) and a default-credentials bypass (CVE-2026-2635) in the same period. Access control has not kept pace with how fast MLflow’s API surface is growing, and attackers have noticed.

Threat Landscape Analysis

CrowdSec has been watching this CVE since our rule went live on June 24, 2026, with exploitation starting July 20. Since then, 129 unique IP addresses have attacked it across our network, generating 352 signals over 17 days with as many as 26 distinct sources active on a single day.

The attacking infrastructure is led by the Netherlands (27% of attacking IPs) and Singapore (16%), followed by the United States, Ireland, and Czechia at 11% each. That reads as rented cloud hosting rather than a compromised-device botnet, which fits what our data says about the campaign: selective, reconnaissance-driven activity from actors who pick their targets rather than spray the internet. Targeted organizations concentrate in Germany (20%) and France (19%), then the United States and Switzerland at 12% each.

The part worth flagging is the shape of the graph. Attacks held at a modest baseline for two weeks, then the last data point of our window jumped to the highest volume we have recorded for this CVE. “Limited Exploitation” here describes how many exposed MLflow servers exist, not how much trouble each one is in. With a one-request public exploit and job endpoints that lead straight into cloud credentials, the servers that are exposed are trivially taken.

How to protect your systems

  • Patch: Upgrade MLflow to 3.10.0 or later, which contains the fix; the GitHub advisory takes the conservative line and lists 3.11.0 as the first confirmed-clean release, so target that if you can. Anything on 3.9.x or earlier running basic auth behind uvicorn is exposed. While you are in there, review MLFLOW_SERVER_ENABLE_JOB_EXECUTION and your allowlisted job functions, and replace any default credentials in basic_auth.ini.
  • Preemptive blocking: MLflow does not belong on the public internet. Put it behind a VPN or an authenticating reverse proxy, and give its service account only the storage and database permissions it genuinely needs. Where it must be reachable, place the CrowdSec WAF in front of it to filter unauthenticated requests to /ajax-api/3.0/jobs/* and /v1/traces, and subscribe to the CrowdSec Intelligence Blocklists to drop the IPs already hitting our network.
  • Stay proactive: For live monitoring of how this CVE evolves, follow the CrowdSec Live Exploit Tracker for CVE-2026-2652.

Unsure about where to start?: Check out our special 3-minute introduction track at: https://start.crowdsec.net

Sharing insights and taking swift action can collectively reduce the impact of these threats. This is your call to action for real-time threat intelligence and collaborative cybersecurity.

Want to stay ahead of the latest cyber threats? Get our weekly Threat Alert Newsletter delivered straight to your inbox, along with critical threat updates and trending cybersecurity insights. 📩 Sign up now for exclusive access

If you’re already subscribed, feel free to like and share this post to help your network stay informed about current threats.

WRITTEN BY