CVE-2025-71366: picklescan: scan bypass lets malicious pickle RCE

HIGH CISA: TRACK*
Published July 4, 2026
CISO Take

picklescan, one of the de-facto scanners used to vet pickle-format ML model files before they are loaded, fails to flag a specific malicious pattern — a pickle file that calls torch.utils.bottleneck.__main__.run_cprofile — meaning a crafted model artifact sails through the safety check and still achieves arbitrary code execution the moment someone deserializes it with pickle.load or torch.load. This matters less because of raw severity (CVSS 8.1, no privileges needed) and more because it undermines a trust control: any pipeline, model hub mirror, or CI job that treats a picklescan 'clean' verdict as sufficient proof a model artifact is safe is currently wrong for this specific gadget. There is no CISA KEV listing, no published EPSS score, and no public exploit code or Nuclei template as of this writing, so this is not an actively-exploited or scanner-automatable threat today — but the low complexity of the bypass (a single well-known torch function) means a working payload is trivial to reproduce once attackers notice this advisory. Action: upgrade picklescan to >=0.0.28 everywhere it gates model ingestion (CI, model registries, Hugging Face mirrors, internal MLOps pipelines), and until upgraded, do not treat a picklescan pass as sufficient — prefer safetensors or other non-pickle serialization for any model artifact of unknown provenance, and alert on any pickle deserialization event that imports torch.utils.bottleneck.__main__.run_cprofile.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

CVSS 8.1 (High) with network attack vector, low complexity, and no privileges required reflects a genuinely dangerous end-state (full code execution, high confidentiality and integrity impact) gated only by required user interaction — someone has to load the file. The mitigating factors are the absence of EPSS scoring, no CISA KEV listing, no public exploit, and no scanner template, indicating this is not yet a mass-exploited or weaponized bug. The real risk driver is architectural: this is a defense-evasion bug in a security control (picklescan) rather than a bug in an application directly exposed to attackers, so its blast radius is proportional to how many organizations rely on picklescan as their sole gate for untrusted pickle/model files. Organizations using picklescan purely as an automated CI/registry gate without a secondary control (sandboxing, safetensors migration, provenance checks) carry materially higher exposure than those using it as one layer among several.

How does the attack unfold?

Malicious artifact creation
Attacker crafts a pickle-format model file embedding a call to torch.utils.bottleneck.__main__.run_cprofile designed to execute arbitrary code on load.
AML.T0018.002
Scan gate bypass
The target's ingestion pipeline runs picklescan (<0.0.28) as an automated safety check, which fails to flag the embedded call and marks the file as safe.
AML.T0010.001
Victim deserialization
A developer or automated MLOps job loads the 'cleared' file via pickle.load/torch.load, triggering deserialization of the malicious payload.
AML.T0011.000
Arbitrary code execution
The embedded function executes attacker-controlled code with the privileges of the loading process, giving the attacker code execution inside the training or inference environment.
AML.T0050

What systems are affected?

Package Ecosystem Vulnerable Range Patched
picklescan pip No patch
418 3 dependents Pushed 25d ago 53% patched ~12d to patch Full package profile →

Do you use picklescan? You're affected.

How severe is it?

CVSS 3.1
8.1 / 10
EPSS
0.4%
chance of exploitation in 30 days
Higher than 37% 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 is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR None
UI Required
S Unchanged
C High
I High
A None

What should I do?

1 step
  1. 1) Upgrade picklescan to version 0.0.28 or later in every pipeline stage where it acts as a gate (CI, model registry ingestion, pre-deployment scanning). 2) Until upgraded, do not treat a 'safe' picklescan verdict as authoritative for untrusted or externally-sourced pickle files — add a second control such as running the scan plus sandboxed/ephemeral deserialization, or migrating to safetensors for model weights where feasible. 3) Detection: monitor/alert on deserialization events or process telemetry showing torch.utils.bottleneck.__main__.run_cprofile being invoked outside of legitimate profiling workflows. 4) Audit existing model artifact stores for pickle files that were previously cleared by picklescan <0.0.28 and re-scan them with the patched version. 5) Where possible, enforce a policy preferring non-pickle serialization formats for any model sourced from outside the organization.

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 requirements for AI systems
NIST AI RMF
MANAGE-2.3 - Risks associated with third-party AI resources are identified and managed
OWASP LLM Top 10
LLM05:2025 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2025-71366?

picklescan, one of the de-facto scanners used to vet pickle-format ML model files before they are loaded, fails to flag a specific malicious pattern — a pickle file that calls torch.utils.bottleneck.__main__.run_cprofile — meaning a crafted model artifact sails through the safety check and still achieves arbitrary code execution the moment someone deserializes it with pickle.load or torch.load. This matters less because of raw severity (CVSS 8.1, no privileges needed) and more because it undermines a trust control: any pipeline, model hub mirror, or CI job that treats a picklescan 'clean' verdict as sufficient proof a model artifact is safe is currently wrong for this specific gadget. There is no CISA KEV listing, no published EPSS score, and no public exploit code or Nuclei template as of this writing, so this is not an actively-exploited or scanner-automatable threat today — but the low complexity of the bypass (a single well-known torch function) means a working payload is trivial to reproduce once attackers notice this advisory. Action: upgrade picklescan to >=0.0.28 everywhere it gates model ingestion (CI, model registries, Hugging Face mirrors, internal MLOps pipelines), and until upgraded, do not treat a picklescan pass as sufficient — prefer safetensors or other non-pickle serialization for any model artifact of unknown provenance, and alert on any pickle deserialization event that imports torch.utils.bottleneck.__main__.run_cprofile.

Is CVE-2025-71366 actively exploited?

No confirmed active exploitation of CVE-2025-71366 has been reported, but organizations should still patch proactively.

How to fix CVE-2025-71366?

1) Upgrade picklescan to version 0.0.28 or later in every pipeline stage where it acts as a gate (CI, model registry ingestion, pre-deployment scanning). 2) Until upgraded, do not treat a 'safe' picklescan verdict as authoritative for untrusted or externally-sourced pickle files — add a second control such as running the scan plus sandboxed/ephemeral deserialization, or migrating to safetensors for model weights where feasible. 3) Detection: monitor/alert on deserialization events or process telemetry showing torch.utils.bottleneck.__main__.run_cprofile being invoked outside of legitimate profiling workflows. 4) Audit existing model artifact stores for pickle files that were previously cleared by picklescan <0.0.28 and re-scan them with the patched version. 5) Where possible, enforce a policy preferring non-pickle serialization formats for any model sourced from outside the organization.

What systems are affected by CVE-2025-71366?

This vulnerability affects the following AI/ML architecture patterns: model serving, training pipelines, MLOps / model registry ingestion, CI/CD model artifact scanning.

What is the CVSS score for CVE-2025-71366?

CVE-2025-71366 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.45%.

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesMLOps / model registry ingestionCI/CD model artifact scanning

MITRE ATLAS Techniques

AML.T0010.001 AI Software
AML.T0011 User Execution
AML.T0011.000 Unsafe AI Artifacts
AML.T0018.002 Embed Malware

Compliance Controls Affected

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

What are the technical details?

Original Advisory

picklescan before 0.0.28 fails to detect malicious torch.utils.bottleneck.__main__.run_cprofile function calls in pickle files, allowing attackers to bypass safety checks. Remote attackers can embed undetected code in pickle files to achieve arbitrary code execution when victims load the files.

Exploitation Scenario

An attacker packages a malicious PyTorch checkpoint (a pickle file) that includes a reference to torch.utils.bottleneck.__main__.run_cprofile crafted to execute attacker-controlled code, and uploads it to a public model repository, a compromised internal artifact store, or sends it directly to a target (e.g., via a 'try my fine-tuned model' social-engineering pretext). The victim organization's ingestion pipeline runs picklescan as an automated safety gate; because picklescan <0.0.28 does not recognize this specific function as dangerous, the file is marked clean and allowed to proceed. A data scientist or an automated deployment job then loads the file with torch.load or pickle.load, at which point the embedded call executes with the privileges of the loading process — giving the attacker code execution inside the training/inference environment, potentially with access to credentials, other models, or downstream infrastructure.

Weaknesses (CWE)

CWE-502 — Deserialization of Untrusted Data: The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.

  • [Architecture and Design, Implementation] If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
  • [Implementation] When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Timeline

Published
July 4, 2026
Last Modified
July 6, 2026
First Seen
July 4, 2026

Related Vulnerabilities