CVE-2026-0545 is a critical (CVSS 9.8) missing authentication flaw in MLflow. When the basic-auth app is on, the FastAPI job endpoints under /ajax-api/3.0/jobs are not protected, so anyone can submit and cancel jobs. Red Hat advises setting MLFLOW_SERVER_ENABLE_JOB_EXECUTION to false.
What's affected
The record says the issue affects the latest version of the repository at the time of the report, and it names no fixed version. Check the MLflow release notes and the huntr report for a fix.
Exposure needs all of these: the basic-auth app enabled, job execution enabled (MLFLOW_SERVER_ENABLE_JOB_EXECUTION set to true), and at least one job function on the allow list.
How to check if you're exposed
pip show mlflow
echo $MLFLOW_SERVER_ENABLE_JOB_EXECUTION
If you run MLflow as a service, read the service definition or container environment for the same variable. Also check whether the server is reachable from outside a private network.
What to do now
- Set MLFLOW_SERVER_ENABLE_JOB_EXECUTION to false and restart the server. This is the mitigation in the Red Hat entry.
- Check the MLflow release notes for a version that fixes the endpoints, and upgrade when one is confirmed.
- Review the job function allow list and remove functions that run shell commands or change files.
- Put MLflow behind a gateway that enforces authentication on every path, not only the basic-auth app.
- Review job history for entries you did not submit.
Job execution is a feature that many teams switch on for convenience, so check whether you really use it. If not, leave it off. If you do, list the job functions on the allow list and ask what each one can reach. A job that only reads metadata is a low concern. A job that runs a shell command or changes files is the one the record flags.
Do not rely on basic-auth alone for a service like this. Put MLflow behind a gateway or VPN that applies authentication to every path, including routes added in later versions. That way, a new endpoint cannot appear outside the protection by accident.
Model tracking servers often hold run history, parameters and artifact locations, which can include cloud storage credentials. If a server was reachable while job execution was on, review the job history and rotate any credentials stored there.
Why it matters
The weakness is CWE-306 (missing authentication for a critical function). The basic-auth layer protected the original routes, and the newer job routes were added outside that protection. Anything that exposes job submission without a check is close to remote command execution if any allowed job touches the shell or the file system.
Even if allowed jobs are harmless, the record notes that the bypass allows job spam, denial of service and data exposure. The record does not mark it as exploited, and it is not in the CISA KEV list.
This is a good example of a new feature that missed an old control. Basic-auth was added as a layer over the original server. A set of new endpoints was added later as a separate application, and nothing joined them to the layer. The effect is that turning on authentication gives a false feeling of safety.
When you assess any tool like this, test the claim in practice. From a machine that has no credentials, try to reach each path you know about, and see which ones ask for a login. Do this after every upgrade, because new routes appear.
Try it yourself
Not every critical score deserves the same urgency. The exploitability view helps separate it from your actual configuration.
Click through it at your own pace, or open it full screen.
Quick check
Am I exposed if job execution is off?
The record ties exposure to job execution being enabled, so turning it off is the stated mitigation.
If you want a quick look at your own dependencies, the free in-browser scan at gold.safeguard.sh/scan needs no repository access.
Sources
Fetched for this guide:
Also referenced by the CVE record:
Last reviewed: 19 October 2026.
