CVE-2025-71348: picklescan scanner bypass enables

Q: Is CVE-2025-71348 actively exploited?

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

Q: How to fix CVE-2025-71348?

1. Upgrade picklescan to 0.0.28 or later immediately — this is the only complete fix. 2. Re-scan all pickle files previously cleared by versions <0.0.28, prioritizing models sourced from public registries (HuggingFace Hub, GitHub, PyPI). 3. Treat all models loaded between deployment of the vulnerable version and patching as potentially compromised — audit system logs for anomalous processes or network connections originating from Python/model-loading processes. 4. Adopt safetensors as the default serialization format for model weights; it is inherently safe against pickle-based attacks and torch.save/load can be redirected. 5. Add defense-in-depth: run model loading in sandboxed environments (containers with no network, restricted syscalls) even after scanning. 6. If using picklescan in CI, update the version pin and add a dependency alert for future releases.

Q: What systems are affected by CVE-2025-71348?

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

Q: What is the CVSS score for CVE-2025-71348?

CVE-2025-71348 has a CVSS v3.1 base score of 8.1 (HIGH).

CISO Take

picklescan, the de-facto security gate ML teams use before loading pickle-based models, fails to flag malicious payloads that invoke torch.utils._config_module.load_config inside reduce methods — meaning a file that would execute arbitrary code on load passes the scanner as clean. The danger here is compounded trust: teams that adopted picklescan as their primary defense against pickle-based supply chain attacks are now operating under a false sense of security. With 3 downstream dependents tracked and pickle deserialization widely used across PyTorch model workflows, any ML pipeline that gates model ingestion solely on picklescan results is exposed. Upgrade immediately to picklescan 0.0.28 or later, re-audit any models cleared by older versions from untrusted or semi-trusted sources, and shift to safetensors format where possible as a structural mitigation.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

High. The CVSS 8.1 score reflects low complexity and no required privileges — the only friction is user interaction, which is routine in ML workflows where engineers regularly load externally sourced models. The critical amplifier is context: picklescan is itself a security control, so exploiting it produces a false negative that eliminates the primary detection layer. Organizations that have operationalized picklescan in CI/CD or pre-load checks may have loaded malicious artifacts already. The 73 prior CVEs in the same package and a package risk score of 53/100 suggest sustained maintenance concerns. No EPSS or KEV data available yet, but the exploit pattern requires only knowledge of the bypass technique, placing sophistication at moderate.

How does the attack unfold?

Artifact Crafting

Attacker crafts a pickle file embedding arbitrary code via torch.utils._config_module.load_config in a reduce method, specifically structured to evade picklescan's detection heuristics.

AML.T0011.000

Supply Chain Injection

Attacker publishes the malicious pickle file to a public model registry (e.g., HuggingFace Hub) or injects it into an internal model repository via a compromised contributor account.

AML.T0010.003

Detection Bypass

Target organization scans the malicious file with picklescan <0.0.28, which returns a false-clean result, removing the only security gate before model loading.

AML.T0107

Code Execution

Engineer or automated pipeline loads the model via pickle.load, triggering the embedded payload and achieving RCE on the ML infrastructure — potentially enabling data exfiltration, persistence, or lateral movement.

AML.T0018.002

Artifact Crafting

Attacker crafts a pickle file embedding arbitrary code via torch.utils._config_module.load_config in a reduce method, specifically structured to evade picklescan's detection heuristics.

AML.T0011.000

Supply Chain Injection

Attacker publishes the malicious pickle file to a public model registry (e.g., HuggingFace Hub) or injects it into an internal model repository via a compromised contributor account.

AML.T0010.003

Detection Bypass

Target organization scans the malicious file with picklescan <0.0.28, which returns a false-clean result, removing the only security gate before model loading.

AML.T0107

Code Execution

Engineer or automated pipeline loads the model via pickle.load, triggering the embedded payload and achieving RCE on the ML infrastructure — potentially enabling data exfiltration, persistence, or lateral movement.

AML.T0018.002

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
picklescan	pip	—	No patch
413 3 dependents Pushed 1mo ago 77% 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

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR None

UI Required

S Unchanged

C High

I High

A None

What should I do?

6 steps

Upgrade picklescan to 0.0.28 or later immediately — this is the only complete fix.
Re-scan all pickle files previously cleared by versions <0.0.28, prioritizing models sourced from public registries (HuggingFace Hub, GitHub, PyPI).
Treat all models loaded between deployment of the vulnerable version and patching as potentially compromised — audit system logs for anomalous processes or network connections originating from Python/model-loading processes.
Adopt safetensors as the default serialization format for model weights; it is inherently safe against pickle-based attacks and torch.save/load can be redirected.
Add defense-in-depth: run model loading in sandboxed environments (containers with no network, restricted syscalls) even after scanning.
If using picklescan in CI, update the version pin and add a dependency alert for future releases.

How is it classified?

Supply Chain Code Execution Model Framework AML.T0010.001 - AI Software AML.T0010.003 - Model AML.T0011.000 - Unsafe AI Artifacts AML.T0018.002 - Embed Malware AML.T0107 - Exploitation for Defense Evasion

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 9 - Risk management system

ISO 42001

8.4 - AI system risk management — supply chain

NIST AI RMF

MANAGE-2.2 - Mechanisms to sustain the value of deployed AI systems

OWASP LLM Top 10

LLM03:2025 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2025-71348?

picklescan, the de-facto security gate ML teams use before loading pickle-based models, fails to flag malicious payloads that invoke torch.utils._config_module.load_config inside reduce methods — meaning a file that would execute arbitrary code on load passes the scanner as clean. The danger here is compounded trust: teams that adopted picklescan as their primary defense against pickle-based supply chain attacks are now operating under a false sense of security. With 3 downstream dependents tracked and pickle deserialization widely used across PyTorch model workflows, any ML pipeline that gates model ingestion solely on picklescan results is exposed. Upgrade immediately to picklescan 0.0.28 or later, re-audit any models cleared by older versions from untrusted or semi-trusted sources, and shift to safetensors format where possible as a structural mitigation.

Is CVE-2025-71348 actively exploited?

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

How to fix CVE-2025-71348?

1. Upgrade picklescan to 0.0.28 or later immediately — this is the only complete fix. 2. Re-scan all pickle files previously cleared by versions <0.0.28, prioritizing models sourced from public registries (HuggingFace Hub, GitHub, PyPI). 3. Treat all models loaded between deployment of the vulnerable version and patching as potentially compromised — audit system logs for anomalous processes or network connections originating from Python/model-loading processes. 4. Adopt safetensors as the default serialization format for model weights; it is inherently safe against pickle-based attacks and torch.save/load can be redirected. 5. Add defense-in-depth: run model loading in sandboxed environments (containers with no network, restricted syscalls) even after scanning. 6. If using picklescan in CI, update the version pin and add a dependency alert for future releases.

What systems are affected by CVE-2025-71348?

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

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

CVE-2025-71348 has a CVSS v3.1 base score of 8.1 (HIGH).

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servingMLOps / model registriesagent frameworks

MITRE ATLAS Techniques

AML.T0010.001 AI Software

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: Art. 9

ISO 42001: 8.4

NIST AI RMF: MANAGE-2.2

OWASP LLM Top 10: LLM03:2025

What are the technical details?

Original Advisory

picklescan before 0.0.28 fails to detect malicious pickle files that invoke torch.utils._config_module.load_config function within reduce methods. Attackers can craft pickle files embedding arbitrary code that evades detection but executes during pickle.load, enabling remote code execution in supply chain attacks.

Exploitation Scenario

An attacker targeting an ML team publishes a seemingly useful PyTorch model to HuggingFace or an internal model registry. The model file is a valid PyTorch checkpoint but embeds a malicious reduce payload that calls torch.utils._config_module.load_config with attacker-controlled arguments, executing arbitrary code. A security-conscious ML engineer runs picklescan on the downloaded file — the scanner returns clean because the bypass evades detection logic in versions <0.0.28. The engineer loads the model in a training or evaluation script; the pickle payload fires during deserialization, establishing a reverse shell or exfiltrating training data and API credentials from the environment. In an automated pipeline, no human review occurs at all — the scanner output alone gates the load.

Weaknesses (CWE)

CWE-502 Deserialization of Untrusted Data Primary CWE-502 Deserialization of Untrusted Data

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.