Trailofbits
Monthly
Pickle-analysis bypass in Trail of Bits fickling through 0.1.12 and vendor master commit d011709 allows arbitrary code execution when a victim uses fickling.load() or check_safety() as a safety gate on a crafted pickle, with CVSS 8.8 (AV:N/AC:L/PR:N/UI:R). The crafted pickle uses a dotted __qualname__ such as optparse.Values.read_file, which fickling records and renders as a plain import and never analyzes as a call, so OvertlyBadEvals does not flag it and check_safety() returns LIKELY_SAFE with zero findings while pickle resolution reaches a code-executing class method. No public exploit identified at time of analysis, and exploitation requires the victim to actively run fickling against the malicious pickle; the advisory states the bypass remained present on vendor master at commit d011709 as of 2026-10-30 and the vuln.today priority is this_week.
fickling through 0.1.12 misclassifies malicious pickle payloads as safe: its OvertlyBadEvals analysis pass skips any call whose name was added to the likely_safe_imports set purely because the source module appears in sys.stdlib_module_names, so check_safety() can return LIKELY_SAFE with zero findings for payloads that reach code execution or arbitrary file write. Because fickling.load() chains check_safety() into pickle.loads() as a security gate, a victim who runs unauthenticated, attacker-supplied pickle or model content through the tool (the required user interaction, UI:R) can end up executing that content with the privileges of the analysis process. The advisory demonstrates three concrete primitives - dataclasses._create_fn (Python 3.7-3.12), mailcap.findmatch (through Python 3.12) and readline.add_history()/write_history_file() on POSIX - while noting the underlying module-origin trust root cause is broader and remains unfixed; no public exploit code is referenced in the available intelligence and there is no KEV entry, but the tool's whole purpose is vetting untrusted pickles, so the severity is real for anyone relying on it as a gate.
Security-control bypass in Trail of Bits fickling (≤0.1.11) neuters its MLAllowlist analysis pass so that malicious pickle files pass fickling's check_safety() gate as LIKELY_SAFE, enabling arbitrary code execution when fickling.load() deserializes them. Because UnsafeImportsML pre-registers every import in the shared reported_shortened_code set, MLAllowlist always short-circuits and never validates imports against the known-safe ML ecosystem, so any standard-library module outside the UNSAFE_IMPORTS denylist can be smuggled through. Publicly available exploit code exists (SSVC 'poc'); it is not listed in CISA KEV and EPSS is low (0.30%), consistent with a demonstrated-but-not-yet-widespread threat.
Arbitrary code execution bypass in Trail of Bits fickling (versions ≤ 0.1.10) allows attackers to craft malicious pickle files that the tool's check_safety() gate rates LIKELY_SAFE with zero findings. Because the standard-library modules _posixsubprocess, site, and atexit are missing from the UNSAFE_IMPORTS denylist in fickle.py, payloads invoking _posixsubprocess.fork_exec, site.execsitecustomize, or atexit._run_exitfuncs pass the scanner and are then deserialized and executed by fickling.load(), which chains check_safety() into pickle.loads() as its security gate. No public exploit has been identified at time of analysis, and no EPSS or KEV signals are present in the input, but the advisory documents the exact bypass primitives.
Fickling versions prior to 0.1.7 fail to properly detect malicious pickle payloads due to inadequate handling of the "builtins" module, allowing attackers to bypass security analysis and potentially execute arbitrary code. This vulnerability affects Python environments using vulnerable versions of Fickling for pickle inspection and static analysis. An attacker can craft specially designed pickle files that evade detection mechanisms, compromising the integrity of pickle validation workflows.
Fickling's static analyzer before version 0.1.7 fails to detect several dangerous Python modules in pickled objects, enabling attackers to craft malicious pickles that bypass safety checks and achieve arbitrary code execution. This vulnerability affects users relying on Fickling to validate untrusted serialized Python objects for safety. Public exploit code exists for this HIGH severity vulnerability, though a patch is available in version 0.1.7 and later.
Fickling before version 0.1.7 allows local attackers to achieve arbitrary code execution through Python pickle deserialization by chaining unblocked ctypes and pydoc modules, bypassing the tool's safety scanner which incorrectly reports malicious files as LIKELY_SAFE. An attacker with user interaction can exploit this vulnerability to execute code with the privileges of the Python process. A patch is available in version 0.1.7 and later.
Fickling's static analyzer through version 0.1.6 fails to properly classify the cProfile module as unsafe during pickle analysis, causing malicious pickles leveraging cProfile.run() to be marked as SUSPICIOUS rather than OVERTLY_MALICIOUS. Organizations using Fickling as a security gate for deserialization decisions may be deceived into executing attacker-controlled code. Public exploit code exists for this vulnerability, and patches are available in version 0.1.7 and later.
Fickling's incomplete pickle analysis allows attackers to bypass security checks by using Python's runpy module to execute arbitrary code. Versions through 0.1.6 misclassify dangerous runpy-based payloads as merely suspicious rather than malicious, enabling code execution on systems that rely on Fickling to validate pickle safety. Public exploit code exists for this vulnerability, though a patch is available in version 0.1.7.
uthenticode is a small cross-platform library for partially verifying Authenticode digital signatures. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
uthenticode is a small cross-platform library for partially verifying Authenticode digital signatures. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Pickle-analysis bypass in Trail of Bits fickling through 0.1.12 and vendor master commit d011709 allows arbitrary code execution when a victim uses fickling.load() or check_safety() as a safety gate on a crafted pickle, with CVSS 8.8 (AV:N/AC:L/PR:N/UI:R). The crafted pickle uses a dotted __qualname__ such as optparse.Values.read_file, which fickling records and renders as a plain import and never analyzes as a call, so OvertlyBadEvals does not flag it and check_safety() returns LIKELY_SAFE with zero findings while pickle resolution reaches a code-executing class method. No public exploit identified at time of analysis, and exploitation requires the victim to actively run fickling against the malicious pickle; the advisory states the bypass remained present on vendor master at commit d011709 as of 2026-10-30 and the vuln.today priority is this_week.
fickling through 0.1.12 misclassifies malicious pickle payloads as safe: its OvertlyBadEvals analysis pass skips any call whose name was added to the likely_safe_imports set purely because the source module appears in sys.stdlib_module_names, so check_safety() can return LIKELY_SAFE with zero findings for payloads that reach code execution or arbitrary file write. Because fickling.load() chains check_safety() into pickle.loads() as a security gate, a victim who runs unauthenticated, attacker-supplied pickle or model content through the tool (the required user interaction, UI:R) can end up executing that content with the privileges of the analysis process. The advisory demonstrates three concrete primitives - dataclasses._create_fn (Python 3.7-3.12), mailcap.findmatch (through Python 3.12) and readline.add_history()/write_history_file() on POSIX - while noting the underlying module-origin trust root cause is broader and remains unfixed; no public exploit code is referenced in the available intelligence and there is no KEV entry, but the tool's whole purpose is vetting untrusted pickles, so the severity is real for anyone relying on it as a gate.
Security-control bypass in Trail of Bits fickling (≤0.1.11) neuters its MLAllowlist analysis pass so that malicious pickle files pass fickling's check_safety() gate as LIKELY_SAFE, enabling arbitrary code execution when fickling.load() deserializes them. Because UnsafeImportsML pre-registers every import in the shared reported_shortened_code set, MLAllowlist always short-circuits and never validates imports against the known-safe ML ecosystem, so any standard-library module outside the UNSAFE_IMPORTS denylist can be smuggled through. Publicly available exploit code exists (SSVC 'poc'); it is not listed in CISA KEV and EPSS is low (0.30%), consistent with a demonstrated-but-not-yet-widespread threat.
Arbitrary code execution bypass in Trail of Bits fickling (versions ≤ 0.1.10) allows attackers to craft malicious pickle files that the tool's check_safety() gate rates LIKELY_SAFE with zero findings. Because the standard-library modules _posixsubprocess, site, and atexit are missing from the UNSAFE_IMPORTS denylist in fickle.py, payloads invoking _posixsubprocess.fork_exec, site.execsitecustomize, or atexit._run_exitfuncs pass the scanner and are then deserialized and executed by fickling.load(), which chains check_safety() into pickle.loads() as its security gate. No public exploit has been identified at time of analysis, and no EPSS or KEV signals are present in the input, but the advisory documents the exact bypass primitives.
Fickling versions prior to 0.1.7 fail to properly detect malicious pickle payloads due to inadequate handling of the "builtins" module, allowing attackers to bypass security analysis and potentially execute arbitrary code. This vulnerability affects Python environments using vulnerable versions of Fickling for pickle inspection and static analysis. An attacker can craft specially designed pickle files that evade detection mechanisms, compromising the integrity of pickle validation workflows.
Fickling's static analyzer before version 0.1.7 fails to detect several dangerous Python modules in pickled objects, enabling attackers to craft malicious pickles that bypass safety checks and achieve arbitrary code execution. This vulnerability affects users relying on Fickling to validate untrusted serialized Python objects for safety. Public exploit code exists for this HIGH severity vulnerability, though a patch is available in version 0.1.7 and later.
Fickling before version 0.1.7 allows local attackers to achieve arbitrary code execution through Python pickle deserialization by chaining unblocked ctypes and pydoc modules, bypassing the tool's safety scanner which incorrectly reports malicious files as LIKELY_SAFE. An attacker with user interaction can exploit this vulnerability to execute code with the privileges of the Python process. A patch is available in version 0.1.7 and later.
Fickling's static analyzer through version 0.1.6 fails to properly classify the cProfile module as unsafe during pickle analysis, causing malicious pickles leveraging cProfile.run() to be marked as SUSPICIOUS rather than OVERTLY_MALICIOUS. Organizations using Fickling as a security gate for deserialization decisions may be deceived into executing attacker-controlled code. Public exploit code exists for this vulnerability, and patches are available in version 0.1.7 and later.
Fickling's incomplete pickle analysis allows attackers to bypass security checks by using Python's runpy module to execute arbitrary code. Versions through 0.1.6 misclassify dangerous runpy-based payloads as merely suspicious rather than malicious, enabling code execution on systems that rely on Fickling to validate pickle safety. Public exploit code exists for this vulnerability, though a patch is available in version 0.1.7.
uthenticode is a small cross-platform library for partially verifying Authenticode digital signatures. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
uthenticode is a small cross-platform library for partially verifying Authenticode digital signatures. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.