CVE-2025-71373: picklescan: methodcaller bypass enables pickle RCE

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

picklescan is a widely-used scanner meant to certify that a pickle file (the format many ML models and artifacts are serialized in) is safe to load, but versions before 0.0.33 fail to recognize `operator.methodcaller` calls as a code-execution primitive, so a crafted pickle can pass the scan and still run arbitrary code the moment it's deserialized. The blast radius isn't the CVE itself but everything downstream that treats a picklescan "clean" verdict as a trust boundary — model hubs, MLOps pipelines, and internal tooling that auto-load third-party pickle artifacts after this check. There's no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so this looks pre-exploitation rather than actively weaponized, but the technique is now public via the GitHub Security Advisory and a VulnCheck writeup, which shortens the runway. Patch to picklescan 0.0.33 or later immediately in any pipeline that gates pickle loading on it, and treat picklescan as defense-in-depth rather than a sufficient control — the durable fix is migrating model storage to safetensors or otherwise avoiding pickle deserialization of untrusted artifacts entirely.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

CVSS 8.1 (High) reflects a network-exploitable, low-complexity, no-privileges-required path to full confidentiality and integrity compromise, offset only by the requirement for user interaction (the victim or an automated pipeline must load the malicious pickle). Real-world exploitability is currently unconfirmed — no EPSS score, no KEV entry, no known public exploit or scanner template — but the vulnerability class (detection bypass in a security control) is high-value to attackers because it undermines an entire category of downstream trust decisions rather than a single application. Any organization that uses picklescan as a gate before loading models from external sources (Hugging Face, internal registries, third-party vendors) should treat this as elevated risk until patched, since the failure mode is silent — the scanner reports "safe" while the payload is live.

How does the attack unfold?

Craft malicious payload
Adversary builds a pickle file that uses operator.methodcaller instead of commonly denylisted calls to smuggle in a code-execution primitive.
AML.T0018.002
Deliver via trusted channel
The malicious pickle is submitted or published as a model/artifact to a hub, registry, or shared location the victim organization consumes from.
AML.T0010.001
Evade detection
The victim's picklescan-based gate scans the file, fails to flag the operator.methodcaller call, and certifies it as safe.
AML.T0107
Code execution on load
A user or automated pipeline deserializes the 'vetted' file, triggering the methodcaller invocation and executing arbitrary code on the host.
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
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.33 or later immediately in any pipeline, service, or CI step that uses it to vet pickle files before loading. Do not treat a picklescan pass as a strong safety guarantee even post-patch — pickle deserialization is inherently unsafe and detection-based scanning is a mitigation, not a fix, so prioritize migrating model storage/exchange to safetensors or another non-executable serialization format where feasible. As a compensating control, sandbox or isolate any process that deserializes pickle files from untrusted or third-party sources (containerized, no network egress, minimal privileges), and add monitoring for unexpected subprocess/network activity immediately following model-load events, since that is the observable signature of a successful bypass.

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 - AI system data acquisition and preparation / third-party and acquired components
NIST AI RMF
MANAGE 2.3 - Third-party AI resources are monitored and managed for risk
OWASP LLM Top 10
LLM03:2025 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2025-71373?

picklescan is a widely-used scanner meant to certify that a pickle file (the format many ML models and artifacts are serialized in) is safe to load, but versions before 0.0.33 fail to recognize `operator.methodcaller` calls as a code-execution primitive, so a crafted pickle can pass the scan and still run arbitrary code the moment it's deserialized. The blast radius isn't the CVE itself but everything downstream that treats a picklescan "clean" verdict as a trust boundary — model hubs, MLOps pipelines, and internal tooling that auto-load third-party pickle artifacts after this check. There's no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so this looks pre-exploitation rather than actively weaponized, but the technique is now public via the GitHub Security Advisory and a VulnCheck writeup, which shortens the runway. Patch to picklescan 0.0.33 or later immediately in any pipeline that gates pickle loading on it, and treat picklescan as defense-in-depth rather than a sufficient control — the durable fix is migrating model storage to safetensors or otherwise avoiding pickle deserialization of untrusted artifacts entirely.

Is CVE-2025-71373 actively exploited?

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

How to fix CVE-2025-71373?

Upgrade picklescan to 0.0.33 or later immediately in any pipeline, service, or CI step that uses it to vet pickle files before loading. Do not treat a picklescan pass as a strong safety guarantee even post-patch — pickle deserialization is inherently unsafe and detection-based scanning is a mitigation, not a fix, so prioritize migrating model storage/exchange to safetensors or another non-executable serialization format where feasible. As a compensating control, sandbox or isolate any process that deserializes pickle files from untrusted or third-party sources (containerized, no network egress, minimal privileges), and add monitoring for unexpected subprocess/network activity immediately following model-load events, since that is the observable signature of a successful bypass.

What systems are affected by CVE-2025-71373?

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

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

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

What is the AI security impact?

Affected AI Architectures

model servingMLOps pipelinesmodel registries/hubstraining pipelines

MITRE ATLAS Techniques

AML.T0011.000 Unsafe AI Artifacts
AML.T0018.002 Embed Malware
AML.T0050 Command and Scripting Interpreter
AML.T0107 Exploitation for Defense Evasion

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:2025

What are the technical details?

Original Advisory

picklescan before 0.0.33 fails to detect operator.methodcaller function calls in pickle files, allowing attackers to bypass security checks. Remote attackers can craft malicious pickle payloads using operator.methodcaller that execute arbitrary code when loaded, compromising systems relying on picklescan for validation.

Exploitation Scenario

An adversary crafts a malicious pickle file — disguised as a legitimate model checkpoint or dataset artifact — that uses `operator.methodcaller` instead of the more commonly denylisted `__reduce__`/`eval`/`os.system` patterns to invoke arbitrary code during unpickling. They publish or submit this file to a location the victim organization trusts (a model hub, an internal artifact repository, a shared training dataset), where an automated pipeline runs picklescan as a safety gate. Because picklescan's detection logic doesn't recognize `operator.methodcaller` as dangerous, the file is certified clean and passed through. When a data scientist, CI job, or inference service subsequently loads the "vetted" file, the methodcaller invocation fires and executes the attacker's code with whatever privileges the loading process holds — potentially a training server, an ML platform backend, or a production inference host.

Weaknesses (CWE)

CWE-693 — Protection Mechanism Failure: The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.

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