Search for packages
| purl | pkg:pypi/picklescan@1.0.3 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-dz86-5sqp-m3gj
Aliases: GHSA-g38g-8gr9-h9xp |
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. |
Affected by 0 other vulnerabilities. |
|
VCID-ffv8-d2fk-tubb
Aliases: GHSA-vvpj-8cmc-gx39 |
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. |
Affected by 0 other vulnerabilities. |
|
VCID-sapx-fzv8-pbcw
Aliases: GHSA-7wx9-6375-f5wh |
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"`. |
Affected by 0 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-mhm6-27cp-1yhr | 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. |
GHSA-97f8-7cmv-76j2
|