Mar 1, 2026·5 min read·27 visits
Picklescan versions prior to 0.0.34 failed to detect malicious pickles utilizing the `operator` module. Attackers could use functions like `methodcaller` to proxy calls to dangerous system commands, bypassing the scanner's denylist and achieving RCE. Fixed in version 0.0.34.
Picklescan, a security auditing tool for Python Pickle files, contained a critical vulnerability allowing for Remote Code Execution (RCE) bypass. The scanner relied on an incomplete denylist of dangerous globals, failing to account for higher-order functions in the Python `operator` module. Attackers could leverage `methodcaller`, `attrgetter`, and `itemgetter` to construct indirect calls to dangerous functions (such as `os.system`), effectively evading detection while achieving arbitrary code execution.
Picklescan is a static analysis tool designed to inspect Python Pickle streams for malicious content without executing them. It operates by parsing the Pickle opcodes and comparing referenced globals (modules and functions) against a predefined list of unsafe signatures. The goal is to allow safe deserialization of data while blocking attempts to execute arbitrary code, a common vector in Python applications processing untrusted serialized data.
The vulnerability, identified as GHSA-955R-X9J8-7RHH, resides in the incompleteness of the scanner's denylist. While Picklescan correctly flagged direct references to obvious execution primitives like os.system, eval, and exec, it failed to account for the standard library's operator and _operator modules. These modules contain higher-order functions that can be used to invoke methods or access attributes on objects indirectly.
By leveraging these overlooked primitives, an attacker can construct a valid Pickle stream that performs the equivalent of os.system(...) but appears benign to the scanner's logic. This results in a complete bypass of the security control, allowing arbitrary code execution on the system performing the scan or deserialization.
The root cause of this vulnerability is a Protection Mechanism Failure (CWE-693) specifically due to an Incomplete List of Disallowed Elements (CWE-184). Picklescan's security model relies on identifying dangerous GLOBAL opcodes. In the Python Pickle protocol, the GLOBAL opcode (or c in protocol 0) instructs the unpickler to import a module and retrieve an attribute.
The scanner maintains a dictionary _unsafe_globals in src/picklescan/scanner.py, which maps module names to sets of dangerous attribute names. Prior to version 0.0.34, this dictionary did not include entries for the operator or _operator modules.
The specific functions methodcaller, attrgetter, and itemgetter in these modules are particularly dangerous in a serialization context because they return callable objects that operate on their arguments. For example, operator.methodcaller('system', 'command') returns a callable that, when applied to the os module, executes os.system('command'). Because the scanner did not recognize operator.methodcaller as a threat, it permitted the creation of this callable, enabling the exploit chain.
The vulnerability existed in the configuration of the _unsafe_globals dictionary. The fix involved explicitly adding the dangerous operator functions to this denylist. The patch ensures that any Pickle stream attempting to import these functions is flagged as malicious.
Below is the relevant change in src/picklescan/scanner.py from commit f2dea43e0c838e09ace1e62994143254b51de927:
# src/picklescan/scanner.py
_unsafe_globals = {
"__builtin__": { ... }, # Existing unsafe builtins
"builtins": { ... }, # Existing unsafe builtins
# NEWLY ADDED BLOCK: explicit denylist for operator module
"_operator": {
"attrgetter", # Can be used to access dangerous attributes
"itemgetter",
"methodcaller", # Can be used to call dangerous methods
},
"operator": {
"attrgetter",
"itemgetter",
"methodcaller",
},
# ... existing entries ...
}The inclusion of both _operator (C implementation) and operator (Python interface) ensures that variations in how the module is imported are covered. Specifically, methodcaller is the most direct vector for RCE, as it allows invoking a method by name with pre-supplied arguments.
To exploit this vulnerability, an attacker constructs a Pickle payload that chains valid, allowed operations to achieve a malicious outcome. The standard approach involves importing a target module (like os) and using operator.methodcaller to invoke a function on it.
The following Pickle assembly (Protocol 0) demonstrates the Proof-of-Concept:
cbuiltins
__import__
(Vos
tRp0 # Import 'os' and store in memo 0
0c_operator
methodcaller
(Vsystem
Vecho "pwned" # Create callable: methodcaller('system', 'echo "pwned"')
tR(g0 # Apply the callable to the 'os' module stored in memo 0
tR.Step-by-Step Execution Flow:
builtins.__import__ to load the os module. Picklescan might allow this if strict restrictions aren't placed on __import__, or if the attacker uses other techniques to get a handle on os._operator.methodcaller with the arguments 'system' and the command string. This creates a "delayed" execution object.methodcaller object to the os module instance. Internally, Python executes getattr(os, 'system')('echo "pwned"')._operator.methodcaller was not in the denylist, Picklescan validates the stream as safe, and the unpickling process executes the command.The impact of this vulnerability is critical for any system relying on Picklescan as a security boundary for untrusted data. By bypassing the scanner, an attacker gains the ability to execute arbitrary code with the privileges of the process deserializing the data.
While the vulnerability requires the attacker to be able to submit a Pickle file to the target, this is the exact scenario Picklescan is designed to handle. Therefore, the exposure is high for any deployment of the tool.
Users of picklescan must upgrade to version 0.0.34 or later immediately. This version includes the updated denylist that blocks the operator module primitives.
Remediation Steps:
pip install --upgrade picklescan.>= 0.0.34.Defense in Depth:
It is widely acknowledged that the Python Pickle format is inherently insecure. Security scanners like Picklescan provide a layer of defense but should not be the sole control for untrusted data. Where possible, switch to safer serialization formats like JSON. If Pickle must be used, ensure cryptographic signing (HMAC) is validated before any deserialization or scanning attempts.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H| Product | Affected Versions | Fixed Version |
|---|---|---|
picklescan picklescan | < 0.0.34 | 0.0.34 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-184 |
| Attack Vector | Local / Remote (Context Dependent) |
| CVSS Score | 9.8 (Critical) |
| Impact | Remote Code Execution (RCE) |
| Exploit Status | Proof of Concept (PoC) Available |
| Protocol | Python Pickle |
The software attempts to filter or sanitize input by searching for a list of dangerous elements (denylist), but the list is incomplete, allowing attackers to use alternative elements to bypass the filter.
A high-severity access control vulnerability in ToolHive CLI before v0.30.1 and ToolHive Studio before v0.38.0 allows local containerized MCP servers to bypass network isolation. This enables malicious workloads to establish TCP/IP connections to administrative and control plane endpoints exposed on the host loopback interface.
AnyCable is a real-time communication server. Prior to version 1.6.15, its Pusher-compatible REST API suffered from an authentication bypass vulnerability because it failed to verify that the request body matched the signature-validated body_md5 parameter. This allows attackers to perform replay attacks with modified body contents.
A denial-of-service vulnerability exists in AnyIO prior to version 4.14.2. Standard error streams of process-pool workers are connected to an operating system pipe that is never drained by the parent process. This allows a worker to fill the pipe buffer and deadlock indefinitely.
CVE-2026-63349 is a critical privilege-dropping bypass vulnerability in the AnyIO asynchronous framework (versions 4.14.0 and 4.14.1) on POSIX platforms. Due to a variable assignment typo, supplementary groups specified by the developer are not correctly propagated to the execution backend, resulting in subprocesses retaining the parent process's elevated supplementary group permissions.
CVE-2026-63406 is an information disclosure vulnerability in AnyCable-go prior to version 1.6.15. The built-in telemetry client is enabled by default with a hardcoded public authentication token ('secret'). This client digests highly sensitive configuration parameters and command-line arguments, including JWT secrets and RPC secrets, into a stable SHA-256 fingerprint. This fingerprint is sent over public networks, exposing those administrative secrets to offline dictionary and brute-force attacks if intercepted.
CVE-2026-84992 is a Cross-Site Scripting (XSS) vulnerability affecting md-editor-v3 before version 6.5.4. It occurs because the fenced-code block language parser directly interpolates unescaped language metadata into unquoted HTML attributes inside the custom rendering callback. This bypasses the built-in XSSPlugin which runs during the parsing phase, before rendering.