CVE-2026-22608

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.

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.

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.

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.

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.

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.