CVE-2025-71375: picklescan: detection bypass enables pickle RCE
HIGH PoC AVAILABLE CISA: ATTENDpicklescan, 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.
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?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| picklescan | pip | — | No patch |
Do you use picklescan? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
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?
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-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
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
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 References
Timeline
Related Vulnerabilities
CVE-2026-3490 10.0 picklescan: blocklist bypass enables full RCE
Same package: picklescan GHSA-vvpj-8cmc-gx39 10.0 picklescan: security flaw enables exploitation
Same package: picklescan GHSA-g38g-8gr9-h9xp 9.8 picklescan: Allowlist Bypass evades input filtering
Same package: picklescan CVE-2025-1945 9.8 picklescan: ZIP flag bypass enables RCE in PyTorch models
Same package: picklescan GHSA-7wx9-6375-f5wh 9.8 picklescan: Allowlist Bypass evades input filtering
Same package: picklescan