CVE-2025-71339: Picklescan Gadget Bypass Allows Arbitrary Code Execution

Technical summary

CVE-2025-71339 is a gadget-chain bypass vulnerability in Picklescan's pickle validation logic. The vulnerability stems from Picklescan's failure to detect the numpy.f2py.crackfortran._eval_length gadget when it appears within __reduce__ methods—a standard Python serialization hook. This gadget chain can be leveraged to achieve arbitrary code execution despite Picklescan's filtering mechanisms. The attack relies on user trust in Picklescan's validation; victims must load a pickle file that Picklescan has incorrectly marked as safe. The vulnerability is rooted in CWE-502 (Deserialization of Untrusted Data), a well-known class of attacks where unsafe deserialization enables remote code execution.

Business impact

Organizations relying on Picklescan as a security control for processing untrusted pickle files face a critical trust boundary violation. If teams use Picklescan to validate pickle files before loading them in data processing pipelines, machine learning workflows, or other automation, attackers can bypass that validation. The impact extends beyond direct code execution: compromised environments may be used for lateral movement, data exfiltration, supply chain attacks, or persistent access. Teams should assume that any pickle files validated with vulnerable Picklescan versions may contain undetected malicious payloads.

Affected systems

All deployments of Picklescan prior to version 0.0.33 are vulnerable. This includes any system using Picklescan in data ingestion pipelines, security scanning workflows, or automated pickle validation. The vulnerability does not require network access to Picklescan itself—only the ability to place a malicious pickle file where a victim using vulnerable Picklescan will load it. Organizations using Picklescan for security scanning in CI/CD pipelines, data lakes, or model repositories are at elevated risk.

Exploitability

The attack has a network attack vector (AV:N) and low attack complexity (AC:L), meaning exploitation requires no special conditions or preconditions beyond convincing a user to load a pickle file. The requirement for user interaction (UI:R) is met when an attacker tricks or socially engineers a victim into processing a malicious pickle file they believe is safe due to Picklescan's validation. Creating such a file requires knowledge of the numpy.f2py.crackfortran._eval_length gadget but no zero-day; proof-of-concept code demonstrating this bypass is likely to appear quickly if it has not already. The practical exploitability is moderate-to-high because the attack depends on organizational trust in Picklescan rather than on system-level flaws.

Remediation

Upgrade Picklescan to version 0.0.33 or later immediately. This version contains detection logic to identify and reject the numpy.f2py.crackfortran._eval_length gadget. Additionally, organizations should audit their pickle processing pipelines: confirm that Picklescan was the sole validation layer, identify any pickle files processed by vulnerable versions, and consider regenerating them from trusted sources. In parallel, implement defense-in-depth controls such as running pickle deserialization in isolated sandboxes, restricting pickle loading to internal sources only, and monitoring for suspicious execution patterns downstream of pickle processing.

Patch guidance

Apply the update to Picklescan 0.0.33 or later across all systems where it is deployed. Verify the upgrade by checking the installed version (e.g., pip show picklescan or equivalent). Test the patched version in a staging environment to ensure no compatibility issues with your validation workflow. Given that this is a tool you likely control directly, updating should be low-friction compared to patching third-party applications. Prioritize systems in data processing pipelines and CI/CD environments where pickle files from external or semi-trusted sources are regularly processed.

Detection guidance

Identify systems using Picklescan by auditing package management systems (pip, poetry, conda), configuration files, and requirements.txt entries. Log the version numbers of Picklescan deployed. Review recent logs for pickle file processing—look for files that were validated by Picklescan and later executed or deserialized. If you have threat hunting capabilities, search for execution patterns involving numpy.f2py.crackfortran or unusual subprocess/exec calls immediately following pickle deserialization. Inspect any pickle files processed during the vulnerable window (between Picklescan's initial release and June 23, 2026) if they originated from untrusted sources. Consider running such files through an updated Picklescan instance in an isolated environment to confirm whether they are now flagged as malicious.

Why prioritize this

This vulnerability warrants urgent prioritization because it directly undermines a security control (Picklescan) that organizations rely on to prevent pickle-based code execution. The CVSS score of 8.1 (HIGH) reflects the combination of network-accessible exploitation, low complexity, and high confidentiality and integrity impact. The gadget bypass is specific but not obscure; any attacker with knowledge of Python gadget chains can likely craft exploits. The attack vector is particularly dangerous because it exploits organizational trust—victims believe Picklescan has validated the file—making the payload more likely to be loaded. Teams using Picklescan for security purposes should treat this as a critical issue regardless of other risk factors.

Risk score, explained

The CVSS 3.1 score of 8.1 is derived from: AV:N (network-accessible), AC:L (no special conditions), PR:N (no privileges required), UI:R (user interaction needed—loading the file), S:U (no scope change), C:H (high confidentiality impact from arbitrary code execution), I:H (high integrity impact), and A:N (no direct availability impact, though code execution could enable denial of service). The score appropriately reflects the severity of a gadget-chain bypass that allows code execution when a security control is defeated. The user interaction requirement prevents a fully critical score, but the impact is substantial because the interaction is social engineering rather than a technical barrier.

Frequently asked questions