CVE-2026-0545

What it actually does

The flaw is an authentication bypass in MLflow FastAPI job endpoints under `/ajax-api/3.0/jobs/*` when the basic-auth application is enabled. If `MLFLOW_SERVER_ENABLE_JOB_EXECUTION=true` and at least one job function is allowlisted, unauthenticated network clients can call job APIs to submit, read, search, and cancel jobs without passing basic authentication. Depending on what the allowlisted jobs can do, this can become unauthenticated remote code execution, arbitrary filesystem modification, sensitive result disclosure, or denial of service through job spam and cancellation.

Why it matters to the business

An exposed MLflow service can be controlled by anyone who can reach the job API, even if teams believe basic authentication is protecting it. This may allow attackers to run unauthorized workloads, disrupt ML or data workflows, access job outputs, modify files, consume compute resources, or pivot through privileged job functions. The risk is urgent because the issue has a critical CVSS score, is described as weaponized, and has been public for 129 days, although it is not currently listed in CISA KEV and no fixed version is provided in the input.

How an attack unfolds

An attacker first identifies an internet-accessible or internally reachable MLflow server using the basic-auth app. Instead of authenticating through normal MLflow routes, the attacker sends direct HTTP requests to the FastAPI job endpoints under `/ajax-api/3.0/jobs/*`. If job execution is enabled and any job function is allowlisted, the server processes the request without authentication or authorization checks. The attacker can then enumerate or search jobs, submit new jobs, retrieve results, or cancel existing work. If an allowlisted job accepts parameters that reach shell commands, file operations, model execution, or other privileged actions, the attacker can use the unauthenticated job submission path to execute code, alter files, exfiltrate output data, or degrade availability.

How to fix it

Upgrade MLflow as soon as an upstream fixed version becomes available; no fixed version was provided in the input. Until then, treat this as an exposure requiring compensating controls. Disable MLflow job execution by setting `MLFLOW_SERVER_ENABLE_JOB_EXECUTION=false` or removing the setting entirely where job execution is not strictly required. Remove all allowlisted job functions unless they are essential and demonstrably safe. Restrict network access to MLflow servers using firewalls, private networking, VPN, or identity-aware proxies. Enforce authentication and authorization at a reverse proxy or gateway for all `/ajax-api/3.0/jobs/*` routes, not only the standard MLflow UI/API routes. If job execution must remain enabled, isolate workers with least privilege, sandboxing, constrained service accounts, restricted filesystem access, and egress controls. Add WAF or proxy rules to block unauthenticated access to `/ajax-api/3.0/jobs/*` until the application can be patched.

How to confirm the fix worked

Verify configuration first: confirm that job execution is disabled unless explicitly required and that no unsafe job functions are allowlisted. From an unauthenticated client, send requests to representative `/ajax-api/3.0/jobs/*` endpoints and confirm they return `401 Unauthorized`, `403 Forbidden`, or are blocked at the proxy; they must not return successful `2xx` responses or job data. Repeat the test with and without an `Authorization` header to ensure the gateway and application enforce the same policy. Review reverse proxy rules to confirm `/ajax-api/3.0/jobs/` is covered by authentication middleware. If job execution is intentionally enabled, submit a controlled authorized test job and confirm that unauthorized clients cannot read, search, submit, or cancel it. Monitor after remediation for continued probes against the affected path.

Typical attack path

1. Discover a reachable MLflow tracking or application server.
2. Confirm that basic authentication is enabled on normal routes but job API routes under `/ajax-api/3.0/jobs/*` respond without credentials.
3. Check whether job execution is enabled by attempting unauthenticated job search, read, or submit operations.
4. Submit an allowlisted job with attacker-controlled parameters.
5. Retrieve job status, logs, or results through unauthenticated job read/search endpoints.
6. If job behavior permits privileged operations, use the job to execute commands, write files, access data, or stage follow-on activity.
7. Cancel legitimate jobs or flood the server with submissions to cause operational disruption.

How to detect it

Review HTTP access logs from MLflow, reverse proxies, load balancers, API gateways, and WAFs for requests to `/ajax-api/3.0/jobs/*`. Focus on requests that returned `2xx` or `3xx` without an authenticated user identity, requests missing an `Authorization` header, unexpected source IPs, and spikes in `POST` traffic, searches, reads, or cancellation activity. Compare job submission history with expected users and automation; investigate jobs created by anonymous, unknown, or unauthenticated callers. Examine MLflow server logs, worker logs, job stdout/stderr, and generated artifacts for unexpected commands, shell metacharacters, file writes, downloads, outbound callbacks, secret access, or unusual error traces. On hosts running MLflow workers, review process creation and endpoint telemetry for child processes spawned by MLflow or Python workers, especially shells, scripting interpreters, download tools, archive utilities, and network utilities. Check filesystem timestamps and artifact stores for new or modified files around suspicious job submission times. Review network telemetry for outbound connections shortly after unauthenticated job API calls. Because the bypass avoids basic-auth-protected routes, successful job endpoint requests may appear without corresponding successful basic-auth login events.

• /ajax-api/3.0/jobs/
• POST /ajax-api/3.0/jobs/
• GET /ajax-api/3.0/jobs/
• DELETE /ajax-api/3.0/jobs/
• PUT /ajax-api/3.0/jobs/
• PATCH /ajax-api/3.0/jobs/
• MLFLOW_SERVER_ENABLE_JOB_EXECUTION=true
• Authorization: Basic
• python -c
• /bin/sh -c
• /bin/bash -c
• cmd.exe /c
• powershell.exe
• curl
• wget

What your security team should do

• Immediately inventory MLflow deployments and identify any instance reachable from untrusted networks.
• Prioritize instances with `MLFLOW_SERVER_ENABLE_JOB_EXECUTION=true`, basic-auth enabled, and allowlisted job functions.
• Block or require authentication for `/ajax-api/3.0/jobs/*` at the reverse proxy or network edge while awaiting an upstream fixed version.
• Disable job execution wherever it is not business-critical.
• Review allowlisted job functions for shell execution, filesystem modification, network access, secret access, or model/plugin execution paths.
• Hunt historical access logs for unauthenticated successful requests to `/ajax-api/3.0/jobs/*`, especially `POST` requests and high-volume searches or cancellations.
• Inspect MLflow job records, worker logs, job outputs, and artifacts for unexpected submissions, commands, file writes, or data exposure.
• Apply least-privilege controls to MLflow server and worker processes, including restricted service accounts, filesystem permissions, and outbound network controls.
• Track upstream MLflow advisories and deploy the first fixed release when available.
• Because exploit maturity is listed as weaponized, treat exposed vulnerable configurations as potentially compromised until logs and job history have been reviewed.