Mlflow CVE-2026-0545

Job execution must be explicitly enabled via MLFLOW_SERVER_ENABLE_JOB_EXECUTION=true environment variable (non-default configuration). At least one job function must be present in the allowlist for job submission to succeed - without allowlisted functions, the authentication bypass exists but job execution fails. Network reachability to MLflow server's /ajax-api/3.0/jobs/* endpoints is required (AV:N). No authentication, user interaction, or elevated privileges needed (PR:N/UI:N). Maximum impact (RCE) requires allowlisted job functions that perform privileged actions such as shell execution, filesystem writes, or network requests. Even 'safe' job configurations remain vulnerable to authentication bypass, enabling job spam DoS and data exposure. Default MLflow installations without MLFLOW_SERVER_ENABLE_JOB_EXECUTION are NOT vulnerable. Limits exploitation: Feature must be explicitly enabled, reducing attack surface compared to vulnerabilities in default configurations.

CVSS 9.8 indicates maximum severity based on network attack vector, no authentication, and high confidentiality/integrity/availability impact. However, real-world risk is conditional: exploitation requires MLFLOW_SERVER_ENABLE_JOB_EXECUTION=true AND allowlisted job functions, which are non-default configurations. SSVC framework reports POC availability and automatable exploitation with partial technical impact. EPSS 0.20% (42nd percentile) suggests low observed exploitation activity despite POC existence, indicating defenders are either mitigating via configuration or attackers are not widely targeting MLflow deployments. No CISA KEV listing at time of analysis. Risk is HIGH for organizations running MLflow with job execution enabled and internet-facing deployments, MEDIUM for isolated internal deployments with job execution, LOW for default installations without job execution features. The authentication bypass alone (even without RCE) enables job spam DoS and data exposure, making this exploitable even in supposedly 'safe' job configurations. Priority depends on deployment model: internet-facing MLflow with job execution warrants immediate action; internal research deployments with network segmentation can schedule remediation during maintenance windows.

A remote attacker identifies an internet-facing MLflow server (port 5000 default, discoverable via Shodan or banner grabbing) running with job execution enabled. Using the publicly available POC, the attacker sends unauthenticated HTTP POST requests to /ajax-api/3.0/jobs/submit with a crafted job payload invoking an allowlisted function that executes shell commands (e.g., model training scripts with os.system() calls). The attacker gains arbitrary code execution in the MLflow server context, potentially accessing ML models, training data, cloud credentials in environment variables, or pivoting to adjacent infrastructure. Even if allowlisted jobs are deemed non-privileged, the attacker can flood the job queue causing denial of service, or retrieve job results containing sensitive hyperparameters or dataset metadata.