CVE-2025-71370: picklescan Detection Bypass & RCE Vulnerability

Technical summary

CVE-2025-71370 is a detection evasion vulnerability in picklescan prior to version 0.0.28. The flaw stems from incomplete signature detection logic that does not properly identify malicious invocations of torch.jit.unsupported_tensor_ops.execWrapper embedded within pickle serialized objects. Pickle is Python's native serialization format and inherently supports arbitrary code execution through various callable mechanisms during deserialization. picklescan attempts to prevent this by scanning pickle bytecode and rejecting files containing known-dangerous operations. However, the specific pattern of execWrapper function calls—likely leveraging PyTorch's JIT compiler internals—is not caught by the current detection heuristics. An attacker who can control or influence the pickle file supplied to an application using an unpatched version of picklescan can bypass the scanner and trigger remote code execution at the privilege level of the Python process.

Business impact

Organizations relying on picklescan to safely deserialize untrusted pickle files face a false sense of security. Any service that accepts pickle uploads, downloads from untrusted sources, or deserializes pickled data from user input or external APIs is now vulnerable to remote code execution despite having picklescan in place. This is particularly critical for data science and machine learning pipelines that frequently load serialized models and datasets in pickle format. A breach could lead to data exfiltration, model theft, lateral movement, or full system compromise. The reputational damage is compounded because picklescan's primary purpose is to provide this protection; its failure undermines trust in the supply chain security posture.

Affected systems

Any application or service using picklescan versions prior to 0.0.28 is affected. This includes development environments, CI/CD pipelines, data science platforms, machine learning infrastructure, and any Python application that deserializes pickle files from untrusted sources while relying on picklescan for protection. PyTorch-based projects are of particular concern given the nature of the evasion technique. The vulnerability does not require a specific operating system or Python version; it affects picklescan across all platforms.

Exploitability

Exploitation requires the attacker to craft a malicious pickle file and cause the target to deserialize it using pickle.load() on a system running vulnerable picklescan. The CVSS vector (AV:N/AC:L/PR:N/UI:R) indicates network accessibility with low complexity and user interaction required—meaning an attacker can deliver the payload remotely but needs the user to trigger deserialization (e.g., by uploading a file, clicking a link to load a model, or accepting data from an external source). The evasion is reliable because it exploits a specific gap in the detection logic rather than relying on obfuscation. No special privileges are needed to craft the payload, making this a practical attack vector for low-skilled attackers once the technique is public.

Remediation

Upgrade picklescan to version 0.0.28 or later. This patched version includes detection logic for the torch.jit.unsupported_tensor_ops.execWrapper pattern and closes the evasion bypass. No workarounds exist that preserve the intended security of picklescan; patching is mandatory. After patching, re-scan any pickle files that were processed by older versions if their origin is untrusted.

Patch guidance

1. Identify all systems and applications using picklescan. Check requirements.txt, Pipfile, pyproject.toml, or package manifests. 2. Update picklescan to version 0.0.28 or later using your package manager (pip install --upgrade picklescan or equivalent). 3. Test the upgraded version against your application's normal pickle deserialization workflow to ensure compatibility. 4. Restart or redeploy affected services to load the patched library. 5. For CI/CD pipelines, update lockfiles and container base images to include the patched version. 6. Consider implementing defense-in-depth measures: limit pickle deserialization to trusted sources, isolate deserialization in sandboxed processes, and prefer safer serialization formats (JSON, Protocol Buffers, MessagePack) where feasible.

Detection guidance

Monitor for unexpected pickle.load() or pickle.loads() calls in production code, especially those processing external input. Review logs for failed picklescan validations (if logging is enabled) and correlate with file uploads or data imports. Look for anomalous process behavior following pickle deserialization—unexpected child process spawning, network connections, or file system access. If running an older picklescan version, treat any pickle file of unknown provenance as high-risk. Threat hunters should search for pickle files with torch.jit.unsupported_tensor_ops.execWrapper patterns in historical data stores or backup systems.

Why prioritize this

This vulnerability scores HIGH (8.1 CVSS) due to the combination of high confidentiality and integrity impact, network accessibility, and low barrier to exploitation. However, it is not yet on the CISA KEV catalog, suggesting active exploitation may not yet be widespread—though once public, adoption of the attack will be rapid given the simplicity of the technique. Organizations should prioritize patching within 7–14 days, especially those handling untrusted pickle data or running data science platforms. The fact that picklescan is a security tool amplifies urgency: failures in detection logic erode downstream trust.

Risk score, explained

CVSS 3.1 score of 8.1 reflects HIGH severity. The vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N breaks down as: Network-accessible attack vector (AV:N) with low attack complexity (AC:L) requiring no privileges (PR:N) but user interaction (UI:R). Confidentiality and integrity are fully compromised (C:H, I:H), but availability is not directly impacted (A:N)—the attacker can exfiltrate or modify data, not crash the service. The user interaction requirement slightly reduces the score; had the attack been fully automated, it would be critical (9.0+). The severity reflects realistic impact: arbitrary code execution is the worst-case outcome in cybersecurity.

Frequently asked questions