CVE-2025-71358: picklescan Detection Bypass via Malicious Pickle Files (CVSS 8.1)

Technical summary

The vulnerability exists in picklescan's inspection logic, which fails to identify malicious reduce operations that invoke idlelib.autocomplete.AutoComplete.get_entity. The pickle protocol's reduce opcode allows arbitrary Python callables to be invoked during deserialization. picklescan's detection mechanism does not properly flag this specific gadget chain, permitting an attacker to embed code that executes with the privileges of the Python process unpickling the data. The flaw is rooted in incomplete gadget detection—picklescan maintains a list of dangerous functions, but the AutoComplete.get_entity method was either not included or not properly matched during inspection. When pickle.load() deserializes the crafted payload, the reduce operation reconstructs an object by calling the undetected gadget, leading to code execution.

Business impact

Organizations using picklescan to validate pickle files from untrusted sources face a direct security regression. Data pipelines, machine learning model loading systems, and any application accepting pickled objects from external parties operate under a false sense of security. A successful exploit grants attackers code execution in the context of the Python application, enabling data theft, lateral movement, malware deployment, or service disruption. The severity is amplified because picklescan is often part of a defense-in-depth strategy; its bypass eliminates a critical validation layer. Remediation requires both tool updates and potential re-evaluation of past pickle file ingestion.

Affected systems

Any system running picklescan version 0.0.28 or earlier is vulnerable. The impact extends to all applications or services that depend on picklescan for security validation of pickle files, including data science platforms, MLOps infrastructure, and data serialization services. Python environments that rely on picklescan as a gating mechanism before calling pickle.load() are at direct risk. Systems not yet upgraded cannot reliably distinguish safe from malicious pickle payloads.

Exploitability

This vulnerability is readily exploitable. Crafting a malicious pickle file requires only standard Python pickle tools and knowledge of the gadget chain; no special privileges or local access are needed. The attack is entirely remote—an attacker can deliver a crafted pickle file via email, file upload, API response, or any data channel. User interaction is minimal: the victim simply needs to load the pickle file using pickle.load() or a wrapper that calls it. Given that picklescan is marketed as a security tool, defenders may have lower suspicion of validated pickle files, increasing the likelihood of successful exploitation.

Remediation

Upgrade picklescan to version 0.0.29 or later immediately. This version includes detection updates that properly identify the malicious reduce chain. After patching, consider re-scanning any pickle files ingested while running vulnerable versions, as they may harbor undetected payloads. Organizations should also review their pickle handling practices: whenever possible, use safer serialization formats (JSON, Protocol Buffers, MessagePack) instead of pickle for untrusted data. If pickle is unavoidable, combine picklescan with other security controls such as sandboxing, strict file permissions, and runtime monitoring.

Patch guidance

The fix is available in picklescan version 0.0.29. Update via your package manager (pip install --upgrade picklescan>=0.0.29). Verify the installed version with picklescan --version or by checking pip show picklescan. Test the patched version in a non-production environment first to ensure compatibility with your pipeline. If you maintain a locked dependency tree, prioritize this update in your next release cycle. For air-gapped or offline environments, download the patched wheel from the official Python Package Index and deploy via your internal package repository.

Detection guidance

Check for picklescan usage across your codebase and infrastructure: grep -r "picklescan" in version control, container images, and requirements files. Identify pickle file sources and ingestion points—focus on those accepting external data. Log pickle.load() calls and monitor for successful executions following picklescan validation. If you have access to historical pickle files scanned by vulnerable versions, re-run them against picklescan 0.0.29+ to detect bypasses. Monitor for unusual process spawning or system calls originating from Python interpreters processing pickled data, as this may indicate exploitation. Check for any error logs or warnings in applications using picklescan; a sudden jump in detection failures post-update may indicate an attempted exploit.

Why prioritize this

This vulnerability merits immediate attention because it directly undermines a security control. Organizations have deployed picklescan precisely to prevent pickle deserialization attacks. A bypass of that control re-exposes a well-known attack surface (CWE-502: Deserialization of Untrusted Data) that many teams considered mitigated. The CVSS score of 8.1 reflects the high impact (code execution, information disclosure) combined with low attack complexity and no authentication requirements. The attack surface is broad—any application accepting pickle files from users, partners, or untrusted infrastructure is vulnerable.

Risk score, explained

The CVSS 3.1 score of 8.1 (HIGH) is justified by the following factors: Network accessibility (AV:N) and low attack complexity (AC:L) mean remote, unauthenticated exploitation is straightforward. No special privileges are required (PR:N), lowering the bar further. The impact is significant—confidentiality (C:H) and integrity (I:H) are fully compromised through code execution, though availability is not directly impacted (A:N). The requirement for user interaction (UI:R) to load the pickle file prevents a critical rating, but remains a practical exploit precondition rather than a meaningful defense. The single-user scope (S:U) limits cross-user privilege escalation but does not reduce the severity within a target's context.

Frequently asked questions