CVE-2026-8387: ClearML: path traversal in zip extraction enables RCE

UNKNOWN CISA: TRACK*
Published July 1, 2026
CISO Take

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.

Sources: NVD GitHub Advisory CISA KEV OpenSSF ATLAS huntr.com

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?

Stage malicious artifact
Attacker crafts a zip archive (dataset, artifact, model, or offline session) with path-traversal entries and publishes or delivers it to a shared/public ClearML server.
AML.T0011.000
Triggered extraction
A victim's ClearML agent or user downloads or imports the archive, and StorageManager._extract_to_cache() extracts it via ZipFile.extractall() with no path validation.
AML.T0049
Persistence via arbitrary write
Traversal entries write attacker-controlled files outside the intended cache directory, such as a cron.d entry or an overwritten SSH authorized_keys file.
AML.T0050
Remote code execution
The planted cron job, SSH key, or web shell gives the attacker code execution and persistent access on the ML training/orchestration host, exposing credentials and data.
AML.T0025

What systems are affected?

Package Ecosystem Vulnerable Range Patched
ClearML pip No patch
6.8K OpenSSF 4.9 25 dependents Pushed 8d ago 50% patched ~2d to patch Full package profile →

Do you use ClearML? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
0.4%
chance of exploitation in 30 days
Higher than 29% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Moderate
Exploitation Confidence
medium
CISA SSVC: Public PoC
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What should I do?

1 step
  1. 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?

Decision Track*
Exploitation poc
Automatable No
Technical Impact partial

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:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.6.2.6 - Third-party and supplier relationships for AI system components
NIST AI RMF
MANAGE-2.3 - Third-party AI resource risk mitigation
OWASP LLM Top 10
LLM03 - Supply Chain Vulnerabilities

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

training pipelinesMLOps orchestrationmodel registryartifact/dataset storageagent frameworks

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

EU AI Act: Article 15
ISO 42001: A.6.2.6
NIST AI RMF: MANAGE-2.3
OWASP LLM Top 10: LLM03

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.

Timeline

Published
July 1, 2026
Last Modified
July 1, 2026
First Seen
July 1, 2026

Related Vulnerabilities