CVE-2026-0596

What it actually does

This vulnerability is a local, authenticated command injection flaw in MLflow model serving when `enable_mlserver=True` is used. The vulnerable code embeds the supplied `model_uri` directly into a command executed through `bash -c` without safely quoting or validating shell metacharacters. A user who can influence the model URI can include command substitution syntax such as `$()` or backticks, causing arbitrary operating-system commands to execute with the privileges of the MLflow serving process. Because model-serving services may run with broader filesystem, credential, or network access than the user who supplied the model path, exploitation can result in privilege escalation, data theft, service tampering, or full compromise of the serving host.

Why it matters to the business

An attacker with access to create or influence served model paths could turn MLflow model serving into a way to run unauthorized commands on the underlying system. In practical terms, this can expose models, datasets, credentials, experiment artifacts, and connected infrastructure, and may disrupt production inference services. The issue is not currently listed in CISA KEV and has low EPSS at 0.01328 with no known public exploit maturity reported, but the impact is high where MLflow is used in shared data science or MLOps environments because lower-privileged users may be able to trigger code execution in a higher-privileged service context.

How an attack unfolds

An attacker first needs legitimate local or application-level access sufficient to place, register, or request serving of a model using MLflow with MLServer integration enabled. They craft a malicious `model_uri` that looks like a model location but includes shell metacharacters, for example command substitution using `$()` or backticks. When MLflow starts serving the model with `enable_mlserver=True`, it builds a shell command containing that URI and passes it to `bash -c`. The shell evaluates the injected syntax before executing the intended serving command, causing the attacker-supplied command to run as the MLflow service user. The attacker can then read sensitive files, write or modify artifacts, download additional tooling, create persistence, access cloud or service credentials available to the process, or interfere with model-serving availability.

How to fix it

Upgrade MLflow to a version that contains an official fix as soon as one is available from the project or distribution maintainer. No fixed version was provided in the supplied vulnerability data, so organizations should monitor MLflow release notes and security advisories for the corrected release. Until patched, avoid using `enable_mlserver=True` with model URIs controlled by untrusted or lower-privileged users. Restrict who can register, modify, or serve models; ensure model artifact directories are not writable by users who should not be able to execute code as the serving service; and run MLflow serving under a dedicated least-privileged account. Where possible, avoid shell-mediated execution paths, enforce allowlists for model URI schemes and paths, reject shell metacharacters in model URIs, and isolate model-serving workloads in containers or sandboxes with limited filesystem, network, and credential access.

How to confirm the fix worked

Inventory MLflow deployments and confirm whether model serving is used with `enable_mlserver=True`. Review service definitions, notebooks, CI/CD jobs, deployment manifests, and MLflow serving commands for MLServer integration. Attempt a safe validation in a non-production environment by providing a benign model URI containing shell metacharacters and confirming that it is rejected or treated as literal data rather than executed. Verify that MLflow has been upgraded to a patched release once available, and confirm that lower-privileged users cannot write to directories or registries from which higher-privileged services automatically serve models. Validate runtime controls by confirming the MLflow service account has minimal permissions and that process monitoring would alert on unexpected child processes spawned by MLflow or MLServer.

Typical attack path

1. Gain access to an MLflow workflow, host, or service where the attacker can influence a model URI or model-serving request.
2. Identify that MLflow model serving is configured to use MLServer by setting `enable_mlserver=True`.
3. Create or reference a model URI containing shell metacharacters such as `$()` or backticks.
4. Trigger MLflow to serve the malicious model URI.
5. MLflow constructs a shell command and executes it through `bash -c`.
6. The shell evaluates the attacker-controlled command substitution embedded in the model URI.
7. Attacker-controlled commands execute with the privileges of the MLflow serving process.
8. Use the resulting execution context to access files, credentials, artifacts, networks, or to disrupt the model-serving service.

How to detect it

Review MLflow, MLServer, application, audit, and process execution logs for suspicious model URIs containing shell metacharacters or command substitution syntax. Pay particular attention to model-serving actions that include `enable_mlserver=True` and model URIs containing `$(`, backticks, semicolons, pipes, redirects, encoded newlines, or chained shell commands. On hosts, examine endpoint detection telemetry, Linux audit logs, shell history, and process accounting for `bash -c` spawned by MLflow, Python, or MLServer processes, especially if followed by utilities such as `curl`, `wget`, `nc`, `bash`, `sh`, `python`, `chmod`, `chown`, `id`, `whoami`, or credential-access commands. Investigate unexpected outbound network connections from MLflow-serving hosts, creation of files in temporary directories, modifications to model artifact paths, new cron/systemd entries, and access to credentials or cloud metadata services after model-serving events. Because no specific public exploit indicators are known from the supplied data, detection should focus on behavioral evidence of shell injection and abnormal child processes from the MLflow serving stack.

• enable_mlserver=True
• bash -c
• model_uri
• $(
• `
• ;curl
• ;wget
• |curl
• |wget
• /bin/bash -c
• /bin/sh -c
• mlflow
• mlserver
• whoami
• id
• chmod +x
• /tmp/
• /var/tmp/
• curl http
• wget http
• nc -e
• bash -i
• /dev/tcp/
• crontab -e
• /etc/cron.d/
• /etc/systemd/system/

What your security team should do

• Prioritize inventory of MLflow model-serving deployments, especially shared MLOps platforms where multiple users can register or serve models.
• Identify and restrict any use of `enable_mlserver=True` until a patched MLflow version is deployed or compensating controls are in place.
• Remove write access for lower-privileged users to model directories, artifact stores, or registry entries that are served by higher-privileged MLflow services.
• Run MLflow and MLServer under dedicated least-privileged service accounts with restricted filesystem, network, and credential access.
• Add validation or allowlisting for model URI schemes and paths; reject `$()`, backticks, semicolons, pipes, redirects, and newline characters where model URIs are accepted.
• Monitor for suspicious process creation where MLflow, Python, or MLServer spawns shells or system administration utilities.
• Review recent MLflow model-serving logs and shell/process telemetry for evidence of command substitution or unexpected child processes.
• Track upstream MLflow advisories and deploy the fixed version immediately when published.