CVE-2025-71353: picklescan: detection bypass allows pickle RCE
HIGH CISA: TRACK*picklescan, the open-source scanner many ML teams rely on to vet untrusted model files before loading them, fails to flag a specific pickle payload that abuses torch._dynamo.guards.GuardBuilder.get inside a __reduce__ method, meaning a file it certifies as 'clean' can still execute arbitrary commands the moment it is deserialized with torch.load. This is not a mass-exploitable zero-day: EPSS sits at just 0.3%, there is no CISA KEV listing, no public exploit, and no Nuclei template, so opportunistic scanning is unlikely today. What makes it worth attention is that it directly defeats a security control organizations deploy specifically to stop malicious model uploads, so any model registry, CI/CD gate, or ingestion pipeline that treats a picklescan pass as sufficient assurance is exposed to arbitrary code execution from a crafted checkpoint. Upgrade picklescan to 0.0.28 or later now, and stop treating scanner clearance as the only control — pair it with sandboxed model loading, restrict model sources, and migrate to safetensors where feasible.
What is the risk?
CVSS 8.1 (High) reflects network attack vector, low complexity, and no privileges required, offset only by the need for user interaction (the victim must load the malicious pickle/model). Exploitability is currently low in practice — EPSS is 0.3%, no public PoC or scanner template exists, and it is not in CISA KEV — but the vulnerability is trivial to weaponize once understood because it targets a well-documented class of pickle-based deserialization attacks against a security tool with a known, auditable ruleset. The real risk driver is that it silently defeats a defensive control (picklescan) rather than exploiting an application directly, so organizations may have a false sense of security in any pipeline that gates model uploads on a picklescan pass.
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.28 immediately in any pipeline or tool that depends on it. Do not treat a picklescan pass as sole assurance of safety — add sandboxing/isolation (containers with no network/host access, seccomp, ephemeral VMs) around any torch.load() call on externally sourced files. Where possible, migrate model storage/exchange to safetensors, which does not support arbitrary code execution via deserialization. For detection, audit CI/CD and registry configs for pinned picklescan versions below 0.0.28, and flag/quarantine any pickle files whose reduce() chains reference torch._dynamo.guards.GuardBuilder or other non-standard torch internals during static review.
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-71353?
picklescan, the open-source scanner many ML teams rely on to vet untrusted model files before loading them, fails to flag a specific pickle payload that abuses torch._dynamo.guards.GuardBuilder.get inside a __reduce__ method, meaning a file it certifies as 'clean' can still execute arbitrary commands the moment it is deserialized with torch.load. This is not a mass-exploitable zero-day: EPSS sits at just 0.3%, there is no CISA KEV listing, no public exploit, and no Nuclei template, so opportunistic scanning is unlikely today. What makes it worth attention is that it directly defeats a security control organizations deploy specifically to stop malicious model uploads, so any model registry, CI/CD gate, or ingestion pipeline that treats a picklescan pass as sufficient assurance is exposed to arbitrary code execution from a crafted checkpoint. Upgrade picklescan to 0.0.28 or later now, and stop treating scanner clearance as the only control — pair it with sandboxed model loading, restrict model sources, and migrate to safetensors where feasible.
Is CVE-2025-71353 actively exploited?
No confirmed active exploitation of CVE-2025-71353 has been reported, but organizations should still patch proactively.
How to fix CVE-2025-71353?
Upgrade picklescan to >=0.0.28 immediately in any pipeline or tool that depends on it. Do not treat a picklescan pass as sole assurance of safety — add sandboxing/isolation (containers with no network/host access, seccomp, ephemeral VMs) around any torch.load() call on externally sourced files. Where possible, migrate model storage/exchange to safetensors, which does not support arbitrary code execution via deserialization. For detection, audit CI/CD and registry configs for pinned picklescan versions below 0.0.28, and flag/quarantine any pickle files whose reduce() chains reference torch._dynamo.guards.GuardBuilder or other non-standard torch internals during static review.
What systems are affected by CVE-2025-71353?
This vulnerability affects the following AI/ML architecture patterns: model serving, training pipelines, model registries, MLOps CI/CD pipelines.
What is the CVSS score for CVE-2025-71353?
CVE-2025-71353 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.30%.
What is the AI security impact?
Affected AI Architectures
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
What are the technical details?
Original Advisory
picklescan before 0.0.28 fails to detect malicious pickle files that exploit torch._dynamo.guards.GuardBuilder.get function in reduce methods. Attackers can craft pickle files with embedded code that evades picklescan detection and executes arbitrary commands when loaded.
Exploitation Scenario
An attacker crafts a PyTorch checkpoint (.pt/.pkl) whose pickle stream includes a __reduce__ method that chains through torch._dynamo.guards.GuardBuilder.get to reach code execution, a gadget outside picklescan's pre-0.0.28 detection rules. They upload it to a public model hub or submit it into a target organization's model ingestion pipeline that automatically runs picklescan as a security gate. picklescan reports the file clean, and it proceeds to torch.load() in the victim's training or inference environment, triggering the embedded reduce() call and executing arbitrary OS commands with the privileges of the loading process — enabling credential theft, lateral movement, or further compromise of the ML training/serving host.
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