CVE-2025-71347: picklescan: numpy.f2py bypass lets malicious pickle evade scan

HIGH CISA: ATTEND
Published July 4, 2026
CISO Take

picklescan, a widely used static scanner meant to flag malicious pickle files before they're deserialized, fails to detect payloads that abuse numpy.f2py.crackfortran.param_eval inside a reduce() method, letting a crafted pickle sail through as "clean" and execute arbitrary code the moment it's loaded. This matters because picklescan is a trust boundary — teams and model hubs rely on it as the last line of defense before running pickle.load()/torch.load() on artifacts from outside their org, so a bypass doesn't just add a vulnerability, it silently defeats an existing control. The CVSS 8.1 (network, low complexity, no privileges) reflects real severity, but EPSS sits at 0.445% (top 64th percentile) with no CISA KEV listing, no public exploit, and no Nuclei template, so opportunistic mass exploitation isn't happening yet — this looks more like a researcher-disclosed logic gap than an active campaign. Action: upgrade picklescan to >=0.0.33 immediately in any CI/CD, model-hub, or ingestion pipeline that gates pickle deserialization on it, and treat picklescan clearance as advisory rather than a hard safety guarantee until then — pair it with sandboxed loading or migrate to safetensors where possible.

Sources: NVD EPSS GitHub Advisory ATLAS

What is the risk?

High-severity (CVSS 8.1) logic flaw in a security control itself, not a typical application bug. Attack complexity is low and no privileges are required, but user interaction is required (a victim or automated pipeline must run the scan-then-load workflow on the attacker's file), which caps it below a fully unauthenticated remote exploit. Exploitation likelihood today is low per EPSS (0.445%, top 64th percentile) and there is no evidence of in-the-wild use, no CISA KEV entry, and no public PoC or Nuclei template — so this is a real but not yet weaponized-at-scale risk. The bigger concern is systemic: any organization that treats a passing picklescan result as sufficient justification to load untrusted model/pickle artifacts has a false sense of safety until patched.

How does the attack unfold?

Weaponization
Adversary crafts a malicious pickle/model file whose reduce method abuses numpy.f2py.crackfortran.param_eval to hide an executable code-execution gadget.
AML.T0018.002
Distribution
The crafted artifact is uploaded to a model hub, dataset repo, or shared as a dependency, posing as a legitimate model or checkpoint.
AML.T0010.001
Defense evasion
The victim's pipeline scans the artifact with a pre-0.0.33 picklescan, which fails to flag the gadget and clears the file as safe.
AML.T0107
Execution / Impact
The victim or automated pipeline deserializes the artifact via pickle.load()/torch.load(), triggering arbitrary code execution 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
Advanced
Exploitation Confidence
medium
CISA SSVC: Public PoC
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. 1) Upgrade picklescan to >=0.0.33 across all environments that use it as a scanning gate (CI, model registries, ingestion services). 2) Do not treat scanner clearance as a sole control — add defense in depth: load untrusted pickle/model artifacts only inside a sandboxed, network-isolated, least-privilege process. 3) Where feasible, migrate model serialization to safetensors or other non-executable formats instead of pickle. 4) Run a secondary/complementary scanner (e.g., fickling) alongside picklescan for cross-validation until confidence in the patched picklescan is established. 5) Audit recent artifacts that were scanned by pre-0.0.33 picklescan and cleared for use — re-scan with the patched version before continued trust. 6) Add detection for anomalous numpy.f2py imports or crackfortran.param_eval references inside deserialized pickle opcodes as a monitoring signal.

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 supply chain management for AI system components
NIST AI RMF
MANAGE 2.3 - Mechanisms for third-party/supply chain risks are in place
OWASP LLM Top 10
LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2025-71347?

picklescan, a widely used static scanner meant to flag malicious pickle files before they're deserialized, fails to detect payloads that abuse numpy.f2py.crackfortran.param_eval inside a reduce() method, letting a crafted pickle sail through as "clean" and execute arbitrary code the moment it's loaded. This matters because picklescan is a trust boundary — teams and model hubs rely on it as the last line of defense before running pickle.load()/torch.load() on artifacts from outside their org, so a bypass doesn't just add a vulnerability, it silently defeats an existing control. The CVSS 8.1 (network, low complexity, no privileges) reflects real severity, but EPSS sits at 0.445% (top 64th percentile) with no CISA KEV listing, no public exploit, and no Nuclei template, so opportunistic mass exploitation isn't happening yet — this looks more like a researcher-disclosed logic gap than an active campaign. Action: upgrade picklescan to >=0.0.33 immediately in any CI/CD, model-hub, or ingestion pipeline that gates pickle deserialization on it, and treat picklescan clearance as advisory rather than a hard safety guarantee until then — pair it with sandboxed loading or migrate to safetensors where possible.

Is CVE-2025-71347 actively exploited?

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

How to fix CVE-2025-71347?

1) Upgrade picklescan to >=0.0.33 across all environments that use it as a scanning gate (CI, model registries, ingestion services). 2) Do not treat scanner clearance as a sole control — add defense in depth: load untrusted pickle/model artifacts only inside a sandboxed, network-isolated, least-privilege process. 3) Where feasible, migrate model serialization to safetensors or other non-executable formats instead of pickle. 4) Run a secondary/complementary scanner (e.g., fickling) alongside picklescan for cross-validation until confidence in the patched picklescan is established. 5) Audit recent artifacts that were scanned by pre-0.0.33 picklescan and cleared for use — re-scan with the patched version before continued trust. 6) Add detection for anomalous numpy.f2py imports or crackfortran.param_eval references inside deserialized pickle opcodes as a monitoring signal.

What systems are affected by CVE-2025-71347?

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

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

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

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesAI supply chain / model hub ingestionMLOps CI/CD pipelines

MITRE ATLAS Techniques

AML.T0010.001 AI Software
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 2.3
OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

picklescan before 0.0.33 fails to detect malicious pickle files using numpy.f2py.crackfortran.param_eval function in reduce methods, allowing attackers to bypass security checks. Remote attackers can embed undetected code in pickle files that executes during deserialization, enabling arbitrary code execution in applications loading untrusted pickle data.

Exploitation Scenario

An adversary crafts a malicious model file (e.g., a PyTorch checkpoint or joblib pickle) whose __reduce__ method invokes numpy.f2py.crackfortran.param_eval in a way that executes attacker-controlled code on unpickling, then uploads it to a model hub, shares it via a blog post, dataset repo, or supply-chain dependency, framing it as a legitimate pretrained model. A victim's MLOps pipeline or data scientist downloads the file and runs it through picklescan as a pre-load safety gate; because the scanner doesn't recognize this specific reduce-method gadget, the file is marked clean. The victim (or an automated CI/CD job) then proceeds to pickle.load()/torch.load() the file, triggering arbitrary code execution on the host — potentially a training server, inference endpoint, or developer workstation — despite having followed documented best practice by scanning first.

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 6, 2026
First Seen
July 4, 2026

Related Vulnerabilities