Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
16 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 0.1.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.…
Recommended action: Upgrade to 0.1.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Our assessment We added platform to the blocklist of unsafe modules (https://github.com/trailofbits/fickling/commit/351ed4d4242b447c0ffd550bb66b40695f3f9975). It was not possible to inject extra arguments to file without first monkey-patching platform.followsymlinks with the pickle, as it always returns an absolute path. We independently hardened it with https://github.com/trailofbits/fickling/commit/b9e690c5a57ee9cd341de947fc6151959f4ae359 to reduce the risk of obtaining direct module references while evading detection. https://github.com/python/cpython/blob/6d1e9ceed3e70ebc39953f5ad4f20702ffa32119/Lib/platform.py#L687-L695 Original report Summary A crafted pickle invoking platform.syscmdfile, platform.architecture, or platform.libcver passes checksafety() with Severity.LIKELYSAFE and zero findings. During fickling.loads(), these functions invoke subprocess.checkoutput with attacker-controlled arguments or read arbitrary files from disk. Clarification: The subprocess call uses a…
Recommended action: Upgrade to 0.1.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Our analysis As stated in the project's security policy, we also don't consider UnusedVariables bypasses to be security issues. We added several unsafe modules mentioned by the reporter in advisory comments to the blocklist (https://github.com/trailofbits/fickling/commit/7f39d97258217ee2c21a1f5031d4a6d7343eb30d). Original report Title: UnusedVariables analysis bypass via BUILD opcode Arbitrary File Read through fickling.load() Summary Two independent bugs in fickling's AST-based static analysis combine to allow a malicious pickle file to execute arbitrary stdlib function calls - including reading sensitive files - while checksafety() returns Severity.LIKELYSAFE and fickling.load() completes without raising UnsafeFileError. A server using fickling.load() as a security gate before deserializing untrusted pickle data (its documented use case) is fully bypassed. The attacker receives the contents of any file readable by the server process as the return value of fickling.load(). Details…
Recommended action: Upgrade to 0.1.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Assessment The modules uuid, osxsupport and aixsupport were added to the blocklist of unsafe imports (https://github.com/trailofbits/fickling/commit/ffac3479dbb97a7a1592d85991888562d34dd05b). Original report Summary fickling's UNSAFEIMPORTS blocklist is missing at least 3 stdlib modules that provide direct arbitrary command execution: uuid, osxsupport, and aixsupport. These modules contain functions that internally call subprocess.Popen() or os.system() with attacker-controlled arguments. A malicious pickle file importing these modules passes both UnsafeImports and NonStandardImports checks. Affected Versions - fickling <= 0.1.8 (all versions) Details Missing Modules fickling's UNSAFEIMPORTS (86 modules) does not include: | Module | RCE Function | Internal Mechanism | Importable On | |--------|-------------|-------------------|---------------| | uuid | getcommandstdout(cmd, args) | subprocess.Popen((cmd,) + args, stdout=PIPE, stderr=DEVNULL) | All platforms | | osxsupport |…
Recommended action: Upgrade to 0.1.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Assessment The missing pickle entrypoints pickle.loads, pickle.loads, and pickle.load were added to the hook https://github.com/trailofbits/fickling/commit/8c24c6edabceab156cfd41f4d70b650e1cdad1f7. Original report Summary fickling.alwayschecksafety() does not hook all pickle entry points. pickle.loads, pickle.loads, and pickle.load remain unprotected, enabling malicious payload execution despite global safety mode being enabled. Affected versions <= 0.1.8 (verified on current upstream HEAD as of 2026-03-03) Non-duplication check against published Fickling GHSAs No published advisory covers hook-coverage bypass in runhook(). Existing advisories are blocklist/detection bypasses (runpy, pty, cProfile, marshal/types, builtins, network constructors, OBJ visibility, etc.), not runtime hook coverage parity. Root cause runhook() patches only: - pickle.load - pickle.Unpickler - pickle.Unpickler It does not patch: - pickle.loads - pickle.load - pickle.loads Reproduction (clean upstream)…
Recommended action: Upgrade to 0.1.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Assessment It is believed that the analysis pass works as intended, REDUCE and BUILD are not at fault here. The few potentially unsafe modules have been added to the blocklist (https://github.com/trailofbits/fickling/commit/0c4558d950daf70e134090573450ddcedaf10400). Original report Summary All 5 of fickling's safety interfaces — islikelysafe(), checksafety(), CLI --check-safety, alwayschecksafety(), and the checksafety() context manager — report LIKELYSAFE / raise no exceptions for pickle files that call dangerous top-level stdlib functions (signal handlers, network servers, network connections, file operations) when the REDUCE opcode is followed by a BUILD opcode. Demonstrated impacts include backdoor network listeners (socketserver.TCPServer), process persistence (signal.signal), outbound data exfiltration (smtplib.SMTP), and file creation on disk (sqlite3.connect). An attacker can append a trivial BUILD opcode to any payload to eliminate all detection. Details The bypass exploits…
Recommended action: Upgrade to 0.1.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Assessment The interpreter so it behaves closer to CPython when dealing with OBJ, NEWOBJ, and NEWOBJEX opcodes (https://github.com/trailofbits/fickling/commit/ff423dade2bb1f72b2b48586c022fac40cbd9a4a). Original report Summary All 5 of fickling's safety interfaces -- islikelysafe(), checksafety(), CLI --check-safety, alwayschecksafety(), and the checksafety() context manager -- report LIKELYSAFE / raise no exceptions for pickle files that use the OBJ opcode to call dangerous stdlib functions (signal handlers, network servers, network connections, file operations). The OBJ opcode's implementation in fickling pushes function calls directly onto the interpreter stack without persisting them to the AST via newvariable(). When the result is discarded with POP, the call vanishes from the final AST entirely, making it invisible to all 9 analysis passes. This is a separate vulnerability from the REDUCE+BUILD bypass, with a different root cause. It survives all three proposed fixes for the…
Recommended action: Upgrade to 0.1.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Our assessment imtplib, imaplib, ftplib, poplib, telnetlib, and nntplib were added to the list of unsafe imports (https://github.com/trailofbits/fickling/commit/6d20564d23acf14b42ec883908aed159be7b9ade). The UnusedVariables heuristic works as expected. Original report Summary Fickling's checksafety() API and --check-safety CLI flag incorrectly rate as LIKELYSAFE pickle files that open outbound TCP connections at deserialization time using stdlib network-protocol constructors: smtplib.SMTP, imaplib.IMAP4, ftplib.FTP, poplib.POP3, telnetlib.Telnet, and nntplib.NNTP. The bypass exploits two independent root causes described below. --- Root Cause 1: Incomplete blocklist (fixed in PR #233) fickling/fickle.py (lines 41-97) defines UNSAFEIMPORTS, the primary blocklist. fickling/analysis.py (lines 229-248) defines the parallel UnsafeImportsML.UNSAFEMODULES dict. Both omitted the following stdlib network-protocol modules whose constructors open a TCP socket at instantiation time: | Module |…
Recommended action: Upgrade to 0.1.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
#Fickling's assessment Fickling started emitting AST nodes for builtins imports in order to match them during analysis (https://github.com/trailofbits/fickling/commit/9f309ab834797f280cb5143a2f6f987579fa7cdf). Original report Summary Fickling works by Pickle bytecode -- AST -- Security analysis However while going from bytecode to AST, some import nodes are removed which blinds the security analysis fickling/fickling/fickle.py Here we see that no import nodes are emitted for builtins However builtins is marked as an unsafe import fickling/fickling/analysis.py But because there are no import nodes for builtins (they werent emitted when making the AST), the security scanner is effectively blind. This can allow for security bypasses like this poc.py (script to create payload) This creates a pickle file which imports the OS module using import which is a part of builtins. if the security scanner wasnt blinded it would have been flagged immidiately. However now fickling sees the pickle…
Recommended action: Upgrade to 0.1.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
#Fickling's assessment ctypes, importlib, runpy, code and multiprocessing were added the list of unsafe imports (https://github.com/trailofbits/fickling/commit/9a2b3f89bd0598b528d62c10a64c1986fcb09f66, https://github.com/trailofbits/fickling/commit/eb299b453342f1931c787bcb3bc33f3a03a173f9, https://github.com/trailofbits/fickling/commit/29d5545e74b07766892c1f0461b801afccee4f91, https://github.com/trailofbits/fickling/commit/b793563e60a5e039c5837b09d7f4f6b92e6040d1, https://github.com/trailofbits/fickling/commit/b793563e60a5e039c5837b09d7f4f6b92e6040d1). Original report Summary The unsafeimports() 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. Details In fickling/fickle.py lines 866-884, the unsafeimports() method checks imported modules against a hardcoded…
Recommended action: Upgrade to 0.1.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Fickling's assessment pydoc and ctypes were added to the list of unsafe imports (https://github.com/trailofbits/fickling/commit/b793563e60a5e039c5837b09d7f4f6b92e6040d1). Original report Summary Both ctypes and pydoc modules arent explictly blocked. Even other existing pickle scanning tools (like picklescan) do not block pydoc.locate. Chaining these two together can achieve RCE while the scanner still reports the file as LIKELYSAFE Details Import: GLOBAL pydoc locate (Allowed). Resolution: Call locate('ctypes.windll.kernel32.WinExec'). Execution: Call the result with (b'calc.exe', 1). To bypass the unused variable check an exception object is used, on the assumption that Exception would not be blocked in the future as it is a benign builtin PoC What fickling sees <img width="915" height="197" alt="image" src="https://github.com/user-attachments/assets/b5d81e0d-4946-4768-a704-618a4554ae7a" /
Recommended action: Upgrade to 0.1.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Fickling's assessment cProfile was added to the list of unsafe imports (https://github.com/trailofbits/fickling/commit/dc8ae12966edee27a78fe05c5745171a2b138d43). Original report Description Summary Fickling versions up to and including 0.1.6 do not treat Python's cProfile module as unsafe. Because of this, a malicious pickle that uses cProfile.run() is classified as SUSPICIOUS instead of OVERTLYMALICIOUS. If a user relies on Fickling's output to decide whether a pickle is safe to deserialize, this misclassification can lead them to execute attacker-controlled code on their system. This affects any workflow or product that uses Fickling as a security gate for pickle deserialization. Details The cProfile module is missing from fickling's block list of unsafe module imports in fickling/analysis.py. This is the same root cause as CVE-2025-67748 (pty) and CVE-2025-67747 (marshal/types). Incriminated source code: - File: fickling/analysis.py - Class: UnsafeImports - Issue: The blocklist…
Recommended action: Upgrade to 0.1.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Fickling's assessment runpy was added to the list of unsafe imports (https://github.com/trailofbits/fickling/commit/9a2b3f89bd0598b528d62c10a64c1986fcb09f66). Original report Summary Fickling versions up to and including 0.1.6 do not treat Python’s runpy module as unsafe. Because of this, a malicious pickle that uses runpy.runpath() or runpy.runmodule() is classified as SUSPICIOUS instead of OVERTLYMALICIOUS. If a user relies on Fickling’s output to decide whether a pickle is safe to deserialize, this misclassification can lead them to execute attacker-controlled code on their system. This affects any workflow or product that uses Fickling as a security gate for pickle deserialization. Details The runpy module is missing from fickling's block list of unsafe module imports in fickling/analysis.py. This is the same root cause as CVE-2025-67748 (pty) and CVE-2025-67747 (marshal/types). Incriminated source code: - File: fickling/analysis.py - Class: UnsafeImports - Issue: The blocklist…
Recommended action: Upgrade to 0.1.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Fickling Assessment Based on the test case provided in the original report below, this bypass was caused by pty missing from our block list of unsafe module imports (as previously documented in #108), rather than the unused variable heuristic. This led to unsafe pickles based on pty.spawn() being incorrectly flagged as LIKELYSAFE, and was fixed in https://github.com/trailofbits/fickling/pull/187. Original report Summary An unsafe deserialization vulnerability in Fickling allows a crafted pickle file to bypass the "unused variable" heuristic, enabling arbitrary code execution. This bypass is achieved by adding a trivial operation to the pickle file that "uses" the otherwise unused variable left on the stack after a malicious operation, tricking the detection mechanism into classifying the file as safe. Details Fickling relies on the heuristic of detecting unused variables in the VM's stack after execution. Opcodes like REDUCE, OBJ, and INST, which can be used for arbitrary code…
Recommended action: Upgrade to 0.1.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Fickling Assessment Based on the test case provided in the original report below, this bypass was caused by marshal and types missing from the block list of unsafe module imports, Fickling started blocking both modules to address this issue. This was fixed in https://github.com/trailofbits/fickling/pull/186. The crash is unrelated and has no security impact—it will be addressed separately. Original report Summary There's missing detection for the python modules, marshal.loads and types.FunctionType and Fickling throws unhandled ValueErrors when the stack is deliberately exhausted. Details Fickling simply doesn't have the aforementioned modules in its list of unsafe imports and therefore it fails to get detected. PoC The following is a disassembled view of a malicious pickle file that uses these modules: When analyzing this modified file, safetyresult.json shows: Furthermore, when we run fickling -s <pathtomaliciousfile, we also encounter this error: Impact This allows an attacker to…
Recommended action: Upgrade to 0.1.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.