Package Instance

Picklescan vulnerable to Arbitrary File Writing
Picklescan has got open() and shutil in its default dangerous blocklist to prevent arbitrary file overwrites. However the module distutils isnt blocked and can be used for the same purpose ie to write arbitrary files.

Picklescan missing detection when calling numpy.f2py.crackfortran.getlincoef
An unsafe deserialization vulnerability allows an attacker to execute arbitrary code on the host when loading a malicious pickle payload from an untrusted source.

Picklescan does not block ctypes
Picklescan doesnt flag ctypes module as a dangerous module, which is a huge issue. ctypes is basically a foreign function interface library and can be used to
* Load DLLs
* Call C functions directly
* Manipulate memory raw pointers.

This can allow attackers to achieve RCE by invoking direct syscalls without going through blocked modules. Another major issue that ctypes being allowed presents is that it can be used down the line to dismantle interpreter based python sandboxes as ctypes allow direct access to raw memory.

This is a more severe loophole than normal gadget chains and bypasses as raw memory access can be used for a lot of nefarious purposes down the line if left undetected

Picklescan is vulnerable to RCE through missing detection when calling numpy.f2py.crackfortran.myeval
Picklescan uses numpy.f2py.crackfortran.myeval, which is a function in numpy to execute remote pickle files.

picklescan has Arbitrary file read using `io.FileIO`
Unsafe pickle deserialization allows unauthenticated attackers to read arbitrary server files and perform SSRF. By chaining io.FileIO and urllib.request.urlopen, an attacker can bypass RCE-focused blocklists to exfiltrate sensitive data (example: /etc/passwd) to an external server.

PickleScan has multiple stdlib modules with direct RCE not in blocklist
picklescan v1.0.3 (latest) does not block at least 7 Python standard library modules that provide direct arbitrary command execution or code evaluation. A malicious pickle file importing these modules is reported as having 0 issues (CLEAN scan). This enables remote code execution that bypasses picklescan entirely.

Picklescan Bypasses Unsafe Globals Check using pty.spawn
The vulnerability allows malicious actors to bypass PickleScan's unsafe globals check, leading to potential arbitrary code execution. The issue stems from the absence of the `pty` library (more specifically, of  the `pty.spawn` function) from PickleScan's list of unsafe globals. This vulnerability allows attackers to disguise malicious pickle payloads within files that would otherwise be scanned for pickle-based threats.

Picklescan has Incomplete List of Disallowed Inputs
Currently picklescanner only blocks some specific functions of the pydoc and operator modules. Attackers can use other functions within these allowed modules to go through undetected and achieve RCE on the final user. Particularly
* pydoc.locate: Can dynamically resolve and import arbitrary modules (e.g., resolving the string "os" to the actual os module).
* operator.methodcaller: Allows executing a method on an object. When combined with a resolved module object, it can execute functions like system.

Since locate and methodcaller are not explicitly listed in the deny-list, picklescan treats them as "Safe" or "Suspicious" (depending on configuration) but does not flag them as "Dangerous", allowing the malicious file to bypass the security check.

PickleScan's pkgutil.resolve_name has a universal blocklist bypass
`pkgutil.resolve_name()` is a Python stdlib function that resolves any `"module:attribute"` string to the corresponding Python object at runtime. By using `pkgutil.resolve_name` as the first REDUCE call in a pickle, an attacker can obtain a reference to ANY blocked function (e.g., `os.system`, `builtins.exec`, `subprocess.call`) without that function appearing in the pickle's opcodes. picklescan only sees `pkgutil.resolve_name` (which is not blocked) and misses the actual dangerous function entirely.

This defeats picklescan's **entire blocklist concept** — every single entry in `_unsafe_globals` can be bypassed.

Picklescan is vulnerable to RCE via missing detection when calling numpy.f2py.crackfortran.param_eval
Picklescan uses numpy.f2py.crackfortran.param_eval, which is a function in numpy to execute remote pickle files.

picklescan vulnerable to arbitrary file create using logging.FileHandler
Unsafe pickle deserialization allows unauthenticated attackers to perform Arbitrary File Creation. By chaining the logging.FileHandler class, an attacker can bypass RCE-focused blocklists to create empty files on the server. The vulnerability allows creating zero-byte files in arbitrary locations but does not permit overwriting or modifying existing files.

Picklescan is vulnerable to RCE through missing detection when calling numpy.f2py.crackfortran._eval_length
Picklescan uses the `numpy.f2py.crackfortran._eval_length` function (a NumPy F2PY helper) to execute arbitrary Python code during unpickling.

Picklescan (scan_pytorch) Bypass via dynamic eval MAGIC_NUMBER
This is a scanning bypass to `scan_pytorch` function in `picklescan`. As we can see in the implementation of [get_magic_number()](https://github.com/mmaitre314/picklescan/blob/2a8383cfeb4158567f9770d86597300c9e508d0f/src/picklescan/torch.py#L76C5-L84) that uses `pickletools.genops(data)` to get the `magic_number` with the condition `opcode.name` includes `INT` or `LONG`, but the PyTorch's implemtation simply uses [pickle_module.load()](https://github.com/pytorch/pytorch/blob/134179474539648ba7dee1317959529fbd0e7f89/torch/serialization.py#L1797) to get this `magic_number`. For this implementation difference, we then can embed the `magic_code` into the `PyTorch` file via dynamic `eval` on the `\_\_reduce\_\_` trick, which can make the `pickletools.genops(data)` cannot get the `magic_code` in `INT` or `LONG` type, but the `pickle_module.load()` can still return the same `magic_code`, eading to a bypass.

Picklescan is vulnerable to RCE via missing detection when calling built-in python _operator.attrgetter
Picklescan uses _operator.attrgetter, which is a built-in python library function to execute remote pickle files.

Picklescan is vulnerable to RCE through missing detection when calling built-in python operator.methodcaller
Picklescan uses `operator.methodcaller`, which is a built-in python library function to execute remote pickle files.

picklescan missing detection by simple obfuscation of a `builtins.eval` call
An unsafe deserialization vulnerability allows any unauthenticated user to execute arbitrary code on the host loading a pickle payload from an untrusted source.

Picklescan is vulnerable to RCE via missing detection when calling numpy.f2py.crackfortran.getlincoef
Picklescan uses the `numpy.f2py.crackfortran.getlincoef` function (a NumPy F2PY helper) to execute arbitrary Python code during unpickling.

PickleScan's profile.run blocklist mismatch allows exec() bypass
picklescan v1.0.3 blocks `profile.Profile.run` and `profile.Profile.runctx` but does NOT block the module-level `profile.run()` function. A malicious pickle calling `profile.run(statement)` achieves arbitrary code execution via `exec()` while picklescan reports 0 issues. This is because the blocklist entry `"Profile.run"` does not match the pickle global name `"run"`.

Picklescan is vulnerable to RCE via missing detection when calling built-in python _operator.methodcaller
Picklescan uses  _operator.methodcaller, which is a built-in python library function to execute remote pickle files.

Picklescan missing detection when calling pty.spawn
Using pty.spawn, which is a built-in python library function to execute arbitrary commands on the host system.