CVE-2025-71342: Picklescan Evasion Enables Remote Code Execution in PyTorch Models

Technical summary

CVE-2025-71342 describes an evasion weakness in picklescan's detection logic. The vulnerability exploits picklescan's inability to identify malicious code embedded via reduce methods that reference idlelib.run.Executive.runcode. In Python's pickle protocol, reduce methods are used to serialize custom object state; an attacker can craft a pickle that invokes arbitrary code through this mechanism without raising picklescan's alarm. When pickle.load() deserializes such a file, the malicious runcode method executes in the application's context. This is particularly dangerous in ML/data science workflows where pickle files are the de facto standard for distributing trained models, checkpoints, and datasets. The weakness stems from incomplete gadget chain detection rather than a flaw in pickle itself.

Business impact

Organizations using picklescan as a security gate for untrusted pickle files face undetected compromise. Supply chain attacks become viable: an attacker can inject malicious pickles into public model repositories, package indexes, or shared datasets. Once deployed in production ML pipelines, the code runs with full application privileges. For companies that auto-download and load models (common in MLOps), a single compromised pickle can lead to credential theft, lateral movement, data exfiltration, or infrastructure hijacking. The reputational and operational impact extends to downstream users of affected models, creating cascading risk across research and industry communities.

Affected systems

Directly affected: picklescan versions before 0.0.30. Indirectly at risk: any organization or tool that relies on picklescan to validate pickle safety, particularly in PyTorch-based ML stacks, Hugging Face model loaders, or custom data loading pipelines. Python 3.x environments using pickle deserialization are the execution environment. The vulnerability does not require a specific operating system or architecture; it affects pickle files processed on any platform where picklescan is deployed as a safety filter.

Exploitability

Exploitability is straightforward for an attacker with ability to control or influence a pickle file's contents. No special privileges are needed on the target system. The attack requires user interaction (opening/loading the pickle), but this is the normal expected behavior in ML workflows—users routinely load models and datasets without binary inspection. Network-based delivery is trivial via package repositories, shared storage, or model hubs. The CVSS score of 8.1 (HIGH, AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N) reflects network-accessible exploitation with low complexity, though impact is limited to confidentiality and integrity (not availability). Weaponization is feasible and likely already demonstrated in proof-of-concept form.

Remediation

Upgrade picklescan to version 0.0.30 or later to obtain detection logic that properly handles the idlelib.run.Executive.runcode gadget chain. Organizations should also implement defense-in-depth: (1) run pickle-loading operations in isolated, low-privilege environments; (2) validate pickle source integrity using cryptographic signatures or trusted repository mechanisms; (3) use sandboxing or containerization to limit blast radius; (4) consider alternative serialization formats (e.g., safetensors for ML models) that do not execute arbitrary code; (5) maintain inventory of where pickles are sourced and loaded in your supply chain.

Patch guidance

Apply picklescan 0.0.30 or later immediately in all environments where picklescan is used as a security control. Verify the version using `pip show picklescan` or `python -c "import picklescan; print(picklescan.__version__)"`. Test the patched version against your existing pickle validation pipelines to ensure no false negatives are introduced. For critical ML infrastructure, consider staging the patch in a non-production environment first. Review picklescan's release notes and changelog to confirm the idlelib.run.Executive gadget chain is documented as fixed. Note that patching picklescan alone does not retroactively sanitize pickles already loaded into your systems; treat recent model updates and data loads with suspicion if sourced from public channels during this disclosure window.

Detection guidance

Search logs and audit trails for pickle.load() calls in your codebase and infrastructure, especially those accepting external input or running in auto-scaling ML contexts. Monitor package manager activity for unexpected pickle-related library updates or new pickle dependencies in supply chains you depend on. Use static analysis or code review to identify locations where pickle is deserialized without prior validation. Consider deploying checksums or SBOM tracking for model artifacts to detect tampering. If available, enable detailed logging in pickle loading operations to capture file names, sources, and execution context. Organizations with network monitoring can flag unusual outbound connections from processes that load pickles, as post-exploitation exfiltration is likely.

Why prioritize this

This vulnerability combines high CVSS (8.1) with serious real-world context: PyTorch and similar frameworks use pickles ubiquitously, supply chain attacks are actively weaponized, and the detection evasion is specific and documented. Picklescan is deployed in organizations precisely because they are security-conscious about pickle deserialization; this evasion undermines that control layer. The gap between patched and unpatched versions is clear and actionable. Organizations that depend on picklescan for gate-keeping should treat this as a critical control-plane failure and prioritize patching immediately, especially if they ingest external models or datasets.

Risk score, explained

The score of 8.1 reflects: (1) Network accessibility (AV:N) — pickle files are routinely shared and downloaded remotely; (2) Low attack complexity (AC:L) — no special conditions or user knowledge required, just crafting a malicious pickle; (3) No privileges required (PR:N) — attacker needs only to influence pickle content; (4) User interaction required (UI:R) — the target must load the pickle, a standard action in ML workflows; (5) High confidentiality and integrity impact (C:H/I:H) — arbitrary code execution allows stealing data and modifying system state; (6) No availability impact (A:N) — the attack does not directly DoS the system, though it could cause application failures. The 8.1 rating appropriately captures serious exploitability with containable scope.

Frequently asked questions