CVE-2025-71368: picklescan RCE via doctest.debug_script Bypass

Technical summary

The vulnerability stems from incomplete function coverage in picklescan's detection engine. The doctest.debug_script function, part of Python's standard library, can be leveraged as a gadget chain to achieve arbitrary code execution during pickle deserialization. When a crafted pickle file containing doctest.debug_script is analyzed by picklescan versions before 0.0.30, the tool fails to identify it as a risky operation and permits the pickle to pass validation. Subsequent invocation of pickle.load on the file then triggers the embedded doctest.debug_script call, executing attacker-controlled commands. This is classified under CWE-502 (Deserialization of Untrusted Data), a well-known class of Python pickle vulnerabilities.

Business impact

Organizations that rely on picklescan as a gating mechanism for accepting or processing untrusted pickle files face a significant bypass risk. Applications that deserialize pickles from external sources (APIs, file uploads, caches, messaging systems) protected only by picklescan 0.0.29 or earlier can be compromised despite the presence of the scanning tool. The HIGH severity CVSS score reflects that network-accessible services could be exploited to achieve remote code execution with no authentication required and minimal user interaction (pickle must be deserialized). Data exfiltration, system compromise, and lateral movement become possible for any attacker who can influence pickle content.

Affected systems

Any Python application using picklescan versions before 0.0.30 to validate untrusted pickle input is affected. This includes web services that accept pickled data, microservices using pickle for inter-process communication, data pipeline tools that deserialize cached pickle objects, and any deployment where picklescan is deployed as a security boundary. The vulnerability does not affect applications that do not use picklescan or those that have already upgraded to 0.0.30 or later. Applications using pickle.loads or pickle.load without any validation tool are also vulnerable to this class of attack, though picklescan's purpose is to mitigate such risks.

Exploitability

Exploitation is straightforward from an attacker's perspective. No special privileges or authentication are required; only the ability to craft and deliver a malicious pickle file to a target application. The attack surface depends on the application design—if pickles come from user uploads, untrusted APIs, or any external source, the risk is immediate. Once a crafted pickle embedding doctest.debug_script reaches a vulnerable picklescan instance and is subsequently deserialized, arbitrary code execution occurs automatically. The CVSS vector AV:N/AC:L/PR:N/UI:R indicates network accessibility and low attack complexity, with only user interaction (deserialization) required as a gate. This combination makes the vulnerability practically exploitable in real-world scenarios.

Remediation

Upgrade picklescan to version 0.0.30 or later, which includes detection logic for doctest.debug_script and other previously undetected gadgets. After patching, re-scan any untrusted pickle files that may have been stored or cached while running vulnerable versions. For applications that cannot upgrade immediately, implement additional controls: avoid deserializing untrusted pickles altogether (prefer JSON or other safer formats), restrict pickle deserialization to authenticated internal sources only, run pickle deserialization in isolated, restricted environments (containers, sandboxes), and apply strict input validation and allowlisting of expected pickle objects where feasible.

Patch guidance

Verify the picklescan release notes and GitHub repository to confirm that version 0.0.30 addresses this specific vulnerability. Update your Python environment and any containerized or deployed applications to use picklescan 0.0.30 or the latest available release. This is a straightforward dependency upgrade for most Python projects (pip install --upgrade picklescan). Test the upgrade in a staging environment to ensure no regressions, then deploy to production. After patching, consider re-running picklescan against any historical pickle files processed while vulnerable versions were in use to detect any that may have been malicious and slipped through.

Detection guidance

Hunt for uses of picklescan in your codebase and verify installed versions against 0.0.30. Examine application logs and network traffic for indicators of pickle deserialization from untrusted sources. If you maintain a artifact repository, scan stored pickle files with the updated picklescan version to retrospectively identify any that may have embedded doctest.debug_script or other obfuscated gadgets. Monitor for unexpected subprocess spawning or command execution initiated from processes that deserialize pickle data. Review application code for any direct pickle.load or pickle.loads calls on untrusted input, even if picklescan is in place, as defense-in-depth is prudent.

Why prioritize this

This vulnerability should be treated as high-priority due to its HIGH CVSS score (8.1), the practical ease of exploitation, and the likelihood that picklescan is deployed in environments processing untrusted data. Because picklescan is a security tool, its bypass creates a false sense of protection and may delay incident detection. Organizations relying on it for compliance or security architecture must patch immediately. If your infrastructure ingests pickles from external sources or user-controlled input, this is a critical threat.

Risk score, explained

The CVSS 3.1 score of 8.1 (HIGH) reflects a network-accessible, unauthenticated attack vector (AV:N, PR:N) with low complexity (AC:L) that requires user interaction only in the form of deserialization (UI:R). The attack yields high confidentiality and integrity impact (C:H, I:H) but no availability impact (A:N), since the payload is arbitrary code execution rather than denial of service. The scope remains unchanged (S:U), meaning impact is limited to the vulnerable component. This score appropriately captures the severity: remote code execution is possible against any application accepting the malicious pickle without authentication, contingent only on the application deserializing it.

Frequently asked questions