Track vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
8.8
CVE-2026-14535: Fickling may load unsafe modules during pickle deserialization
CVE-2026-14535 · published 4 months ago
Summary
The Python tool fickling (versions up to 0.1.11) has a coding mistake that stops one of its safety checks from running. As a result, code that’s saved in a pickle file can bring in unexpected Python modules and be executed, even though the tool says the file looks safe. Update to a newer release or stop using fickling to load untrusted pickle data until the problem is fixed.
What to do
The CVE record does not list a fixed version. Check the vendor's site or the advisory links below - a fix may already be released.
Affected software
| Vendor | Product | Affected versions |
|---|---|---|
| trailofbits | fickling | <= 0.1.11 |
Original advisory text
Fickling MLAllowlist analysis pass rendered inoperative by shared mutable state in AnalysisContext.shorten_code()
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.
References
- https://github.com/trailofbits/fickling/releases/tag/v0.1.12 URL
- https://github.com/trailofbits/fickling/security/advisories/GHSA-cffv-grgg-g429 Vendor Advisory
- https://github.com/trailofbits/fickling/commit/41ce7cb01edd97072994039574a2301eb... Patch
- https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/14xxx/CVE-2026-14535... Vendor Advisory
- https://nvd.nist.gov/vuln/detail/CVE-2026-14535 Vendor Advisory
- https://github.com/trailofbits/fickling/pull/278 Patch
- https://pypi.org/project/fickling/ Product
Internet-facing
14 days
Internal
At next upgrade
- Not known to be exploited
- Needs hands-on effort to exploit
- Gives an attacker full control
Type
CWE-693Protection Mechanism Failure
Timeline
Published4 Jul 2026
Updated4 Nov 2026
First seen4 Jul 2026
Track software like this
Free during beta