CVE-2025-71358: picklescan: scanner bypass enables RCE via pickle

HIGH
Published June 22, 2026
CISO Take

picklescan before 0.0.29 contains a detection bypass that allows attackers to embed arbitrary command execution payloads in pickle files using Python's `idlelib.autocomplete.AutoComplete.get_entity` function in reduce methods, completely evading the scanner. This is especially damaging because picklescan is explicitly deployed as a security gate before `pickle.load()` calls — organizations relying on it to vet externally sourced AI models from Hugging Face, S3, or research repositories now have a false assurance layer with CVSS 8.1 exposure. No public exploit or KEV listing exists yet, but the bypass path is now publicly disclosed in the GHSA advisory, sharply lowering the attacker skill bar. Upgrade picklescan to 0.0.29 immediately and layer model sandboxing or process isolation as defense-in-depth; also prefer SafeTensors over pickle format wherever possible.

Sources: NVD GitHub Advisory VulnCheck ATLAS

What is the risk?

High risk in AI/ML environments. The CVSS 8.1 reflects a low-complexity network-vector attack requiring only user interaction — loading a pickle file. The real amplification comes from the trust model: teams that use picklescan assume scanned files are safe, converting a hardened pipeline into a false-confidence liability. Any organization downloading models from external sources and relying solely on picklescan faces direct RCE exposure. No active exploitation or KEV listing confirmed, but the public disclosure of the exact bypass technique (idlelib module path) makes weaponization straightforward for anyone familiar with Python pickle internals.

How does the attack unfold?

Craft Malicious Artifact
Attacker crafts a pickle file with a reduce method invoking idlelib.autocomplete.AutoComplete.get_entity, embedding arbitrary OS command payloads that evade picklescan's detection logic.
AML.T0018.002
Scanner Evasion
The malicious pickle passes pre-0.0.29 picklescan inspection undetected, giving victims false confidence that the file is safe to load.
AML.T0074
User-Triggered Execution
Victim calls pickle.load() on the scanned-clean file within their ML pipeline, triggering arbitrary command execution on the host system.
AML.T0011.000
Infrastructure Compromise
Attacker achieves RCE on ML infrastructure — training servers, model serving hosts, or CI/CD workers — gaining access to model weights, training data, and cloud credentials.
AML.T0072

What systems are affected?

Package Ecosystem Vulnerable Range Patched
picklescan pip No patch
413 3 dependents Pushed 1mo ago 74% 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
N/A
Exploitation Status
No known exploitation
Sophistication
Moderate

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?

7 steps
  1. Upgrade picklescan to version 0.0.29 or later immediately — this is the primary fix.

  2. Audit all pickle files previously scanned by pre-0.0.29 versions and treat results as potentially compromised; re-scan with the patched version.

  3. As an interim detection indicator, grep pickle files for references to 'idlelib' or 'AutoComplete' in serialized bytes.

  4. Migrate model exchange to SafeTensors format (HuggingFace) wherever possible — it is not executable by design.

  5. Use torch.load(..., weights_only=True) for PyTorch models to restrict deserialization scope.

  6. Sandbox model loading in isolated environments (containers, VMs, restricted Linux namespaces) even post-scan as defense-in-depth.

  7. Restrict model sources to internal registries with provenance controls and code signing rather than relying solely on scanning.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Art. 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.6.2.6 - AI system supply chain security controls
NIST AI RMF
GOVERN 6.2 - Policies and procedures for AI supply chain risk management
OWASP LLM Top 10
LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2025-71358?

picklescan before 0.0.29 contains a detection bypass that allows attackers to embed arbitrary command execution payloads in pickle files using Python's `idlelib.autocomplete.AutoComplete.get_entity` function in reduce methods, completely evading the scanner. This is especially damaging because picklescan is explicitly deployed as a security gate before `pickle.load()` calls — organizations relying on it to vet externally sourced AI models from Hugging Face, S3, or research repositories now have a false assurance layer with CVSS 8.1 exposure. No public exploit or KEV listing exists yet, but the bypass path is now publicly disclosed in the GHSA advisory, sharply lowering the attacker skill bar. Upgrade picklescan to 0.0.29 immediately and layer model sandboxing or process isolation as defense-in-depth; also prefer SafeTensors over pickle format wherever possible.

Is CVE-2025-71358 actively exploited?

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

How to fix CVE-2025-71358?

1. Upgrade picklescan to version 0.0.29 or later immediately — this is the primary fix. 2. Audit all pickle files previously scanned by pre-0.0.29 versions and treat results as potentially compromised; re-scan with the patched version. 3. As an interim detection indicator, grep pickle files for references to 'idlelib' or 'AutoComplete' in serialized bytes. 4. Migrate model exchange to SafeTensors format (HuggingFace) wherever possible — it is not executable by design. 5. Use `torch.load(..., weights_only=True)` for PyTorch models to restrict deserialization scope. 6. Sandbox model loading in isolated environments (containers, VMs, restricted Linux namespaces) even post-scan as defense-in-depth. 7. Restrict model sources to internal registries with provenance controls and code signing rather than relying solely on scanning.

What systems are affected by CVE-2025-71358?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, model serving, AI/ML supply chain, model registries, MLOps pipelines.

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

CVE-2025-71358 has a CVSS v3.1 base score of 8.1 (HIGH).

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servingAI/ML supply chainmodel registriesMLOps pipelines

MITRE ATLAS Techniques

AML.T0010.001 AI Software
AML.T0011.000 Unsafe AI Artifacts
AML.T0018.002 Embed Malware
AML.T0072 Reverse Shell
AML.T0074 Masquerading

Compliance Controls Affected

EU AI Act: Art. 15
ISO 42001: A.6.2.6
NIST AI RMF: GOVERN 6.2
OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

picklescan before 0.0.29 fails to detect malicious pickle files that exploit idlelib.autocomplete.AutoComplete.get_entity function in reduce methods. Attackers can embed undetected code in pickle files that executes arbitrary commands when loaded by victims using pickle.load().

Exploitation Scenario

An attacker targeting an ML team uploads a malicious pickle file to a shared model repository — a public HuggingFace model, a compromised S3 bucket, or a poisoned research artifact shared via email. The file embeds a reduce method invoking `idlelib.autocomplete.AutoComplete.get_entity` carrying an OS command payload (reverse shell, credential harvester, or persistent backdoor). The victim team runs pre-0.0.29 picklescan on the file as part of their model intake pipeline — it reports clean with no detections. The victim then calls `pickle.load()` on the file, triggering execution on the ML training server or model serving host. The attacker gains access to model weights, training data, cloud credentials stored in the environment, and potentially the broader corporate network from the ML infrastructure foothold.

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
June 22, 2026
Last Modified
June 22, 2026
First Seen
June 22, 2026

Related Vulnerabilities