CVE-2025-15379

What it actually does

CVE-2025-15379 is a command injection vulnerability in MLflow 3.8.0 model serving container initialization. When a model is deployed with env_manager=LOCAL, MLflow reads dependency data from the model artifact's python_env.yaml file and passes values into a shell command without proper sanitization or argument isolation. A malicious model artifact can therefore cause the serving host or container to execute attacker-controlled operating-system commands during model deployment or dependency installation. Successful exploitation can provide arbitrary code execution with the privileges of the MLflow serving process, enabling data theft, model tampering, credential access, lateral movement, or service disruption.

Why it matters to the business

Organizations that accept, import, register, or deploy MLflow model artifacts from untrusted or semi-trusted sources could have model serving infrastructure compromised during deployment. Because the flaw can lead to full command execution without user interaction once a malicious model is deployed, it may affect confidentiality of models and data, integrity of production inference behavior, and availability of ML services. Although it is not currently listed in CISA KEV and has low EPSS at the time provided, the CVSS 9.8 severity means affected deployments should be treated as high priority, especially where external contributors, automated model promotion pipelines, shared registries, or CI/CD systems can introduce model artifacts.

How an attack unfolds

An attacker prepares an MLflow model artifact containing a crafted python_env.yaml dependency specification with shell metacharacters or command substitutions embedded in a field that MLflow later uses to install dependencies. The attacker then causes the artifact to be deployed through MLflow model serving with env_manager=LOCAL, such as by uploading it to a model registry, submitting it through an automated ML pipeline, or convincing an operator or deployment job to serve the artifact. During container or serving environment initialization, MLflow calls _install_model_dependencies_to_env(), reads the dependency specification, interpolates the malicious value into a shell command, and executes it. The injected command runs in the context of the MLflow serving process or container, allowing the attacker to download tooling, read environment variables and mounted secrets, modify served model files, open outbound connections, or disrupt the service.

How to fix it

Upgrade affected MLflow deployments from version 3.8.0 to version 3.8.2 or later. If immediate upgrade is not possible, do not deploy untrusted MLflow model artifacts with env_manager=LOCAL, restrict who can publish or promote models into registries and serving pipelines, require review of python_env.yaml files before deployment, and run model serving containers with least privilege, read-only filesystems where feasible, restricted egress, and no unnecessary host mounts or secrets. Prefer deployment patterns that avoid shell interpretation of artifact-controlled dependency values. Remove or quarantine model artifacts with suspicious dependency specifications containing shell metacharacters, command substitution, redirection, or network download commands.

How to confirm the fix worked

Confirm the installed MLflow version is 3.8.2 or later on all model serving images, build environments, notebooks, CI/CD runners, and deployment containers that can serve MLflow models. Review container image manifests and dependency lockfiles for mlflow==3.8.0. Attempt to deploy a benign test model with env_manager=LOCAL and a python_env.yaml value containing inert shell metacharacters in a non-production environment; the fixed version should not execute or expand the injected shell syntax. Verify model deployment policies block or flag untrusted artifacts and that production model artifacts are scanned for suspicious python_env.yaml content before serving.

Typical attack path

1. Create or modify an MLflow model artifact that includes a malicious python_env.yaml dependency entry containing shell command injection syntax.
2. Publish, upload, or otherwise place the malicious model artifact where a victim MLflow deployment process can access it.
3. Trigger or wait for deployment of the model using MLflow model serving with env_manager=LOCAL.
4. Allow MLflow initialization to process python_env.yaml and construct the vulnerable shell command.
5. Execute arbitrary operating-system commands under the MLflow serving process or container identity.
6. Use the obtained execution to access credentials, model files, datasets, network services, or to alter inference behavior and persist within the runtime environment.

How to detect it

Review MLflow model serving logs, container stdout/stderr, orchestration events, CI/CD deployment logs, model registry audit logs, and endpoint deployment records for model deployments using env_manager=LOCAL on MLflow 3.8.0. Correlate model deployment or dependency installation timestamps with suspicious child processes spawned by the MLflow process, such as shells, network download tools, interpreters, package managers, or reconnaissance utilities. Inspect deployed model artifacts, especially python_env.yaml, for shell metacharacters, command substitution, redirection, here-documents, encoded payloads, or commands such as curl, wget, bash, sh, nc, python -c, perl -e, or chmod. In containers, check for unexpected files written to /tmp, /var/tmp, application working directories, user home directories, or mounted volumes after model initialization. Review network telemetry for unusual outbound connections from MLflow serving containers during startup or dependency installation. Because no public exploit indicators or threat actor infrastructure are provided, prioritize behavior-based detection over static IOCs.

• mlflow==3.8.0
• env_manager=LOCAL
• python_env.yaml
• _install_model_dependencies_to_env
• curl
• wget
• bash -c
• sh -c
• python -c
• perl -e
• nc -e
• /bin/sh
• /bin/bash
• /tmp/
• /var/tmp/

What your security team should do

• Inventory all MLflow installations and container images; prioritize any serving workloads running MLflow 3.8.0.
• Upgrade MLflow to 3.8.2 or later and rebuild/redeploy affected model serving containers.
• Identify pipelines or registries that allow externally supplied, user-submitted, or automatically promoted model artifacts, and restrict deployment approval until patched.
• Search existing model artifacts for suspicious python_env.yaml entries containing shell metacharacters, command substitution, redirection, curl/wget, reverse shell patterns, or encoded payloads.
• Review recent MLflow serving deployments for unexpected child processes, outbound network connections, file modifications, or dependency installation failures around model initialization time.
• Harden MLflow serving runtimes with least-privilege service accounts, minimal mounted secrets, restricted network egress, container isolation, and immutable or read-only filesystem controls where practical.
• Add CI/CD or registry validation to reject model artifacts with unsafe dependency specifications before they reach serving infrastructure.