runpy was added to the list of unsafe imports (https://github.com/trailofbits/fickling/commit/9a2b3f89bd0598b528d62c10a64c1986fcb09f66).
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.run_path() or runpy.run_module() is classified as SUSPICIOUS instead of OVERTLY_MALICIOUS.
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.
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:
fickling/analysis.pyUnsafeImportsrunpy, runpy.run_path, runpy.run_module, or runpy._run_codeReference to similar fix:
pty to the blocklist to fix CVE-2025-67748runpyHow the bypass works:
runpy.run_path() in __reduce__UnsafeImports analysis does not flag runpy as dangerousUnusedVariables heuristic triggers, resulting in SUSPICIOUS severityOVERTLY_MALICIOUS like os.system, eval, and execTested behavior (fickling 0.1.6):
| Function | Fickling Severity | RCE Capable | |-------------------|----------------------------|-------------| | os.system | LIKELY_OVERTLY_MALICIOUS | Yes | | eval | OVERTLY_MALICIOUS | Yes | | exec | OVERTLY_MALICIOUS | Yes |...
0.1.7Exploitability
AV:NAC:LAT:NPR:NUI:NVulnerable System
VC:HVI:HVA:HSubsequent System
SC:NSI:NSA:N8.9/CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P