picklescan CVE-2025-71374

Exploitation requires three concrete conditions: (1) the victim must use picklescan version < 0.0.29 as their safety gate for an attacker-supplied pickle or ML model file; (2) the malicious pickle must contain a __reduce__ method referencing the standard-library profile.Profile.run callable, which the vulnerable scanner does not detect; and (3) the victim must subsequently deserialize/load that file (pickle.load or equivalent model-load), the passive user interaction (UI:P) that triggers code execution. Limiting factors: code executes only on deserialization, not on scanning alone, and only organizations that rely on picklescan's verdict to approve untrusted pickles are meaningfully exposed - environments that already refuse untrusted pickles or use safetensors are largely unaffected. No special privileges are needed (PR:N), but the attack requirement (AT:P) means the attacker depends on the victim's specific scan-then-trust-then-load workflow.

Signals are mixed and should be weighed carefully. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:P, VC:H/VI:H/VA:N) yields 7.6 High: network-reachable, low complexity, no privileges, but it requires both a passive user interaction (the victim must scan and then load the file) and an attack requirement (AT:P) - the victim must actually rely on picklescan as their gate. There is no EPSS score provided, no CISA KEV listing, and no POC referenced, so this is not evidence of active or widespread exploitation; the realistic threat is targeted ML supply-chain poisoning rather than mass exploitation. The notable nuance is that this is a detection-bypass, not a primary RCE: pickle deserialization of untrusted data is already unsafe, so the practical impact lands only on organizations that trust picklescan's verdict as a safety boundary. For those teams the risk is meaningful because it produces a false sense of safety; for teams that never load untrusted pickles regardless, real-world risk is low. Note that the underlying RCE itself impacts availability as well, so the official VA:N may understate full system-compromise potential - verify against your deployment.

An attacker uploads a malicious pickled ML model containing a __reduce__ payload that calls profile.Profile().run('<attacker code>') to a model hub or shared artifact store. A victim, following secure practice, runs picklescan against the file, receives a 'no dangerous content' verdict, and loads the model with pickle.load(); the embedded code executes in the victim's process. No public POC is referenced, but the technique is straightforward given the pickle __reduce__ pattern and the named gadget.