CVE-2025-15031

What it actually does

MLflow's pyfunc extraction path can write files outside the intended artifact extraction directory when it processes a crafted tar.gz archive. The vulnerable behavior stems from extracting tar archive entries without validating member paths, allowing entries that contain parent-directory traversal sequences or absolute paths to overwrite arbitrary files accessible to the MLflow process. Depending on file permissions and runtime context, this can result in modification of application code, configuration, credentials, startup scripts, SSH keys, or Python package files, potentially escalating from arbitrary file write to remote code execution when the overwritten file is later executed or loaded.

Why it matters to the business

Organizations using MLflow to ingest, register, load, or serve models from untrusted or shared sources could have ML infrastructure tampered with by a malicious artifact. In multi-tenant ML platforms, this can allow one user or pipeline to affect other users, poison model-serving environments, disrupt experiments, alter results, or gain code execution in MLflow-related workloads. Although it is not currently listed in CISA KEV and has low EPSS at publication time, the CVSS 9.1 severity and simple archive-based exploitation path make this important to prioritize wherever MLflow processes artifacts from external contributors, CI/CD pipelines, shared registries, or object storage.

How an attack unfolds

An attacker creates or supplies an MLflow model artifact containing a tar.gz archive with malicious archive member paths that escape the expected extraction directory, such as paths using parent-directory traversal or absolute filesystem locations. When MLflow's pyfunc loading or extraction workflow processes the artifact, the archive extraction routine writes those files to attacker-selected locations that the MLflow process can access. If the attacker overwrites a sensitive configuration file, Python module, model-serving file, startup hook, credential file, or other executable content, the write can be converted into persistence, privilege escalation within the application context, or remote code execution the next time that file is loaded, imported, or executed. The attack is most practical where MLflow accepts artifacts from untrusted users, automated training jobs, shared registries, or externally controlled artifact stores.

How to fix it

Upgrade MLflow as soon as a fixed release is available from the MLflow project or downstream package maintainers; no fixed version was provided in the input, so organizations should monitor upstream advisories and package repositories closely. Until a fix is deployed, do not load or extract MLflow pyfunc artifacts from untrusted sources. Restrict who can upload, register, or trigger loading of model artifacts. Run MLflow tracking, registry, and serving components with least-privilege filesystem permissions and in isolated containers or sandboxes so arbitrary writes cannot affect sensitive host paths. Validate tar archives before extraction and reject entries with absolute paths, drive-letter paths, symlinks/hardlinks to external locations, or path components containing '..'. Store artifacts in controlled repositories with provenance checks, signing, or trusted CI/CD promotion gates. Consider adding wrapper controls around artifact ingestion to scan tar.gz members and quarantine suspicious artifacts.

How to confirm the fix worked

Inventory MLflow installations and determine whether they process pyfunc artifacts, especially from shared registries, user uploads, CI/CD jobs, notebooks, object storage, or external partners. Confirm the deployed MLflow version against upstream fixed releases when available. Validate mitigation by scanning representative model artifacts and ensuring archive members cannot contain absolute paths, parent-directory traversal, unsafe links, or paths resolving outside the intended extraction directory. In a controlled non-production test, verify that malicious archive paths are rejected or safely normalized rather than written outside the extraction root. Confirm the MLflow service account cannot write to sensitive host locations, application source directories, credential stores, shell startup paths, cron/systemd locations, or global Python package directories.

Typical attack path

1. Identify an MLflow deployment, model registry, pipeline, or artifact ingestion path that processes pyfunc model artifacts.
2. Submit, upload, register, or otherwise cause MLflow to retrieve a crafted tar.gz model artifact.
3. Include archive entries whose paths escape the intended extraction directory using parent-directory traversal or absolute paths.
4. Trigger MLflow pyfunc extraction by model loading, registration, serving, evaluation, or automated pipeline processing.
5. Cause files to be written or overwritten in locations accessible to the MLflow process.
6. Leverage overwritten configuration, code, credentials, startup hooks, or importable modules to gain execution, persistence, or control over MLflow-related workloads.

How to detect it

Review MLflow tracking server, model registry, artifact repository, object storage, reverse proxy, and application logs for unusual model artifact uploads, registrations, downloads, or pyfunc load events shortly before unexpected file changes. Inspect tar.gz model artifacts received from untrusted or shared sources for archive entries containing '../', absolute paths, Windows drive paths, or symlinks/hardlinks that resolve outside the extraction directory. Use EDR, auditd, container runtime telemetry, or file integrity monitoring to identify writes by MLflow, Python, gunicorn, uvicorn, celery, notebook, or model-serving processes to locations unrelated to the configured artifact extraction directory. Investigate unexpected modifications to application code, Python site-packages, shell startup files, cron/systemd paths, SSH authorized_keys, credential/configuration files, or MLflow runtime configuration. Correlate suspicious file writes with model load, model serve, experiment run, artifact download, and registry transition events. If artifacts are stored in S3, GCS, Azure Blob, NFS, or shared storage, review object access logs for recently added tar.gz model artifacts and preserve them for forensic inspection.

• ../
• ..\\
• /etc/cron.d/
• /etc/profile.d/
• /etc/systemd/system/
• /root/.ssh/authorized_keys
• .ssh/authorized_keys
• /home/*/.ssh/authorized_keys
• /usr/local/lib/python
• site-packages/
• MLmodel
• python_model.pkl
• .tar.gz

What your security team should do

• Prioritize review of internet-facing, shared, or multi-tenant MLflow deployments and any environment that ingests artifacts from untrusted contributors.
• Temporarily block or quarantine pyfunc model artifacts from untrusted sources until a patched MLflow release or compensating validation control is in place.
• Implement archive inspection for tar.gz artifacts and reject entries containing absolute paths, parent-directory traversal, unsafe symlinks, or hardlinks.
• Run MLflow components under dedicated low-privilege accounts in containers with read-only root filesystems where feasible and tightly scoped writable directories.
• Audit recent model registrations, artifact uploads, and pyfunc load events for suspicious archives or unexpected filesystem writes.
• Monitor upstream MLflow advisories and package repositories for a fixed version, then upgrade promptly and verify the safe-extraction behavior.
• Add EDR, auditd, or file integrity monitoring on sensitive paths that should never be modified by MLflow processes.