CVE-2025-71340: Picklescan Evasion via idlelib.pyshell.ModifiedInterpreter

Technical summary

The vulnerability stems from incomplete bytecode pattern matching in picklescan's malicious payload detection logic. Pickle's `__reduce__` protocol allows objects to define custom unpickling behavior by returning a callable and its arguments. Picklescan's scanner, designed to block dangerous callables, does not adequately flag calls to `idlelib.pyshell.ModifiedInterpreter.runcode`—an interface method that executes arbitrary Python code during interpreter initialization. By constructing a pickle object that references this method in a `__reduce__` handler, an attacker bypasses picklescan's safety checks entirely. The unpickling process invokes `runcode()` with attacker-controlled arguments, achieving remote code execution. This affects any downstream consumer relying on picklescan to validate pickle integrity before calling `pickle.load()`, particularly users in machine learning workflows where pickled model weights are distributed from external sources.

Business impact

Organizations using picklescan as a gatekeeper for untrusted pickle files face unexpected breach risk. If your supply chain includes downloading pre-trained models or shared Python objects from third parties, an attacker can replace those artifacts with poisoned versions that pass picklescan validation yet execute arbitrary code on your infrastructure upon loading. This undermines the core security promise of the scanning tool. Downstream impact includes data exfiltration, lateral movement, cryptomining, or ransomware installation—all triggered passively when a data scientist loads what they believe is a legitimate model checkpoint. The longer you remain on unpatched versions, the greater the window for undetected compromise.

Affected systems

Any deployment running picklescan version 0.0.26 or earlier is vulnerable. This includes development environments, CI/CD pipelines, and production systems that use picklescan to validate pickle files before deserialization. ML teams relying on picklescan for model artifact security are most at risk. Additionally, any downstream tool, framework, or service that depends on picklescan as a security library is transitively affected unless they upgrade their dependency.

Exploitability

Exploitation requires user interaction: an attacker must craft a malicious pickle file and convince a victim to load it via `pickle.load()` in an environment where picklescan has been run (and passed) as a pre-check. The attacker does not need authentication or special privileges. The technique is not known to be actively weaponized in the wild, but the evasion method is straightforward to implement once the gap is understood. The CVSS score of 8.1 reflects the high impact (code execution, data theft) combined with low barrier to exploitation and the widespread use of pickle in Python ecosystems.

Remediation

Upgrade picklescan to version 0.0.30 or later. Review all pickle files that were validated by older versions during the period they were in use; assume any that were sourced externally may be compromised. If you cannot immediately patch, implement additional controls: (1) isolate pickle deserialization to sandboxed or ephemeral containers; (2) restrict network access from unpickling processes; (3) add runtime monitoring for unexpected child process spawning or shell invocations during model loading; (4) require cryptographic signing of model artifacts at the source, validated before unpickling.

Patch guidance

Update picklescan from your package manager (e.g., `pip install --upgrade picklescan>=0.0.30`) and verify the installed version. This is a safe upgrade with no breaking changes. Coordinate with teams that maintain CI/CD pipelines or shared model repositories to ensure they also bump their picklescan dependency. Test in a non-production environment first if your workflow has custom unpickling logic. Verify against the official picklescan repository (GitHub: trailofbits/picklescan) and the vendor advisory to confirm patched version numbers.

Detection guidance

Monitor for unexpected process spawns, shell invocations, or code execution originating from Python interpreter processes during model loading or pickle deserialization workflows. Watch for direct invocation of `idlelib.pyshell` or similar idle shell components from unpickling contexts. Audit recent pickle files consumed from external sources; if available, re-scan them with picklescan 0.0.30+ to identify previously undetected payloads. Review logs for `pickle.load()` calls on untrusted input and cross-reference timestamps with any suspicious system activity.

Why prioritize this

Prioritize this patch within 48–72 hours if you maintain any supply chain distribution of models or serialized objects, or if your organization consumes externally sourced pickle files. The vulnerability directly undermines a security control your team likely relies on, and exploitation is user-triggered (not a server-side flaw that would auto-execute). The high CVSS and ease of exploitation once a pickle is loaded warrant swift action, but this is not an emergency zero-day affecting deployed systems without user interaction.

Risk score, explained

CVSS 8.1 (HIGH) is justified by: (1) Network-accessible attack vector (attacker can distribute a malicious pickle remotely); (2) Low attack complexity (no special setup needed, just a crafted file); (3) No privileges required; (4) User interaction required (file must be loaded); (5) High confidentiality and integrity impact (arbitrary code execution means data theft and system compromise are possible); (6) No availability impact (code runs in user process, not DoS). The score correctly reflects that while dangerous, the barrier to user interaction is non-trivial, preventing a critical 9.0+ rating.

Frequently asked questions