CVE-2026-8387: ClearML: path traversal in zip extraction enables RCE
UNKNOWN CISA: TRACK*ClearML's StorageManager extracts dataset, artifact, model, and offline-session zip archives with Python's ZipFile.extractall() and no path traversal validation, letting a crafted archive write files anywhere on the filesystem the ClearML process can reach. That arbitrary write is a direct path to remote code execution through cron job injection, SSH authorized_keys overwrite, or web shell drop — turning any of ClearML's normal download flows into a compromise vector for ML training and orchestration infrastructure. There is no CVSS score, EPSS data, CISA KEV listing, public exploit, or Nuclei template for this CVE yet, and the package carries only one other CVE and a mediocre 4.9/10 OpenSSF Scorecard, so this looks unweaponized today but sits in a widely-relied-upon MLOps package (25 downstream dependents). Patch to ClearML 2.1.6 or later immediately, and until then treat any dataset, model, or artifact pulled from a shared or public ClearML server as untrusted input, since the attack requires no special privileges beyond getting a victim agent to download a poisoned archive. Monitor ClearML agent hosts for unexpected cron entries, modified authorized_keys, or new web-accessible files as a compensating detection control.
What is the risk?
The flaw itself (CWE-23, classic Zip Slip pattern) is well understood and not technically hard to exploit — crafting a zip with '../' path traversal entries is trivial with public tooling. What raises the bar is delivery: an attacker needs their poisoned dataset, artifact, model, or offline session archive to actually be pulled by a victim's ClearML server or agent, which typically means compromising or impersonating a shared registry/server, or social-engineering a user into importing a malicious offline session. No CVSS vector, EPSS score, KEV listing, public PoC, or scanner template exists yet, so near-term opportunistic exploitation is unlikely, but the eventual impact — arbitrary file write escalating to full RCE via cron/SSH/web shell — is severe for any ML training or orchestration host. The package's low OpenSSF Scorecard (4.9/10) and its role as shared infrastructure for 25 downstream dependents mean the blast radius is meaningful in any organization running shared or multi-tenant ClearML deployments.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| ClearML | pip | — | No patch |
Do you use ClearML? You're affected.
How severe is it?
What should I do?
1 step-
Upgrade allegroai/clearml to version 2.1.6 or later immediately across all servers and agents. Until patched, restrict who can publish datasets, artifacts, models, or offline sessions that automated ClearML agents will consume, and treat any archive from a shared or public ClearML instance as untrusted. Run ClearML agents in sandboxed, non-root containers with a restricted filesystem so a path-traversal write cannot reach sensitive locations like ~/.ssh or cron directories. Audit StorageManager cache paths and host filesystems for files written outside expected directories, and add detection for new cron entries, modified authorized_keys files, or unexpected web-servable files appearing after artifact pulls.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-8387?
ClearML's StorageManager extracts dataset, artifact, model, and offline-session zip archives with Python's ZipFile.extractall() and no path traversal validation, letting a crafted archive write files anywhere on the filesystem the ClearML process can reach. That arbitrary write is a direct path to remote code execution through cron job injection, SSH authorized_keys overwrite, or web shell drop — turning any of ClearML's normal download flows into a compromise vector for ML training and orchestration infrastructure. There is no CVSS score, EPSS data, CISA KEV listing, public exploit, or Nuclei template for this CVE yet, and the package carries only one other CVE and a mediocre 4.9/10 OpenSSF Scorecard, so this looks unweaponized today but sits in a widely-relied-upon MLOps package (25 downstream dependents). Patch to ClearML 2.1.6 or later immediately, and until then treat any dataset, model, or artifact pulled from a shared or public ClearML server as untrusted input, since the attack requires no special privileges beyond getting a victim agent to download a poisoned archive. Monitor ClearML agent hosts for unexpected cron entries, modified authorized_keys, or new web-accessible files as a compensating detection control.
Is CVE-2026-8387 actively exploited?
No confirmed active exploitation of CVE-2026-8387 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-8387?
Upgrade allegroai/clearml to version 2.1.6 or later immediately across all servers and agents. Until patched, restrict who can publish datasets, artifacts, models, or offline sessions that automated ClearML agents will consume, and treat any archive from a shared or public ClearML instance as untrusted. Run ClearML agents in sandboxed, non-root containers with a restricted filesystem so a path-traversal write cannot reach sensitive locations like ~/.ssh or cron directories. Audit StorageManager cache paths and host filesystems for files written outside expected directories, and add detection for new cron entries, modified authorized_keys files, or unexpected web-servable files appearing after artifact pulls.
What systems are affected by CVE-2026-8387?
This vulnerability affects the following AI/ML architecture patterns: training pipelines, MLOps orchestration, model registry, artifact/dataset storage, agent frameworks.
What is the CVSS score for CVE-2026-8387?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.001 AI Software AML.T0010.002 Data AML.T0010.003 Model AML.T0011.000 Unsafe AI Artifacts AML.T0050 Command and Scripting Interpreter Compliance Controls Affected
What are the technical details?
Original Advisory
A vulnerability in allegroai/clearml versions up to and including 1.16.5 allows for relative path traversal when extracting `.zip` archives using the `ZipFile.extractall()` method in `StorageManager._extract_to_cache()`. This issue arises due to the lack of path traversal validation, enabling an attacker to write arbitrary files to the filesystem. Attack vectors include dataset downloads, artifact downloads, model downloads, and offline session imports. The vulnerability can lead to remote code execution through methods such as cron job injection, SSH key overwrite, or web shell deployment. The issue is resolved in version 2.1.6.
Exploitation Scenario
An attacker publishes a poisoned dataset, model, or artifact — packaged as a zip with entries like '../../../../home/user/.ssh/authorized_keys' or '../../etc/cron.d/backdoor' — to a shared or public ClearML server, or tricks a user into importing a malicious offline session. When a victim's ClearML agent or user runs a normal pipeline step that downloads that dataset/artifact/model, StorageManager._extract_to_cache() calls ZipFile.extractall() without validating the archive's internal paths, and the traversal entries are written outside the intended cache directory to the attacker's chosen filesystem locations. The attacker now has a persistent SSH key, a scheduled cron job, or a dropped web shell on the ML training or orchestration host, granting full remote code execution and access to any credentials, training data, or model artifacts present on that machine.
Weaknesses (CWE)
CWE-23 — Relative Path Traversal: The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory.
- [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
- [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked. Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes: realpath() in C getCanonicalPath() in Java GetFullPath() in ASP.NET realpath() or abs_path() in Perl realpath() in PHP
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2025-8917 5.8 clearml: path traversal in safe_extract → RCE risk
Same package: clearml CVE-2024-2912 10.0 BentoML: RCE via insecure deserialization (CVSS 10)
Same attack type: Supply Chain CVE-2023-3765 10.0 MLflow: path traversal allows arbitrary file read
Same attack type: Supply Chain CVE-2025-5120 10.0 smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Supply Chain CVE-2025-59528 10.0 Flowise: Unauthenticated RCE via MCP config injection
Same attack type: Supply Chain