Fickling
Monthly
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.
Trail of Bits Fickling versions before 0.1.6 fail to flag malicious pickles as unsafe because the `pty` module was omitted from the tool's blocklist of dangerous imports, allowing a crafted pickle that invokes `pty.spawn()` to be reported as LIKELY_SAFE. The bypass matters in any workflow where a user, analyst, or CI pipeline uses Fickling as a security gate and then unpickles a file it has cleared, resulting in arbitrary code execution on the machine doing the deserialization; the CVSS 4.0 base score is 7.1 (AV:L/AC:L/AT:N/PR:N/UI:P with high confidentiality, integrity and availability impact), reflecting a local, high-impact outcome gated by passive user interaction rather than remote reach. Publicly available exploit code exists, there is no indication of confirmed in-the-wild exploitation (the issue is not listed in CISA KEV), and a vendor fix is available in 0.1.6.
Deserialization of an attacker-supplied pickle file that has been vetted by Fickling versions prior to 0.1.6 can execute arbitrary code because the analyzer's unsafe-import block list omitted the 'marshal' and 'types' modules, allowing payloads built on marshal.loads and types.FunctionType to pass the scan as 'LIKELY_SAFE'. The flaw affects any user or pipeline that trusts Fickling as a safety gate for untrusted pickles and then unpickles the file; because Fickling is the inspection tool rather than the execution sink, code only runs when the file is subsequently loaded, and the CVSS 4.0 vector (AV:L/AC:L/PR:N/UI:P) and the independent assessment (AV:L/AC:L/PR:N/UI:R) both confirm that unauthenticated attackers need the victim to run the scan and then choose to deserialize the file. Publicly available exploit code exists - the upstream GHSA advisory itself includes a disassembled malicious pickle and a regression test - but there is no confirmed active exploitation (no CISA KEV listing), and the vendor-released patch fixes the issue in Fickling 0.1.6.
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.
Trail of Bits Fickling versions before 0.1.6 fail to flag malicious pickles as unsafe because the `pty` module was omitted from the tool's blocklist of dangerous imports, allowing a crafted pickle that invokes `pty.spawn()` to be reported as LIKELY_SAFE. The bypass matters in any workflow where a user, analyst, or CI pipeline uses Fickling as a security gate and then unpickles a file it has cleared, resulting in arbitrary code execution on the machine doing the deserialization; the CVSS 4.0 base score is 7.1 (AV:L/AC:L/AT:N/PR:N/UI:P with high confidentiality, integrity and availability impact), reflecting a local, high-impact outcome gated by passive user interaction rather than remote reach. Publicly available exploit code exists, there is no indication of confirmed in-the-wild exploitation (the issue is not listed in CISA KEV), and a vendor fix is available in 0.1.6.
Deserialization of an attacker-supplied pickle file that has been vetted by Fickling versions prior to 0.1.6 can execute arbitrary code because the analyzer's unsafe-import block list omitted the 'marshal' and 'types' modules, allowing payloads built on marshal.loads and types.FunctionType to pass the scan as 'LIKELY_SAFE'. The flaw affects any user or pipeline that trusts Fickling as a safety gate for untrusted pickles and then unpickles the file; because Fickling is the inspection tool rather than the execution sink, code only runs when the file is subsequently loaded, and the CVSS 4.0 vector (AV:L/AC:L/PR:N/UI:P) and the independent assessment (AV:L/AC:L/PR:N/UI:R) both confirm that unauthenticated attackers need the victim to run the scan and then choose to deserialize the file. Publicly available exploit code exists - the upstream GHSA advisory itself includes a disassembled malicious pickle and a regression test - but there is no confirmed active exploitation (no CISA KEV listing), and the vendor-released patch fixes the issue in Fickling 0.1.6.