© 2025-2026 PySpect
First version without a known vulnerability: 0.1.12
In Trail of Bits fickling versions up to and including 0.1.11, the UnsafeImportsML analysis pass unconditionally calls AnalysisContext.shorten_code(node) on every import node it inspects, regardless of whether the import is flagged as unsafe. This call registers the shortened code representation in the shared AnalysisContext.reported_shortened_code set. When the MLAllowlist analysis pass subsequently runs, it calls the same shorten_code() method, receives already_reported=True for every import, and executes a continue statement that skips its allowlist check entirely. This renders MLAllowlist dead code for all imports — it never evaluates whether an import is in the ML allowlist or not. The MLAllowlist pass was designed to catch imports of modules outside the known-safe ML ecosystem (torch, numpy, transformers, etc.) that slip past the UnsafeImports denylist. With MLAllowlist inoperative, any standard library module not in the UNSAFE_IMPORTS denylist can be invoked via pickle deserialization while fickling's check_safety() returns LIKELY_SAFE. The fickling.load() API chains check_safety() into pickle.loads() as an explicit security gate, meaning a LIKELY_SAFE verdict causes the payload to be deserialized and executed. The root cause is shared mutable state between independently-correct analysis passes — UnsafeImportsML works as designed in isolation, MLAllowlist works as designed in isolation, but the shared reported_shortened_code set causes UnsafeImportsML to poison MLAllowlist's deduplication logic.
Fixed in: 0.1.12
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.
Fixed in: 0.1.11
fickling's `platform` module subprocess invocation evades `check_safety()` with `LIKELY_SAFE`
Fixed in: 0.1.10
fickling modules linecache, difflib and gc are missing from the unsafe modules blocklist
Fixed in: 0.1.10
Fickling missing RCE-capable modules in UNSAFE_IMPORTS
Fixed in: 0.1.9
Fickling has `always_check_safety()` bypass: pickle.loads and _pickle.loads remain unhooked
Fixed in: 0.1.9
Fickling has safety check bypass via REDUCE+BUILD opcode sequence
Fixed in: 0.1.8
Fickling: OBJ opcode call invisibility bypasses all safety checks
Fixed in: 0.1.8
Fickling has a detection bypass via stdlib network-protocol constructors
Fixed in: 0.1.8
Fickling vulnerable to detection bypass due to "builtins" blindness
Fixed in: 0.1.7
Fickling has Static Analysis Bypass via Incomplete Dangerous Module Blocklist
Fixed in: 0.1.7
Fickling vulnerable to use of ctypes and pydoc gadget chain to bypass detection
Fixed in: 0.1.7
Fickling Blocklist Bypass: cProfile.run()
Fixed in: 0.1.7
Fickling has a bypass via runpy.run_path() and runpy.run_module()
Fixed in: 0.1.7
Fickling has Code Injection vulnerability via pty.spawn()
Fixed in: 0.1.6
Fickling has missing detection for marshal.loads and types.FunctionType in unsafe modules list
Fixed in: 0.1.6