CVE-2025-71375: picklescan: detection bypass enables pickle RCE

HIGH PoC AVAILABLE CISA: ATTEND
Published July 4, 2026
CISO Take

picklescan, the security scanner many AI teams rely on to vet pickle-serialized model files before loading them, fails to flag payloads built with Python's `_operator.methodcaller`, so a maliciously crafted pickle can sail through scanning marked 'safe' and then execute arbitrary code the moment `pickle.load()` runs on it. This is CVSS 8.1 high-severity precisely because it undermines the specific control organizations put in place to catch this exact attack class — a passed scan giving false confidence is often worse than having no scanner at all, and any pipeline that gates model ingestion on a picklescan pass is exposed. There is no evidence of active exploitation (absent from CISA KEV, no public PoC or Nuclei template found, EPSS unavailable), and exploitation still requires a user or automated step to load the malicious file, so this is not internet-wormable — but the bar to weaponize a working payload is low now that the GHSA advisory documents the exact bypass technique. Upgrade picklescan to 0.0.34 or later immediately in any model-ingestion, CI, or model-registry pipeline; until patched, treat picklescan 'clean' verdicts on untrusted pickle files as unverified and prefer safetensors or other non-pickle serialization formats for externally sourced models.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

High risk for any organization that treats a picklescan pass as sufficient justification to load untrusted pickle files. The vulnerability itself requires no privileges and low attack complexity (AV:N/AC:L/PR:N), but does require user interaction — a person or automated pipeline must actually load the crafted pickle file. There's no confirmed exploitation in the wild, no CISA KEV listing, and no public exploit or scanner signature yet, which lowers immediate urgency, but the underlying weakness (an incomplete opcode/callable blocklist) is a class of bug likely to recur and is trivial to weaponize once known, since `_operator.methodcaller` is a legitimate stdlib callable that a naive denylist approach can miss. The real danger is second-order: teams that adopted picklescan specifically to make pickle loading 'safe' may have relaxed other controls (e.g., sandboxing, provenance checks) in reliance on it.

How does the attack unfold?

Craft malicious artifact
Adversary builds a pickle file whose payload uses _operator.methodcaller instead of commonly denylisted callables, designed to execute code on deserialization.
AML.T0018.002
Evade security scan
The file is submitted to or scanned by picklescan (<0.0.34), which fails to recognize the methodcaller-based payload and reports it as safe.
AML.T0107
Victim loads artifact
A user or automated ML pipeline, trusting the 'clean' scan result, calls pickle.load() on the file.
AML.T0011.000
Code execution / impact
The embedded payload executes with the privileges of the loading process, giving the adversary code execution and a foothold into the ML environment.
AML.T0112

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 30% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Moderate
Exploitation Confidence
medium
CISA SSVC: Public PoC
Public PoC indexed (trickest/cve)
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. Upgrade picklescan to >= 0.0.34 immediately in all environments where it gates pickle file ingestion (CI/CD, model registries, MLOps pipelines). Until upgraded, do not treat a picklescan 'clean' result as sufficient assurance for pickle files from untrusted or external sources — add a compensating control such as loading untrusted models only in an isolated/sandboxed environment (container with no network/credentials, seccomp, or a disposable VM) regardless of scan result. Where feasible, migrate model storage/exchange to non-executable formats like safetensors, which cannot carry arbitrary code execution payloads, eliminating this class of risk entirely. For detection, retroactively re-scan previously 'cleared' pickle artifacts with the patched picklescan version and audit provenance of any pickle files ingested from external sources since exposure to this gap began.

What does CISA's SSVC say?

Decision Attend
Exploitation poc
Automatable No
Technical Impact total

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 / acquired AI components
NIST AI RMF
MANAGE 4.1 - Third-party AI resource risk management
OWASP LLM Top 10
LLM03:2025 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2025-71375?

picklescan, the security scanner many AI teams rely on to vet pickle-serialized model files before loading them, fails to flag payloads built with Python's `_operator.methodcaller`, so a maliciously crafted pickle can sail through scanning marked 'safe' and then execute arbitrary code the moment `pickle.load()` runs on it. This is CVSS 8.1 high-severity precisely because it undermines the specific control organizations put in place to catch this exact attack class — a passed scan giving false confidence is often worse than having no scanner at all, and any pipeline that gates model ingestion on a picklescan pass is exposed. There is no evidence of active exploitation (absent from CISA KEV, no public PoC or Nuclei template found, EPSS unavailable), and exploitation still requires a user or automated step to load the malicious file, so this is not internet-wormable — but the bar to weaponize a working payload is low now that the GHSA advisory documents the exact bypass technique. Upgrade picklescan to 0.0.34 or later immediately in any model-ingestion, CI, or model-registry pipeline; until patched, treat picklescan 'clean' verdicts on untrusted pickle files as unverified and prefer safetensors or other non-pickle serialization formats for externally sourced models.

Is CVE-2025-71375 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2025-71375, increasing the risk of exploitation.

How to fix CVE-2025-71375?

Upgrade picklescan to >= 0.0.34 immediately in all environments where it gates pickle file ingestion (CI/CD, model registries, MLOps pipelines). Until upgraded, do not treat a picklescan 'clean' result as sufficient assurance for pickle files from untrusted or external sources — add a compensating control such as loading untrusted models only in an isolated/sandboxed environment (container with no network/credentials, seccomp, or a disposable VM) regardless of scan result. Where feasible, migrate model storage/exchange to non-executable formats like safetensors, which cannot carry arbitrary code execution payloads, eliminating this class of risk entirely. For detection, retroactively re-scan previously 'cleared' pickle artifacts with the patched picklescan version and audit provenance of any pickle files ingested from external sources since exposure to this gap began.

What systems are affected by CVE-2025-71375?

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

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

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

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinessupply chain / artifact registries

MITRE ATLAS Techniques

AML.T0010.003 Model
AML.T0011.000 Unsafe AI Artifacts
AML.T0018.002 Embed Malware
AML.T0107 Exploitation for Defense Evasion

Compliance Controls Affected

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

What are the technical details?

Original Advisory

picklescan before 0.0.34 fails to detect the _operator.methodcaller built-in function when scanning pickle files for malicious code. Attackers can craft malicious pickle payloads using _operator.methodcaller that evade detection and execute arbitrary code when loaded by pickle.load().

Exploitation Scenario

An adversary crafts a malicious pickle file — for example, a 'fine-tuned model checkpoint' — embedding a `_operator.methodcaller` call chain designed to invoke `os.system` or an equivalent code-execution primitive instead of using the commonly denylisted `__reduce__`/`os.system` pattern. The adversary publishes or sends this file as a seemingly legitimate model artifact (e.g., uploaded to a public model-sharing platform or attached to a pull request/dataset). The victim organization's ingestion pipeline runs picklescan as a security gate, which fails to recognize `_operator.methodcaller` as dangerous and reports the file as clean. A data scientist or automated pipeline then loads the 'verified safe' file via `pickle.load()`, triggering the embedded payload and achieving arbitrary code execution with the privileges of the loading process — potentially exposing credentials, training data, or providing a foothold into the broader ML 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 7, 2026
First Seen
July 4, 2026

Related Vulnerabilities