CVE-2025-71367: picklescan <0.0.34 Detection Bypass—RCE via _operator.attrgetter

Technical summary

CVE-2025-71367 is a detection bypass in picklescan (versions <0.0.34) affecting its ability to identify unsafe callable objects in pickle streams. The vulnerability exploits picklescan's incomplete opcode and callable-name coverage: the tool does not detect _operator.attrgetter when used within pickle reduce operations. An attacker crafts a malicious pickle file where the reduce method specifies _operator.attrgetter as the callable, paired with arguments designed to access and invoke dangerous code paths. During pickle deserialization, Python's pickle module processes the reduce opcode, instantiates _operator.attrgetter with attacker-controlled arguments, and executes the resulting operation. Because picklescan's validation logic omits this specific function from its detection patterns, the file passes validation. The root cause is CWE-502 (Deserialization of Untrusted Data), compounded by incomplete whitelisting or blacklisting in the scanner's callable-detection logic.

Business impact

Organizations relying on picklescan as part of their Python application security posture face an unexpected vulnerability in their defensive layer. Any service that validates pickle data before loading it—to prevent remote code execution from untrusted sources—may unknowingly allow crafted payloads through. This is especially critical for: (1) applications deserializing pickles from user uploads, API endpoints, or message queues; (2) security teams using picklescan to audit third-party Python packages or artifacts; (3) MLOps and data science pipelines where pickled models or serialized data objects flow between systems. A breach could grant remote code execution in production environments with the privileges of the Python process, potentially leading to lateral movement, data exfiltration, or service disruption. The trust placed in picklescan's validation creates a false sense of security.

Affected systems

Any deployment using picklescan versions prior to 0.0.34 to validate or scan pickle files before deserialization is affected. This includes: applications that import picklescan and call its scanning functions; security tools or CI/CD pipelines that invoke picklescan as a command-line utility; development teams using picklescan during code review or artifact scanning. Systems not using picklescan, or those already updated to 0.0.34 or later, are not affected by this specific bypass. Note that the vulnerability does not affect pickle security in general—it affects the ability of picklescan to detect this particular attack vector. Standard pickle deserialization from untrusted sources remains unsafe regardless of picklescan version.

Exploitability

This vulnerability requires user interaction (UI:R in the CVSS vector): an attacker must trick a user or system into loading a malicious pickle file. However, exploitation is otherwise straightforward. No authentication is required (PR:N), the attack is network-accessible (AV:N), and no complex conditions must be met (AC:L). Crafting a pickle file with _operator.attrgetter in the reduce method is trivial for anyone with Python knowledge. The barrier to entry is low, and the impact is severe (arbitrary code execution with process privileges). The CVSS 8.1 (HIGH) score reflects the high impact but acknowledges that delivery of the malicious pickle requires social engineering or a compromised data source. In real-world scenarios, pickles are often downloaded, deserialized in automated pipelines, or accepted from seemingly trusted sources, making the

Remediation

Immediate action: update picklescan to version 0.0.34 or later, which closes the detection gap by recognizing _operator.attrgetter and other overlooked callables in reduce methods. Verify the update in your dependency management tool (pip, poetry, etc.) and re-run picklescan scans across your artifact inventory. Longer-term measures: (1) treat picklescan as a layer of defense, not a complete solution—do not rely on it as the sole gatekeeper for pickle deserialization; (2) whenever possible, replace pickle with safer serialization formats (JSON, Protocol Buffers, MessagePack) in new code; (3) deserialize pickle data only from fully trusted sources in controlled environments; (4) run pickle deserialization in isolated sandboxes or containers with minimal privileges; (5) implement network segmentation so that code execution in one tier cannot easily pivot to sensitive systems. For applications that cannot migrate away from pickle, update picklescan immediately and combine it with additional runtime controls (e.g., restrictive pickle.Unpickler configurations or custom Unpickler subclasses that constrain which modules and classes can be instantiated).

Patch guidance

Update picklescan to version 0.0.34 or later. Verify the upgrade with `pip show picklescan` or equivalent and confirm the version number. If you are using picklescan as a pinned dependency in a requirements.txt, pyproject.toml, or similar, change the version specifier to >=0.0.34 (or, after testing, to a specific newer version). Re-run picklescan against any stored pickle files or artifacts in your environment to catch payloads that may have passed the old, vulnerable scanner. If you are using picklescan in a CI/CD pipeline, ensure the updated version is pulled in your next build. There are no known breaking changes in 0.0.34, but review the changelog to confirm compatibility with your call patterns.

Detection guidance

Monitor for the use of _operator.attrgetter in pickle files or pickle-like byte streams. Network-based detection is difficult without decoding the pickle protocol, but you can inspect pickles at rest or in transit by: (1) decoding them with a tool that extracts opcode and callable names without full deserialization (e.g., pickletools.dis() in Python); (2) scanning logs for warnings from picklescan versions <0.0.34 that may have false-negatives; (3) auditing which applications deserialize pickles and verifying they are running picklescan 0.0.34+. Behavioral detection: watch for unexpected process spawning or system calls originating from Python processes that are known to deserialize pickle data. If you have not explicitly enabled picklescan or do not validate pickles before loading, assume all pickle deserialization from untrusted sources is a risk and implement immediate controls.

Why prioritize this

This vulnerability should be patched with high urgency. While the CVSS score is 8.1 (HIGH), not CRITICAL, the practical risk is elevated because: (1) picklescan is a security tool relied upon for assurance, so its failure undermines a key defensive control; (2) the bypass is trivial to exploit and requires no special tools or skills; (3) exploitation grants arbitrary code execution in the context of the running process; (4) the vulnerability directly affects the integrity of Python artifact supply chains and deserialization workflows. Organizations should treat this as a critical defect in their intake validation layer and patch within days, not weeks. If you use picklescan in production or continuous integration, this is a priority fix.

Risk score, explained

The CVSS 8.1 score reflects a HIGH-severity vulnerability with a high base risk: (C:H) confidentiality impact from arbitrary code execution; (I:H) integrity impact from the same; (A:N) no direct availability impact, though availability can be affected indirectly via DoS or service disruption. The attack vector is network-accessible (AV:N), requires low complexity (AC:L), no privileges (PR:N), and some user interaction (UI:R). The user interaction requirement (loading or validating a specific file) prevents a CRITICAL rating, but the combination of straightforward exploitation, severe impact, and the fact that picklescan is supposed to prevent exactly this type of attack justifies the 8.1 score. The real-world risk to any organization using picklescan may feel higher than the numeric score suggests, because the vulnerability undermines a trusted tool.

Frequently asked questions