CVE-2026-14534
HighCVSS 8.8Exploitation Probability (EPSS)
Low risk48th percentile - higher than 48% of all known CVEs
Summary
The vulnerability in fickling up to version 0.1.10 is due to missing Python standard library modules (_posixsubprocess, site, atexit) in the UNSAFE_IMPORTS denylist. This causes check_safety() to incorrectly mark malicious pickle payloads as LIKELY_SAFE, allowing deserialization and execution of dangerous functions like fork_exec, execsitecustomize, or _run_exitfuncs.
Risk Assessment
An attacker can remotely execute arbitrary binary code or Python scripts on the server, leading to full system compromise, data theft, or service disruption.
Recommendation
Immediately update fickling to version 0.1.11 or later, which includes the corrected UNSAFE_IMPORTS list. Until updated, manually block deserialization of pickle payloads containing the mentioned modules.
Other vulnerabilities in fickling
See all- CVE-2026-22612High
Fickling, a Python pickling decompiler and static analyzer, before version 0.1.7 contains a vulnerability that allows bypassing detection of malicious code. The issue stems from a lack of analysis of 'builtins' objects and has been fixed in version 0.1.7.
- CVE-2026-22609High
Fickling is a Python pickling decompiler and static analyzer. Prior to version 0.1.7, the unsafe_imports() method in Fickling's static analyzer fails to flag several high-risk Python modules that can be used for arbitrary code execution. Malicious pickles importing these modules will not be detected as unsafe, allowing attackers to bypass Fickling's primary static safety checks.
- CVE-2026-22608High
Fickling is a Python pickling decompiler and static analyzer. Prior to version 0.1.7, it did not explicitly block the ctypes and pydoc modules, which combined with pydoc.locate can achieve RCE while the scanner still reports the file as LIKELY_SAFE. This issue has been patched in version 0.1.7.
- CVE-2026-22607High
Fickling versions up to and including 0.1.6 do not treat Python's cProfile module as unsafe. A malicious pickle using cProfile.run() is classified as SUSPICIOUS instead of OVERTLY_MALICIOUS, potentially leading to arbitrary code execution.
- CVE-2026-22606High
Fickling versions up to and including 0.1.6 do not treat Python's runpy module as unsafe. A malicious pickle using runpy.run_path() or runpy.run_module() is classified as SUSPICIOUS instead of OVERTLY_MALICIOUS. This can lead to arbitrary code execution if users rely on Fickling's output for deserialization safety.
- CVE-2026-16760High
fickling through 0.1.12 incorrectly treats calls to functions from Python standard library modules as safe without inspecting their actual behavior. As a result, check_safety() returns LIKELY_SAFE for malicious pickle payloads that reach code execution or file writes through such callables (e.g., dataclasses._create_fn, mailcap.findmatch, readline.write_history_file). Because fickling.load() uses this verdict as a security gate before pickle.loads(), the payload is deserialized and executed with the privileges of the victim process.
- CVE-2026-118938High
A vulnerability in Trail of Bits fickling through 0.1.12 allows a pickle STACK_GLOBAL operand with a dotted __qualname__ (e.g., "Values.read_file") to be resolved by pickle's find_class via _getattribute to an arbitrary attribute path instead of a module-level function. Fickling records only the leading component in its import tracking and renders the operation as a plain import, so the trailing attribute reference is never analyzed as a call; the OvertlyBadEvals pass does not flag it and check_safety() returns LIKELY_SAFE with zero findings. This lets an attacker reach a class method that performs code execution (optparse.Values.read_file executes exec(open(filename).read(), vars)), achieving arbitrary code execution when the crafted pickle is loaded through fickling.load(), which chains check_safety() into pickle.loads() as an explicit security gate.
- CVE-2026-14535High
In fickling up to version 0.1.11, the UnsafeImportsML analysis pass registers shortened code for every import in a shared set, causing the subsequent MLAllowlist pass to skip all checks as already reported. This renders MLAllowlist dead code, allowing imports of modules outside the allowlist (e.g., torch, numpy) to be missed, leading to a false LIKELY_SAFE verdict.
- CVE-2025-67748High
Fickling is a Python pickling decompiler and static analyzer. Versions prior to 0.1.6 had a bypass caused by `pty` missing from the block list of unsafe module imports. This led to unsafe pickles based on `pty.spawn()` being incorrectly flagged as `LIKELY_SAFE`, and was fixed in version 0.1.6. This impacted any user or system that used Fickling to vet pickle files for security issues.
- CVE-2025-67747High
Fickling is a Python pickling decompiler and static analyzer. Versions prior to 0.1.6 are missing `marshal` and `types` from the block list of unsafe module imports. Fickling started blocking both modules to address this issue. This allows an attacker to craft a malicious pickle file that can bypass fickling since it misses detections for `types.FunctionType` and `marshal.loads`. A user who deserializes such a file, believing it to be safe, would inadvertently execute arbitrary code on their system. This impacts any user or system that uses Fickling to vet pickle files for security issues. The issue was fixed in version 0.1.6.
Original NVD description (English source)
Trail of Bits fickling versions up to and including 0.1.10 do not include the Python standard library modules _posixsubprocess, site, and atexit in the UNSAFE_IMPORTS denylist (fickle.py). Because these modules are absent from the denylist, fickling's check_safety() function returns LIKELY_SAFE with zero findings for pickle payloads that invoke dangerous functions including _posixsubprocess.fork_exec (C-level process spawner capable of executing arbitrary binaries), site.execsitecustomize (executes arbitrary site customization code), and atexit._run_exitfuncs (triggers all registered exit handler callbacks). The fickling.load() API chains check_safety() into pickle.loads() as an explicit security gate; a LIKELY_SAFE verdict causes the payload to be deserialized and executed. This shares the same root cause as CVE-2026-22607 (cProfile), CVE-2025-67748 (pty), and CVE-2025-67747 (marshal/types). OvertlyBadEvals does not flag these modules because they are standard library imports. UnsafeImports does not flag them because they are not in the denylist. The UnusedVariables heuristic is defeated by the SETITEMS opcode pattern.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

