CVE-2026-53875: picklescan scanner bypass enables

Q: Is CVE-2026-53875 actively exploited?

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

Q: How to fix CVE-2026-53875?

1. Patch: Upgrade picklescan to version 1.0.3 or later immediately — commits 134179474 and 2a8383cf on the upstream repo address the scan_pytorch bypass. 2. Re-scan: Re-scan all PyTorch model files (.pt, .pth) previously cleared by picklescan <1.0.3 with the patched version; treat prior scan results as untrusted. 3. torch.load() hardening: Pass weights_only=True to torch.load() to restrict deserialization to tensor data only — this is the most impactful in-place workaround and is available since PyTorch 1.13 (default True in PyTorch 2.6+). 4. Format migration: Prefer safetensors format for model serialization where the ML framework supports it — safetensors is not vulnerable to pickle deserialization attacks by design. 5. Sandbox model loading: Run torch.load() in containers with no network egress and restricted syscalls (seccomp) to limit blast radius if a payload executes. 6. Audit gates: Review any CI/CD or MLOps pipeline that uses picklescan output as a binary security decision; add defense-in-depth controls rather than relying on a single scanner.

Q: What systems are affected by CVE-2026-53875?

This vulnerability affects the following AI/ML architecture patterns: ML training pipelines, Model serving infrastructure, MLOps pipelines with model validation gates, Model registries and artifact hubs, CI/CD pipelines with security scanning stages.

Q: What is the CVSS score for CVE-2026-53875?

No CVSS score has been assigned yet.

CISO Take

picklescan before 1.0.3 contains a flaw in its PyTorch scan function that allows an attacker to craft malicious .pt model files using __reduce__ with dynamic eval to forge magic numbers, completely bypassing detection while the payload remains fully executable. Organizations relying on picklescan as their primary defense against pickle-based code execution in ML pipelines face a false sense of security — any model file cleared by the scanner may still detonate on torch.load(). There is no CVSS score or EPSS data published yet and the vulnerability is not in CISA KEV, but the exploit mechanic maps directly to a known and reliable attack class (CWE-95: Eval Injection), lowering the bar for motivated adversaries who understand Python deserialization. Patch immediately to picklescan 1.0.3 or later, re-scan all previously cleared model files, and enforce torch.load(weights_only=True) as a defense-in-depth measure.

Sources: NVD GitHub Advisory ATLAS VulnCheck

What is the risk?

Risk is HIGH despite the absent CVSS scoring. picklescan is a security control, not an application — bypassing it creates an undetected path to arbitrary code execution via Python's pickle deserialization. ML infrastructure (GPU servers, training clusters, CI/CD inference nodes) executing arbitrary code from crafted models can lead to full host compromise, data exfiltration, or lateral movement into corporate networks. The exploit technique (dynamic eval via __reduce__) is well-understood in the pickle security research community, and proof-of-concept primitives for __reduce__-based payloads are publicly documented. Organizations that treat a picklescan clearance as a safe-to-load signal are the primary risk population, and the blast radius scales with how broadly the tool is used as a compliance gate.

How does the attack unfold?

Craft Malicious Model

Adversary creates a PyTorch .pt file using __reduce__ with dynamic eval to embed arbitrary code while forging magic number bytes to pass picklescan's scan_pytorch signature heuristics.

AML.T0018.002

Distribution

Malicious model file is distributed via a public model hub, phishing email, or compromised internal model registry targeting organizations known to use picklescan as a security gate.

AML.T0010.001

Scanner Evasion

Victim runs picklescan on the received model file; scan_pytorch returns clean due to the magic number bypass, granting a false security clearance and eliminating the primary defense.

AML.T0107

Code Execution

Victim calls torch.load() on the scanner-cleared model file; the __reduce__ payload executes arbitrary code with the privileges of the ML process, achieving full host compromise on the GPU server.

AML.T0011.000

Craft Malicious Model

Adversary creates a PyTorch .pt file using __reduce__ with dynamic eval to embed arbitrary code while forging magic number bytes to pass picklescan's scan_pytorch signature heuristics.

AML.T0018.002

Distribution

Malicious model file is distributed via a public model hub, phishing email, or compromised internal model registry targeting organizations known to use picklescan as a security gate.

AML.T0010.001

Scanner Evasion

Victim runs picklescan on the received model file; scan_pytorch returns clean due to the magic number bypass, granting a false security clearance and eliminating the primary defense.

AML.T0107

Code Execution

Victim calls torch.load() on the scanner-cleared model file; the __reduce__ payload executes arbitrary code with the privileges of the ML process, achieving full host compromise on the GPU server.

AML.T0011.000

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
picklescan	pip	—	No patch
412 3 dependents Pushed 1mo ago 82% patched ~12d to patch Full package profile →
PyTorch	pip	—	No patch
100.7K OpenSSF 6.4 22.7K dependents Pushed 3d ago 9% patched ~260d to patch Full package profile →

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

5 steps

Patch: Upgrade picklescan to version 1.0.3 or later immediately — commits 134179474 and 2a8383cf on the upstream repo address the scan_pytorch bypass.
Re-scan: Re-scan all PyTorch model files (.pt, .pth) previously cleared by picklescan <1.0.3 with the patched version; treat prior scan results as untrusted. 3. torch.load() hardening: Pass weights_only=True to torch.load() to restrict deserialization to tensor data only — this is the most impactful in-place workaround and is available since PyTorch 1.13 (default True in PyTorch 2.6+).
Format migration: Prefer safetensors format for model serialization where the ML framework supports it — safetensors is not vulnerable to pickle deserialization attacks by design.
Sandbox model loading: Run torch.load() in containers with no network egress and restricted syscalls (seccomp) to limit blast radius if a payload executes.
Audit gates: Review any CI/CD or MLOps pipeline that uses picklescan output as a binary security decision; add defense-in-depth controls rather than relying on a single scanner.

How is it classified?

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

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

A.6.1 - Actions to address AI risks and opportunities

NIST AI RMF

GOVERN 6.1 - AI supply chain risk policies

OWASP LLM Top 10

LLM03:2025 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-53875?

picklescan before 1.0.3 contains a flaw in its PyTorch scan function that allows an attacker to craft malicious .pt model files using __reduce__ with dynamic eval to forge magic numbers, completely bypassing detection while the payload remains fully executable. Organizations relying on picklescan as their primary defense against pickle-based code execution in ML pipelines face a false sense of security — any model file cleared by the scanner may still detonate on torch.load(). There is no CVSS score or EPSS data published yet and the vulnerability is not in CISA KEV, but the exploit mechanic maps directly to a known and reliable attack class (CWE-95: Eval Injection), lowering the bar for motivated adversaries who understand Python deserialization. Patch immediately to picklescan 1.0.3 or later, re-scan all previously cleared model files, and enforce torch.load(weights_only=True) as a defense-in-depth measure.

Is CVE-2026-53875 actively exploited?

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

How to fix CVE-2026-53875?

1. Patch: Upgrade picklescan to version 1.0.3 or later immediately — commits 134179474 and 2a8383cf on the upstream repo address the scan_pytorch bypass. 2. Re-scan: Re-scan all PyTorch model files (.pt, .pth) previously cleared by picklescan <1.0.3 with the patched version; treat prior scan results as untrusted. 3. torch.load() hardening: Pass weights_only=True to torch.load() to restrict deserialization to tensor data only — this is the most impactful in-place workaround and is available since PyTorch 1.13 (default True in PyTorch 2.6+). 4. Format migration: Prefer safetensors format for model serialization where the ML framework supports it — safetensors is not vulnerable to pickle deserialization attacks by design. 5. Sandbox model loading: Run torch.load() in containers with no network egress and restricted syscalls (seccomp) to limit blast radius if a payload executes. 6. Audit gates: Review any CI/CD or MLOps pipeline that uses picklescan output as a binary security decision; add defense-in-depth controls rather than relying on a single scanner.

What systems are affected by CVE-2026-53875?

This vulnerability affects the following AI/ML architecture patterns: ML training pipelines, Model serving infrastructure, MLOps pipelines with model validation gates, Model registries and artifact hubs, CI/CD pipelines with security scanning stages.

What is the CVSS score for CVE-2026-53875?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

ML training pipelinesModel serving infrastructureMLOps pipelines with model validation gatesModel registries and artifact hubsCI/CD pipelines with security scanning stages

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0011.000 Unsafe AI Artifacts

AML.T0018.002 Embed Malware

AML.T0074 Masquerading

AML.T0107 Exploitation for Defense Evasion

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.6.1

NIST AI RMF: GOVERN 6.1

OWASP LLM Top 10: LLM03:2025

What are the technical details?

Original Advisory

picklescan before 1.0.3 contains a scanning bypass vulnerability in the scan_pytorch function that allows attackers to embed malicious magic numbers via dynamic eval using the __reduce__ trick. Attackers can craft malicious PyTorch payloads that evade picklescan detection while remaining executable, enabling arbitrary code execution when loaded with torch.load().

Exploitation Scenario

An adversary targeting an ML engineering team crafts a PyTorch model file (.pt) by overriding __reduce__ with a dynamic eval payload and carefully manipulating magic number bytes to satisfy picklescan's scan_pytorch signature heuristics. The adversary distributes the file via a public model hub, a phishing email containing a 'fine-tuned model' link, or a compromised internal artifact repository. The target team, following their documented security policy, runs picklescan on the downloaded model — it returns clean. A data scientist then calls torch.load('model.pt') in a Jupyter notebook running on a shared GPU server, triggering the payload. The attacker obtains a shell on the ML training host with access to sensitive training datasets, model weights, API keys stored in environment variables, and internal network connectivity to databases and cloud services.

Weaknesses (CWE)

CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') Primary CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

CWE-95 — Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection'): The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").

[Architecture and Design, Implementation] If possible, refactor your code so that it does not need to use eval() at all.
[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis

Source: MITRE CWE corpus.