CVE-2026-22609: Incomplete Blocklist in Fickling Pickle Analyzer Leads to Arbitrary Code Execution

Fickling is a specialized static analysis tool developed to inspect Python pickle files—a serialization format known for its inherent security risks. The tool operates by symbolically executing the pickle machine's opcodes (such as GLOBAL, STACK_GLOBAL, and REDUCE) to reconstruct the Abstract Syntax Tree (AST) of the code that would execute upon deserialization. Fickling's primary objective is to identify malicious intent, such as the invocation of os.system or subprocess.Popen, allowing security teams to filter out dangerous files before they are loaded by the Python interpreter.

CVE-2026-22609 identifies a fundamental flaw in Fickling's detection logic. The analyzer employed a "denylist" approach, maintaining a hardcoded tuple of module names deemed unsafe. However, this list was not exhaustive. It omitted several powerful Python standard library modules that provide execution primitives capable of bypassing the Python runtime's intended constraints. Furthermore, the logic used to validate module paths was insufficient, allowing submodules or specific import patterns to evade detection.

The impact of this vulnerability is significant because Fickling is often deployed as a security gate in Machine Learning (ML) pipelines to validate untrusted models (which are often pickled data). By exploiting this flaw, an attacker can supply a malicious model that Fickling certifies as safe, but which subsequently compromises the downstream system consuming the model.

The vulnerability stems from the implementation of the unsafe_imports() method within fickling/fickle.py. This method is responsible for iterating over the AST nodes generated during the symbolic execution of the pickle file. It compares the module names targeted by GLOBAL or STACK_GLOBAL opcodes against a predefined set of forbidden strings.

The Incomplete Blocklist (CWE-184) The primary failure was the omission of critical modules from the UNSAFE_IMPORTS collection. Prior to version 0.1.7, the list lacked the following modules:

• ctypes: Provides C-compatible data types and allows calling functions in DLLs/shared libraries. This can be used to invoke libc.system directly, bypassing Python's os module checks.
• runpy: Designed to locate and execute Python modules without importing them first. Functions like run_path can execute arbitrary script files.
• importlib: Provides the implementation of the import statement. Attackers can use it to dynamically load other blocked modules or execute arbitrary code during the import process.
• multiprocessing: Can spawn new processes, potentially executing arbitrary shell commands.
• code: Provides facilities to implement read-eval-print loops, which can be abused to execute arbitrary Python code strings.

Logic Flaws in Detection Beyond the missing entries, the detection logic contained structural flaws. First, the string matching was too rigid. It often checked for exact matches on the top-level package, meaning that if an attacker imported a submodule (e.g., ctypes.util) in a specific way, the check might be bypassed depending on how the opcode argument was structured. Second, Fickling explicitly suppressed the generation of AST nodes for builtins, __builtin__, and __builtins__. This exclusion was intended to reduce noise but inadvertently hid calls to dangerous built-in functions (like eval or __import__) from the safety check routine entirely.

The following analysis contrasts the vulnerable implementation with the remediated code in version 0.1.7. The changes focus on expanding the blocklist and refining the validation logic.

Vulnerable Implementation (Concept) In earlier versions, the check was a simple membership test against a limited tuple. If the module wasn't in the tuple, it was yielded as safe or ignored.

# fickling/fickle.py (Pre-patch)
UNSAFE_IMPORTS = ("os", "subprocess", "sys", ...)
 
# Inside unsafe_imports()
if node.module in UNSAFE_IMPORTS:
    yield node

Remediated Implementation The patch introduces a comprehensive list of dangerous modules and refactors the check to inspect every component of the dotted module path. This prevents bypasses where a submodule is imported.

# fickling/fickle.py (Patched in v0.1.7)
 
# 1. Expanded Blocklist
UNSAFE_IMPORTS = {
    "os", "subprocess", "sys", "eval", "exec",
    "shutil", "platform", "ctypes",          # Added
    "runpy", "importlib", "code",            # Added
    "multiprocessing", "cProfile", "pydoc"   # Added
}
 
# 2. Enhanced Path Validation
# The analyzer now splits the module path and checks if ANY part is unsafe.
# e.g., 'ctypes.util' -> checks 'ctypes' AND 'util'.
if node.module and any(component in UNSAFE_IMPORTS for component in node.module.split(".")):
    yield node
 
# 3. Removal of Builtin Suppression
# The logic that previously ignored 'builtins' was removed to ensure
# access to dangerous builtins is visible to the analyzer.

The fix transforms the detection from a shallow string match to a more robust component-wise validation, significantly reducing the attack surface for import-based evasion.

To exploit this vulnerability, an attacker must craft a pickle file that utilizes one of the unmonitored modules to execute code. Standard pickle exploitation often relies on the __reduce__ method, which dictates how an object is pickled and unpickled. When unpickled, the GLOBAL opcode imports the specified module and returns a callable, and REDUCE executes that callable with provided arguments.

Scenario: ctypes Bypass The ctypes module allows interaction with C data types and shared libraries. An attacker can use ctypes.CDLL to load the standard C library (libc.so.6 on Linux) and invoke the system function. Because ctypes was missing from the UNSAFE_IMPORTS list, Fickling would parse the opcodes, see the import of ctypes, fail to match it against the blocklist, and conclude the file is safe.

Proof of Concept (PoC) The following Python snippet generates a pickle payload that executes id via ctypes. This payload successfully bypasses Fickling < 0.1.7.

import pickle
 
# The opcode sequence roughly translates to:
# GLOBAL 'ctypes' 'CDLL'  -> import ctypes; push ctypes.CDLL
# STRING 'libc.so.6'      -> push argument
# REDUCE                  -> call ctypes.CDLL('libc.so.6') -> returns libc handle
# ... (subsequent calls to resolve 'system' and call it)
 
# Payload construction using raw bytes for clarity:
# c = GLOBAL opcode
# ( = MARK
# t = TUPLE
# R = REDUCE
 
payload = b"cctypes\nCDLL\n(S'libc.so.6'\ntR(S'system'\ntR(S'id'\ntR."

When this payload is analyzed by a vulnerable version of Fickling, the result is Severity.LIKELY_SAFE. When loaded by a victim application using pickle.loads(), it executes the id command immediately.

The vulnerability represents a critical failure in the security controls provided by the library. Fickling is explicitly marketed as a tool to detect malicious pickles; failing to detect standard library exploits renders the tool ineffective for its primary use case.

Technical Impact

• Arbitrary Code Execution (ACE): Successful exploitation grants the attacker full code execution privileges in the context of the application parsing the pickle.
• Data Confidentiality: Attackers can read sensitive files, environment variables, or database credentials.
• Integrity: Attackers can modify data, install persistence mechanisms, or pivot to other systems on the network.

Business Impact Organizations integrating Fickling into automated pipelines (e.g., for scanning uploaded Machine Learning models) face the highest risk. If a pipeline automatically deploys a model deemed "safe" by Fickling, an attacker could introduce a backdoor into production inference servers. The vulnerability has a CVSS v4.0 score of 8.9 (High), reflecting the high impact on Confidentiality, Integrity, and Availability with a low attack complexity.

The primary remediation is to upgrade the Fickling library to version 0.1.7 or later. This version includes the expanded blocklist and improved validation logic.

Immediate Actions

1. Identify Vulnerable Instances: Scan dependency trees for fickling < 0.1.7.
2. Upgrade: Update to the latest version using pip: pip install --upgrade fickling.
3. Rescan Artifacts: Any pickle files previously marked as safe by the vulnerable version should be quarantined and re-analyzed with the patched version.

Strategic Recommendations Security teams should recognize that blocklisting (enumerating "bad" things) is inherently fragile compared to allowlisting (enumerating "good" things). The Python pickle format is Turing-complete and notoriously difficult to secure.

• Avoid Pickles: Where possible, transition to safer serialization formats. For Machine Learning models, use Safetensors or ONNX, which are designed to store tensors without executable code capabilities.
• Sandboxing: If pickle processing is unavoidable, ensure it occurs within a strictly isolated sandbox (e.g., ephemeral containers, gVisor, or restricted microVMs) with no access to sensitive networks or data.