Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🛡️
Not in CISA KEV
HIGH severity

GHSA-cffv-grgg-g429 — fickling

HIGHFix: trailofbits/fickling@41ce7cb

GHSA-cffv-grgg-g429 is a high-severity (CVSS 8.8) CWE-693 vulnerability. A fix is available — see the affected versions and patch details below.

Fickling MLAllowlist analysis pass rendered inoperative by shared mutable state in AnalysisContext.shorten_code()

Also known asPYSEC-2026-2150
Published
Jul 4, 2026
Updated
Aug 12, 2026
Affected
1 product
Patched
See advisory
Exploits
None indexed
Exploitation data as of Sep 30, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • A successful exploit gives an attacker total control of the affected component, not partial access.

Exploitation and automatability from CISA’s SSVC triage for GHSA-cffv-grgg-g429.

EPSS Exploitation Probability

via FIRST.org ↗
0.6%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs45th percentile — riskier than 45% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-cffv-grgg-g429 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 380,526 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Description

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.

Affected Products

1 product · 1 configurations
Application
ficklingtrailofbits
≤ 0.1.11
range

Detection & mitigation playbook

Vulnerability
  1. Detect

    Identify every host running the affected component and compare the installed build against the fixed version below — for source-built or distro-packaged software the version string, not a lockfile, is the source of truth (`dpkg -l`, `rpm -q`, or the binary's own `--version`).

  2. Fix

    Upgrade the affected component to the fixed release for GHSA-cffv-grgg-g429, or apply your distribution's backported patch — distro builds are often patched at an older version number, so check your vendor's advisory rather than the upstream version alone.

  3. Workarounds

    Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

A flaw was found in Trail of Bits fickling versions through 0.1.11, where a logic error in the security analysis pipeline silently disables the MLAllowlist safety check. The UnsafeImportsML pass inadvertently populates the shared reported_shortened_code set for all imports, causing the MLAllowlist pass to skip its…

Workaround published by Red Hat
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
Source: Red Hat security advisory for GHSA-cffv-grgg-g429 (CC BY 4.0)

Frequently Asked Questions

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
O3 Security · Impact-Aware SCA

Is GHSA-cffv-grgg-g429 in your dependencies?

Find it across , including transitive dependencies.

GHSA-cffv-grgg-g429: fickling (High 8.8) | O3 Security