Organizations using picklescan to validate PyTorch models or any pickle-based ML artifacts have a false sense of security — malicious models crafted with operator.methodcaller bypass detection entirely and execute arbitrary code on load. Patch to picklescan 0.0.33+ immediately. Any third-party or community model ingested through a picklescan-validated pipeline before this patch should be treated as unvalidated and potentially compromised.
What is the risk?
HIGH. Exploitability is straightforward given the public PoC — an attacker only needs to craft a pickle file using operator.methodcaller opcodes, a primitive not flagged by pre-patch picklescan. Impact is full RCE on any system that loads the file after trusting picklescan's clean verdict. Exposure is broad: picklescan is widely adopted in ML security workflows, particularly for HuggingFace model validation and PyTorch model distribution pipelines. The false confidence created by an incomplete scanner is arguably more dangerous than no scanner at all, as it removes downstream caution.
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| picklescan | pip | < 0.0.33 | 0.0.33 |
Do you use picklescan? You're affected.
How severe is it?
What should I do?
5 steps-
PATCH
Upgrade picklescan to >= 0.0.33 immediately — only definitive fix.
-
AUDIT
Re-scan all externally-sourced models previously validated by older picklescan versions; treat prior clean results as untrusted.
-
DEFENSE IN DEPTH
Prefer SafeTensors format over pickle for model storage — it eliminates the attack surface entirely. Where pickle is unavoidable, load models in isolated sandboxed processes with network egress controls.
-
DETECT
Search CI/CD and pipeline logs for picklescan runs on externally-sourced models prior to 0.0.33 and flag those ingestions for review.
-
POLICY
Enforce SafeTensors-first policy for model intake; document picklescan as a supplementary control, not a standalone gate.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-x843-g5mx-g377?
Organizations using picklescan to validate PyTorch models or any pickle-based ML artifacts have a false sense of security — malicious models crafted with operator.methodcaller bypass detection entirely and execute arbitrary code on load. Patch to picklescan 0.0.33+ immediately. Any third-party or community model ingested through a picklescan-validated pipeline before this patch should be treated as unvalidated and potentially compromised.
Is GHSA-x843-g5mx-g377 actively exploited?
No confirmed active exploitation of GHSA-x843-g5mx-g377 has been reported, but organizations should still patch proactively.
How to fix GHSA-x843-g5mx-g377?
1. PATCH: Upgrade picklescan to >= 0.0.33 immediately — only definitive fix. 2. AUDIT: Re-scan all externally-sourced models previously validated by older picklescan versions; treat prior clean results as untrusted. 3. DEFENSE IN DEPTH: Prefer SafeTensors format over pickle for model storage — it eliminates the attack surface entirely. Where pickle is unavoidable, load models in isolated sandboxed processes with network egress controls. 4. DETECT: Search CI/CD and pipeline logs for picklescan runs on externally-sourced models prior to 0.0.33 and flag those ingestions for review. 5. POLICY: Enforce SafeTensors-first policy for model intake; document picklescan as a supplementary control, not a standalone gate.
What systems are affected by GHSA-x843-g5mx-g377?
This vulnerability affects the following AI/ML architecture patterns: model serving, training pipelines, MLOps/CI-CD pipelines, model registries, data science workstations.
What is the CVSS score for GHSA-x843-g5mx-g377?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.001 AI Software AML.T0011.000 Unsafe AI Artifacts AML.T0018.002 Embed Malware AML.T0058 Publish Poisoned Models AML.T0074 Masquerading AML.T0107 Exploitation for Defense Evasion Compliance Controls Affected
What are the technical details?
Original Advisory
### Summary Picklescan uses `operator.methodcaller`, which is a built-in python library function to execute remote pickle files. ### Details The attack payload executes in the following steps: - First, the attacker crafts the payload by calling the `operator.methodcaller` function in method `reduce`. - Then, when the victim checks whether the pickle file is safe using the Picklescan library and this library doesn't detect any dangerous functions, they decide to use pickle.load() on this malicious pickle file, thus leading to remote code execution. ### PoC ``` import pickle import pickletools opcode1 = b'''cbuiltins __import__ (Vos tRp0 0coperator methodcaller (Vsystem Vecho "pwned by operator.methodcaller" tR(g0 tR.''' pickletools.dis(opcode1) pickle.loads(opcode1) ``` This PoC can't be easily created by pickle.dumps, therefore it was manually built. ### Impact Any organization or individual relying on picklescan to detect malicious pickle files inside PyTorch models. Attackers can embed malicious code in pickle file that remains undetected but executes when the pickle file is loaded. Attackers can distribute infected pickle files across ML models, APIs, or saved Python objects. ### Report by Pinji Chen (cpj24@mails.tsinghua.edu.cn) from the NISL lab (https://netsec.ccert.edu.cn/about) at Tsinghua University, Guanheng Liu (coolwind326@gmail.com).
Exploitation Scenario
An adversary publishes a malicious PyTorch model to HuggingFace or injects it via a compromised model repository. The victim's MLOps pipeline runs picklescan on the file before ingestion — picklescan reports no dangerous opcodes because the payload uses operator.methodcaller instead of flagged builtins like os.system. The victim calls torch.load() or pickle.load(), triggering arbitrary OS command execution (reverse shell, credential harvesting, lateral movement into training infrastructure). The attacker gains persistent access to the ML environment with the privileges of the workload — often a GPU node with broad data access.
Weaknesses (CWE)
CWE-502 Deserialization of Untrusted Data
Primary
CWE-94 Improper Control of Generation of Code ('Code Injection')
Primary
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.
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