Picklescan
Monthly
Malicious code execution via scanner bypass affects picklescan before 0.0.34, a security tool used to vet pickle files for unsafe deserialization before loading ML model artifacts. The scanner fails to flag the _operator.methodcaller built-in, so an attacker can craft a pickle that passes picklescan's malware check yet executes arbitrary code the moment a victim calls pickle.load(). No public exploit has been identified at time of analysis, and the flaw is not on CISA KEV; the fix landed in version 0.0.34.
Detection bypass in picklescan before 0.0.33 lets attackers slip malicious pickle files past its security scanner by using operator.methodcaller, a callable the scanner's blocklist did not recognize. Any ML pipeline, model hub, or workflow that trusts picklescan to vet untrusted pickle/model files is affected, because a crafted payload will be marked safe yet execute arbitrary code the moment the file is deserialized. No public exploit identified at time of analysis and the flaw is not in CISA KEV, but the bypass technique is straightforward and the issue is tagged RCE by the reporting source (VulnCheck).
Security-scanner bypass in Picklescan before 0.0.33 lets attackers smuggle arbitrary-code-execution payloads past its safety checks by abusing the numpy.f2py.crackfortran.getlincoef gadget inside a pickle __reduce__ method, which the scanner fails to flag as dangerous. Because Picklescan is used to vet shared machine-learning model files, a malicious pickle passes as 'clean' and then executes attacker-controlled Python when the trusting downstream consumer deserializes it. No public exploit is identified at time of analysis, and it is not listed in CISA KEV; the CVSS 4.0 score is 7.6 and the attack depends on a victim actually loading the file.
Safety-check bypass in picklescan before 0.0.28 allows attackers to smuggle malicious pickle files past the scanner by abusing torch.utils.data.datapipes.utils.decoder.basichandlers as a reduce gadget, so a payload the tool reports as clean still executes arbitrary code when the victim deserializes it. Because picklescan is a defensive scanner used to vet untrusted ML models (notably in Hugging Face workflows), this blind spot converts a trusted safety gate into a false sense of security. No public exploit identified at time of analysis, and it is not on CISA KEV; CVSS 4.0 base score is 7.6.
Security-scanner detection bypass in picklescan before 0.0.34 lets attackers slip malicious pickle files past its checks by invoking _operator.attrgetter inside a reduce method, so a file the scanner reports as clean still executes arbitrary code when pickle.load() deserializes it. The flaw affects ML/AI supply-chain pipelines that rely on picklescan to vet untrusted model files. No public exploit identified at time of analysis; the issue was reported by VulnCheck and fixed in 0.0.34.
Security-scanner evasion in picklescan before 0.0.28 lets attackers slip malicious pickle files past its safety checks by abusing the torch.utils.bottleneck.__main__.run_cprofile call, which the scanner's blocklist does not recognize as dangerous. Any ML pipeline or platform that relies on picklescan to vet untrusted models will therefore approve a weaponized file, and the embedded code runs with arbitrary execution when the victim deserializes it. No public exploit identified at time of analysis; not listed in CISA KEV, but VulnCheck published a dedicated advisory and the technique is fully documented.
Detection bypass in picklescan before 0.0.30 lets a crafted pickle smuggle the asyncio.unix_events._UnixSubprocessTransport._start built-in past the scanner's malicious-opcode checks, so a model or pickle that picklescan reports as safe actually executes arbitrary OS commands when a victim deserializes it. Because picklescan is a security scanner used to vet untrusted ML artifacts (e.g. in AI model supply chains), this false-negative turns a trusted safety gate into a blind spot. No public exploit identified at time of analysis and it is not on CISA KEV, but the technique is fully described in the VulnCheck advisory.
Malicious-pickle detection bypass in picklescan before 0.0.33 lets attackers smuggle arbitrary code past the scanner by abusing numpy.f2py.crackfortran functions that call eval() on attacker-controlled strings. Because picklescan is itself the security tool meant to vet untrusted pickle/model files, this evasion causes a weaponized pickle to be marked safe, so the embedded code executes when the file is later deserialized. Reported by VulnCheck with a CVSS 4.0 score of 7.6; no public exploit identified at time of analysis and it is not in CISA KEV.
Security-control bypass in picklescan before 0.0.29 lets attackers craft malicious pickle files that evade its malware scanner by hiding a reduce-method payload behind Python's idlelib.calltip.get_entity function, so a file the scanner reports as clean executes arbitrary commands when a victim deserializes it. Affected are ML/AI pipelines and users relying on picklescan to vet untrusted model artifacts. No public exploit or CISA KEV listing is identified at time of analysis, though the technique and a GitHub Security Advisory (GHSA-9xph-j2h6-g47v) are documented by VulnCheck.
Detection bypass in picklescan before 0.0.29 lets attackers slip malicious pickle payloads past the scanner by abusing lib2to3.pgen2.grammar.Grammar.loads inside a pickle reduce method, resulting in remote code execution when the file is later deserialized with pickle.load(). Because picklescan is trusted as a safety gate for machine-learning model files, a bypass converts a 'scanned and clean' verdict into silent arbitrary code execution. No public exploit has been identified at time of analysis and the flaw is not listed in CISA KEV, though the technique is concretely described in the VulnCheck advisory.
Security scanner bypass in picklescan before 0.0.28 allows attackers to smuggle arbitrary code past the tool's malware detection by abusing torch.fx.experimental.symbolic_shapes.ShapeEnv.evaluate_guards_expression, which is not on picklescan's dangerous-globals blocklist. Because picklescan is a defensive tool used to vet untrusted ML pickle files (notably in the Hugging Face ecosystem), a bypass causes a malicious model to be marked safe and then execute remote code when the victim deserializes it. There is no public exploit identified at time of analysis and this CVE is not listed in CISA KEV, but the technique is fully described in the VulnCheck advisory.
Detection bypass in picklescan before 0.0.28 lets attackers smuggle malicious pickle files past the scanner by abusing the torch._dynamo.guards.GuardBuilder.get gadget inside a __reduce__ method, so a file that picklescan reports as safe still executes arbitrary commands when deserialized (e.g. via torch.load). This undermines the security control that ML pipelines and model hubs rely on to vet untrusted model artifacts, turning a trusted-scan result into a false negative. Reported by VulnCheck with a vendor GHSA advisory; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Security-scanner evasion in picklescan before 0.0.33 lets attackers smuggle malicious pickle files past its detection engine by abusing the numpy.f2py.crackfortran.param_eval function inside a pickle reduce method, so a payload the scanner declares safe still triggers arbitrary code execution when the application deserializes it. This defeats the exact protection picklescan exists to provide, endangering ML pipelines that rely on it to vet untrusted model/pickle files (e.g., Hugging Face-style workflows). No public exploit is identified at time of analysis and it is not in CISA KEV, though VulnCheck published an advisory.
Malicious-pickle detection bypass in picklescan before 0.0.30 allows attackers to smuggle undetected remote code execution payloads past the scanner by abusing the torch.utils.bottleneck.__main__.run_autograd_prof gadget, which was absent from picklescan's dangerous-import blocklist. Because picklescan is used as a security gate to vet untrusted ML model files, a false-negative here means a crafted model passes as safe and executes arbitrary code when subsequently deserialized. Reported by VulnCheck via GHSA-4whj-rm5r-c2v8; no public exploit identified at time of analysis, and it is not on CISA KEV.
Detection bypass in picklescan before 0.0.30 lets attackers smuggle malicious pickle files past the scanner by abusing lib2to3.pgen2.pgen.ParserGenerator.make_label as a reduce callable, so a file that picklescan clears still runs arbitrary commands when downstream code calls pickle.load(). picklescan is the security control itself - a static scanner used to vet ML model artifacts - so this weakness undermines the exact protection teams rely on to catch unsafe pickles. No public exploit identified at time of analysis and it is not on CISA KEV, but the technique is documented in VulnCheck and vendor advisories.
Malicious pickle detection bypass in picklescan before 0.0.30 lets attackers hide code that runs during pickle.load, because the scanner does not flag the idlelib.run.Executive.runcode primitive used in a reduce method. Since picklescan is a security tool relied upon to vet PyTorch/ML model files, this bypass turns a trusted safety check into a false 'clean' verdict, enabling remote code execution and supply-chain attacks against anyone loading an attacker-supplied model. Reported by VulnCheck; no public exploit identified at time of analysis and not listed in CISA KEV.
Arbitrary code execution bypass in picklescan before 0.0.29 lets attackers smuggle malicious Python pickle files past the scanner by abusing the built-in profile.Profile.run function inside a pickle __reduce__ method, which picklescan's blocklist fails to flag. Because picklescan is a defensive ML supply-chain tool meant to certify pickle/model files as safe, the flaw is a security-control evasion: a file marked 'clean' executes attacker code on deserialization. No public exploit is identified at time of analysis, and it is not in CISA KEV; the CVSS 4.0 base score is 7.6 (High).
Malicious-pickle detection bypass in picklescan before 0.0.29 lets attackers smuggle weaponized pickle files past the scanner by abusing `code.InteractiveInterpreter.runcode` inside a `__reduce__` method, leading to arbitrary code execution when the file is later deserialized with `pickle.load()`. picklescan is a security scanner specifically meant to flag dangerous pickles (e.g. in ML model files), so a gap in its blocklist directly defeats the control users rely on. Reported by VulnCheck with an assigned CVSS 4.0 score of 7.6; no public exploit and no CISA KEV listing identified at time of analysis.
Detection bypass leading to arbitrary code execution in picklescan before 0.0.30 allows attackers to smuggle malicious payloads past the scanner by abusing the doctest.debug_script function, which picklescan's analyzer does not recognize as dangerous. Because picklescan is used to vet untrusted pickle/ML model files before loading, a crafted pickle marked 'safe' will execute attacker commands the moment pickle.load is invoked. There is no public exploit identified at time of analysis, and this is not listed in CISA KEV, but the technique is well-understood and was disclosed by VulnCheck.
Scanner-detection bypass in picklescan before 0.0.30 lets a crafted pickle file evade malicious-code detection and execute arbitrary code on deserialization. The tool - a Python security scanner used to vet untrusted pickle/ML model files - fails to flag `cProfile.run` calls embedded in a pickle object's `__reduce__` method, so a payload routed through `cProfile.run` passes the scan and then runs when the file is loaded. Reported by VulnCheck (CWE-502); no public exploit identified at time of analysis and it is not in CISA KEV.
Static-analysis bypass in Picklescan before 0.0.25 lets attackers smuggle malicious pickle files past its malware scanner, leading to arbitrary OS command execution when a victim deserializes the file. Picklescan's denylist fails to flag unsafe Numpy globals, so a reduce method invoking numpy.testing._private.utils.runstring can import os and run commands while being reported as safe. No public exploit has been identified at time of analysis, though VulnCheck's advisory documents the exact gadget; the issue is not in CISA KEV. CVSS 4.0 base score is 7.6.
Detection bypass in picklescan before 0.0.29 allows attackers to smuggle arbitrary-code payloads past the scanner by abusing Python's built-in trace.Trace.runctx in a pickle reduce method, so a malicious model/pickle file is rated safe yet executes code when later deserialized with pickle.load(). picklescan is a security scanner used to vet untrusted ML pickle files (notably in the Hugging Face ecosystem), so this failure defeats the very control teams rely on to catch malicious models. No public exploit identified at time of analysis and the issue is not in CISA KEV; reported by VulnCheck with a CVSS 4.0 base score of 7.6.
Malicious-pickle detection bypass in picklescan before 0.0.28 lets attackers smuggle remote-code-execution payloads past the scanner by hiding them in a pickle reduce method that invokes torch.utils.collect_env.run, which picklescan's blocklist failed to flag. Because picklescan is the gatekeeper many ML pipelines rely on to vet untrusted models (notably scanning Hugging Face artifacts), a 'clean' verdict on a weaponized file directly leads to command execution when the victim deserializes it. Reported by VulnCheck with a fix in 0.0.28; no public exploit identified at time of analysis and not listed in CISA KEV.
Malicious pickle detection bypass in picklescan before 0.0.29 lets attackers smuggle arbitrary code execution payloads past the scanner by abusing the built-in trace.Trace.run function inside a pickle's __reduce__ method. Because picklescan does not flag trace.Trace.run as a dangerous global, a crafted model/pickle file is reported as safe yet executes arbitrary code when later deserialized via pickle.load. No public exploit identified at time of analysis; this is a classic deny-list gap in a security scanner that defenders rely on to gate untrusted ML artifacts.
Detection bypass in picklescan through version 0.0.26 lets attackers smuggle malicious pickle payloads past the scanner by invoking idlelib.pyshell.ModifiedInterpreter.runcode from a __reduce__ method, which picklescan does not blocklist. Because organizations rely on picklescan to vet PyTorch models and serialized Python objects, a payload it marks 'safe' still achieves arbitrary command execution the moment the victim calls pickle.load(), enabling ML supply-chain attacks. Publicly available exploit code exists (GHSA-3gf5-cxq9-w223 ships a working PoC); the CVE is not in CISA KEV and EPSS data was not provided, so active exploitation is unconfirmed.
Detection bypass in picklescan before 0.0.29 allows malicious pickle files to evade scanning by abusing the undetected idlelib.calltip.Calltip.fetch_tip function, enabling arbitrary code execution when the file is later loaded via pickle.load(). Affects ML supply chains relying on picklescan to vet PyTorch models; publicly available exploit code exists in the GHSA advisory, but no public exploit identified in active campaigns at time of analysis.
Detection bypass in picklescan before 0.0.29 allows attackers to craft malicious pickle files using idlelib.debugobj.ObjectTreeItem.SetText in __reduce__ methods that evade the scanner's dangerous-function checks, resulting in arbitrary command execution when the victim subsequently calls pickle.load(). The flaw turns picklescan from a security control into a false-assurance tool for ML pipelines that consume untrusted PyTorch models. Publicly available exploit code exists via the GHSA advisory, though no public exploit identified in active campaigns at time of analysis.
Remote code execution in picklescan versions prior to 1.0.4 allows attackers to bypass the scanner's safety validation by crafting malicious pickle files that import unblocked Python standard library modules. The tool's blocklist (scanner.py _unsafe_globals) omits at least seven stdlib modules - including uuid, _osx_support, _aix_support, _pyrepl.pager, and imaplib - exposing eight functions that execute arbitrary commands via subprocess or os.system. Publicly available exploit code exists in the GHSA advisory, demonstrating CLEAN scan results for files that achieve full RCE on load; this is especially concerning because picklescan is relied on by HuggingFace Hub and similar ML pipelines.
Detection bypass in picklescan versions prior to 0.0.29 allows attackers to smuggle arbitrary code execution payloads through malicious pickle files by leveraging idlelib.autocomplete.AutoComplete.fetch_completions inside the __reduce__ method. Because the scanner does not flag this built-in Python function as dangerous, victims who rely on picklescan to vet PyTorch models or other pickle artifacts will load attacker-controlled code under pickle.load(). Publicly available exploit code exists (in the GHSA advisory), though no active in-the-wild exploitation has been reported.
Detection bypass in picklescan before 0.0.28 allows attackers to embed malicious torch.jit.unsupported_tensor_ops.execWrapper calls in pickle files that evade the scanner and execute arbitrary code when later loaded via pickle.load(). Publicly available exploit code exists in the GHSA advisory, and the flaw directly undermines the security guarantee picklescan is meant to provide for PyTorch model files. No CISA KEV listing and no EPSS data are provided, but the scanner bypass nature makes this a meaningful supply-chain risk for ML pipelines.
Detection bypass in picklescan before 0.0.33 allows attackers to smuggle arbitrary code through malicious pickle files by abusing numpy.f2py.crackfortran.myeval in a __reduce__ method, which the scanner fails to flag as dangerous. Any ML pipeline or model-hosting workflow that trusts picklescan's verdict before calling pickle.load() will execute attacker-controlled commands; publicly available exploit code exists in the GHSA advisory, and the CVSS 4.0 score of 7.6 reflects high confidentiality and integrity impact contingent on user interaction.
Detection bypass in picklescan prior to 0.0.29 allows attackers to smuggle remote code execution payloads through pickle files that the scanner incorrectly classifies as safe. The library fails to flag the built-in profile.Profile.runctx function when used in a __reduce__ method, so a downstream pickle.load() of the scanned file executes arbitrary Python. Publicly available exploit code exists in the GHSA-6vqj-c2q5-j97w advisory, though no active exploitation has been reported.
Detection bypass in picklescan before 0.0.29 allows attackers to smuggle arbitrary code execution payloads through pickle files by abusing the idlelib.autocomplete.AutoComplete.get_entity function inside __reduce__ methods. Because picklescan does not flag this function as dangerous, malicious ML model files (e.g., PyTorch checkpoints) appear safe to scan but execute attacker commands the moment a victim calls pickle.load(). Publicly available exploit code exists in the GHSA advisory, but no public exploit identified at time of analysis in CISA KEV.
Detection bypass in picklescan versions 0.0.26 and earlier (fixed in 0.0.30) allows attackers to smuggle arbitrary code through malicious pickle files by abusing Python's built-in ensurepip._run_pip function, which the scanner failed to flag as dangerous. Organizations relying on picklescan to vet PyTorch models or other serialized Python objects will load the file as safe and trigger remote code execution upon pickle.load(). Publicly available exploit code exists via the GHSA advisory PoC, though no public exploit identified in active campaigns at time of analysis.
Arbitrary code execution in Picklescan before 0.0.33 occurs because the scanner fails to flag the numpy.f2py.crackfortran._eval_length gadget when used inside a pickle __reduce__ method, allowing crafted pickle files to be marked safe while still executing attacker-supplied Python on load. Workflows that rely on Picklescan to vet untrusted pickle or PyTorch model artifacts are exposed to supply-chain poisoning, and publicly available exploit code exists in the GHSA advisory.
Detection bypass in picklescan versions before 0.0.30 allows malicious pickle files to evade security scanning by using cProfile.runctx in __reduce__ methods, leading to arbitrary code execution when the file is loaded via pickle.load(). The flaw undermines the core purpose of picklescan as a defensive tool for ML model security and was reported by VulnCheck with a published proof-of-concept in the GitHub Security Advisory. No public exploit identified at time of analysis as a weaponized in-the-wild attack, but PoC code is published in the GHSA.
Detection bypass in picklescan before 0.0.30 allows attackers to smuggle arbitrary code execution payloads through pickle files by abusing idlelib.pyshell.ModifiedInterpreter.runcommand inside a __reduce__ method, which the scanner fails to flag as dangerous. Any victim who relies on picklescan to vet PyTorch models or other pickle artifacts and then calls pickle.load() will execute attacker-supplied commands. Publicly available exploit code exists (PoC published in the GHSA advisory), no CISA KEV listing, and the issue is fixed in version 0.0.30.
Detection bypass in picklescan versions before 0.0.25 allows attackers to embed remote code execution payloads in pickle files by abusing the built-in timeit.timeit() function inside a __reduce__ method, which is not on the unsafe-globals blacklist. Any organization using picklescan to vet PyTorch or other pickle-based model files is affected, and a working PoC is publicly documented in the GHSA advisory (no public exploit identified at time of analysis as a weaponized tool, but POC code is published).
Detection bypass in picklescan before 0.0.28 allows attackers to smuggle arbitrary code through pickle files by abusing torch.utils._config_module.load_config inside __reduce__ methods, defeating the library's malicious-pickle scanning and enabling remote code execution when the file is later loaded. Publicly available exploit code exists (GHSA-vv6j-3g6g-2pvj includes a working PoC), and the flaw is significant for any ML pipeline that trusts picklescan to vet third-party PyTorch model files. No CISA KEV listing at time of analysis, so exploitation status is limited to public POC rather than confirmed in-the-wild use.
Unsafe pickle deserialization in picklescan before 1.0.1 allows unauthenticated remote attackers to create arbitrary zero-byte files on the server by crafting malicious pickle payloads that instantiate Python's standard-library logging.FileHandler class. This technique bypasses RCE-focused blocklists because it abuses legitimate standard library functionality rather than commonly blocked modules, making it a notable blocklist-evasion primitive. A publicly available proof-of-concept exploit exists; no public exploit identified at time of analysis for active KEV-confirmed exploitation, but the PoC demonstrates concrete filesystem impact including lock-file-based denial of service.
Scanner evasion in picklescan versions prior to 1.0.3 lets an attacker smuggle malicious PyTorch pickle payloads past the scan_pytorch detection routine and gain arbitrary code execution when the model is later loaded with torch.load(). The bypass exploits a parser-differential between picklescan's pickletools.genops()-based magic-number extraction and PyTorch's pickle_module.load(), allowing a __reduce__(eval, ('MAGIC_NUMBER',)) trick to produce files that scan as clean but still deserialize correctly. A detailed proof-of-concept is published in the GHSA advisory and the VulnCheck writeup; no CISA KEV listing or EPSS score was supplied in the input.
Arbitrary code execution in picklescan versions prior to 1.0.1 allows attackers to bypass the scanner's malicious pickle detection by obfuscating eval calls nested under callable objects via getattr, causing the very tool intended to detect malicious pickles to miss them. Publicly available exploit code exists via the GHSA advisory PoC, though no public exploit identified at time of analysis as actively used in attacks; the CVSS 4.0 score of 9.3 reflects unauthenticated network-reachable impact on confidentiality, integrity, and availability.
Arbitrary code execution bypass in picklescan before 1.0.4 allows attackers to smuggle malicious pickle files past the scanner by invoking the module-level profile.run() function, which is missing from the blocklist that only covers Profile.run and Profile.runctx. The scanner reports zero issues while pickle.loads() triggers exec() of attacker-controlled Python. No public exploit identified at time of analysis beyond the proof-of-concept in the GHSA advisory, and the issue is not listed in CISA KEV.
Arbitrary file read in picklescan versions before 0.0.35 allows remote unauthenticated attackers to exfiltrate sensitive server files by abusing standard-library callables that the tool's RCE-focused blocklist fails to detect. By chaining io.FileIO and urllib.request.urlopen inside a malicious pickle, an attacker can stream contents of files such as /etc/passwd to an attacker-controlled URL when the scanner processes untrusted model artifacts. Publicly available exploit code exists in the GHSA advisory, but there is no public exploit identified at time of analysis in the form of in-the-wild abuse.
Remote code execution against users of picklescan versions prior to 1.0.4 is achievable by smuggling any blocked function past its scanner using pkgutil.resolve_name as an indirection primitive. Because pkgutil.resolve_name is not on the blocklist, an attacker can chain two REDUCE opcodes to resolve and invoke os.system, builtins.exec, subprocess.call, or any other dangerous function while the scanner reports the pickle as CLEAN - a universal blocklist bypass that defeats picklescan's entire safety premise. No public exploit is identified in CISA KEV, but the GHSA advisory authored by VulnCheck publishes a complete working technique, so weaponization is trivial.
Detection bypass in picklescan versions prior to 0.0.27 allows attackers to smuggle malicious Python pickle files past the scanner by exploiting an off-by-one parsing error in STACK_GLOBAL opcode handling. The flaw, reported by VulnCheck and tracked under GHSA-9gvj-pp9x-gcfr, lets crafted pickles trigger an unexpected exception in _list_globals so dangerous imports such as os.system go unflagged; a working PoC is published in the advisory and a vendor patch is available, though no public exploitation against deployments has been observed.
Remote code execution in picklescan before 0.0.33 enables attackers to bypass the tool's malicious-pickle detection by smuggling the unblocked ctypes module into a pickle payload. A working POC demonstrates loading kernel32.dll via ctypes.WinDLL and invoking WinExec to launch arbitrary commands during pickle deserialization scans or downstream loads. Publicly available exploit code exists in the GHSA-4675-36f9-wf6r advisory, and the flaw undermines the very security guarantee picklescan is deployed to provide for ML model pipelines.
Security check bypass in PickleScan versions before 0.0.33 allows attackers to smuggle arbitrary code execution payloads past the scanner by invoking the pty.spawn function, which was omitted from the unsafe globals deny-list. Publicly available exploit code exists (released as part of the HeroCTF 2025 'Irreductible 2' challenge writeup), and the flaw is particularly impactful for platforms like Hugging Face and other ML pipelines that rely on PickleScan to vet PyTorch model files. No public exploit identified at time of analysis in CISA KEV.
Arbitrary file write in picklescan before 0.0.33 lets attackers bypass the tool's dangerous-call blocklist by abusing distutils.file_util.write_file inside crafted pickle payloads. Because picklescan is used as a safety gate before loading ML model pickles, a bypass means malicious models pass scanning and can overwrite files on disk to achieve denial of service or remote code execution. Publicly available exploit code exists in the GHSA advisory, though there is no public exploit identified at time of analysis indicating active exploitation.
Arbitrary code execution in picklescan before 0.0.33 allows remote attackers to bypass the scanner's malicious-pickle detection by using pydoc.locate and operator.methodcaller, which were missing from the deny-list. Any downstream tool that trusts a 'clean' picklescan verdict and then deserializes the pickle (e.g., ML model loaders) will execute attacker-supplied code. Publicly available exploit code exists (GHSA PoC), and CVSS 4.0 is rated 9.3 Critical, though no public exploit identified at time of analysis in CISA KEV.
A Protection Mechanism Failure vulnerability in mmaitre314 picklescan versions up to and including 0.0.30 allows a remote attacker to bypass the unsafe globals check. Rated critical severity (CVSS 9.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
An Improper Handling of Exceptional Conditions vulnerability in the ZIP archive scanning component of mmaitre314 picklescan allows a remote attacker to bypass security scans. Rated critical severity (CVSS 9.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
An Improper Input Validation vulnerability in the scanning logic of mmaitre314 picklescan versions up to and including 0.0.30 allows a remote attacker to bypass pickle files security checks by. Rated critical severity (CVSS 9.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
The unsafe globals in Picklescan before 0.0.25 do not include ssl. Rated medium severity (CVSS 6.8), this vulnerability is no authentication required, low attack complexity. Public exploit code available.
picklescan before 0.0.22 only considers standard pickle file extensions in the scope for its vulnerability scan. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
picklescan before 0.0.21 does not treat 'pip' as an unsafe global. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Malicious code execution via scanner bypass affects picklescan before 0.0.34, a security tool used to vet pickle files for unsafe deserialization before loading ML model artifacts. The scanner fails to flag the _operator.methodcaller built-in, so an attacker can craft a pickle that passes picklescan's malware check yet executes arbitrary code the moment a victim calls pickle.load(). No public exploit has been identified at time of analysis, and the flaw is not on CISA KEV; the fix landed in version 0.0.34.
Detection bypass in picklescan before 0.0.33 lets attackers slip malicious pickle files past its security scanner by using operator.methodcaller, a callable the scanner's blocklist did not recognize. Any ML pipeline, model hub, or workflow that trusts picklescan to vet untrusted pickle/model files is affected, because a crafted payload will be marked safe yet execute arbitrary code the moment the file is deserialized. No public exploit identified at time of analysis and the flaw is not in CISA KEV, but the bypass technique is straightforward and the issue is tagged RCE by the reporting source (VulnCheck).
Security-scanner bypass in Picklescan before 0.0.33 lets attackers smuggle arbitrary-code-execution payloads past its safety checks by abusing the numpy.f2py.crackfortran.getlincoef gadget inside a pickle __reduce__ method, which the scanner fails to flag as dangerous. Because Picklescan is used to vet shared machine-learning model files, a malicious pickle passes as 'clean' and then executes attacker-controlled Python when the trusting downstream consumer deserializes it. No public exploit is identified at time of analysis, and it is not listed in CISA KEV; the CVSS 4.0 score is 7.6 and the attack depends on a victim actually loading the file.
Safety-check bypass in picklescan before 0.0.28 allows attackers to smuggle malicious pickle files past the scanner by abusing torch.utils.data.datapipes.utils.decoder.basichandlers as a reduce gadget, so a payload the tool reports as clean still executes arbitrary code when the victim deserializes it. Because picklescan is a defensive scanner used to vet untrusted ML models (notably in Hugging Face workflows), this blind spot converts a trusted safety gate into a false sense of security. No public exploit identified at time of analysis, and it is not on CISA KEV; CVSS 4.0 base score is 7.6.
Security-scanner detection bypass in picklescan before 0.0.34 lets attackers slip malicious pickle files past its checks by invoking _operator.attrgetter inside a reduce method, so a file the scanner reports as clean still executes arbitrary code when pickle.load() deserializes it. The flaw affects ML/AI supply-chain pipelines that rely on picklescan to vet untrusted model files. No public exploit identified at time of analysis; the issue was reported by VulnCheck and fixed in 0.0.34.
Security-scanner evasion in picklescan before 0.0.28 lets attackers slip malicious pickle files past its safety checks by abusing the torch.utils.bottleneck.__main__.run_cprofile call, which the scanner's blocklist does not recognize as dangerous. Any ML pipeline or platform that relies on picklescan to vet untrusted models will therefore approve a weaponized file, and the embedded code runs with arbitrary execution when the victim deserializes it. No public exploit identified at time of analysis; not listed in CISA KEV, but VulnCheck published a dedicated advisory and the technique is fully documented.
Detection bypass in picklescan before 0.0.30 lets a crafted pickle smuggle the asyncio.unix_events._UnixSubprocessTransport._start built-in past the scanner's malicious-opcode checks, so a model or pickle that picklescan reports as safe actually executes arbitrary OS commands when a victim deserializes it. Because picklescan is a security scanner used to vet untrusted ML artifacts (e.g. in AI model supply chains), this false-negative turns a trusted safety gate into a blind spot. No public exploit identified at time of analysis and it is not on CISA KEV, but the technique is fully described in the VulnCheck advisory.
Malicious-pickle detection bypass in picklescan before 0.0.33 lets attackers smuggle arbitrary code past the scanner by abusing numpy.f2py.crackfortran functions that call eval() on attacker-controlled strings. Because picklescan is itself the security tool meant to vet untrusted pickle/model files, this evasion causes a weaponized pickle to be marked safe, so the embedded code executes when the file is later deserialized. Reported by VulnCheck with a CVSS 4.0 score of 7.6; no public exploit identified at time of analysis and it is not in CISA KEV.
Security-control bypass in picklescan before 0.0.29 lets attackers craft malicious pickle files that evade its malware scanner by hiding a reduce-method payload behind Python's idlelib.calltip.get_entity function, so a file the scanner reports as clean executes arbitrary commands when a victim deserializes it. Affected are ML/AI pipelines and users relying on picklescan to vet untrusted model artifacts. No public exploit or CISA KEV listing is identified at time of analysis, though the technique and a GitHub Security Advisory (GHSA-9xph-j2h6-g47v) are documented by VulnCheck.
Detection bypass in picklescan before 0.0.29 lets attackers slip malicious pickle payloads past the scanner by abusing lib2to3.pgen2.grammar.Grammar.loads inside a pickle reduce method, resulting in remote code execution when the file is later deserialized with pickle.load(). Because picklescan is trusted as a safety gate for machine-learning model files, a bypass converts a 'scanned and clean' verdict into silent arbitrary code execution. No public exploit has been identified at time of analysis and the flaw is not listed in CISA KEV, though the technique is concretely described in the VulnCheck advisory.
Security scanner bypass in picklescan before 0.0.28 allows attackers to smuggle arbitrary code past the tool's malware detection by abusing torch.fx.experimental.symbolic_shapes.ShapeEnv.evaluate_guards_expression, which is not on picklescan's dangerous-globals blocklist. Because picklescan is a defensive tool used to vet untrusted ML pickle files (notably in the Hugging Face ecosystem), a bypass causes a malicious model to be marked safe and then execute remote code when the victim deserializes it. There is no public exploit identified at time of analysis and this CVE is not listed in CISA KEV, but the technique is fully described in the VulnCheck advisory.
Detection bypass in picklescan before 0.0.28 lets attackers smuggle malicious pickle files past the scanner by abusing the torch._dynamo.guards.GuardBuilder.get gadget inside a __reduce__ method, so a file that picklescan reports as safe still executes arbitrary commands when deserialized (e.g. via torch.load). This undermines the security control that ML pipelines and model hubs rely on to vet untrusted model artifacts, turning a trusted-scan result into a false negative. Reported by VulnCheck with a vendor GHSA advisory; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Security-scanner evasion in picklescan before 0.0.33 lets attackers smuggle malicious pickle files past its detection engine by abusing the numpy.f2py.crackfortran.param_eval function inside a pickle reduce method, so a payload the scanner declares safe still triggers arbitrary code execution when the application deserializes it. This defeats the exact protection picklescan exists to provide, endangering ML pipelines that rely on it to vet untrusted model/pickle files (e.g., Hugging Face-style workflows). No public exploit is identified at time of analysis and it is not in CISA KEV, though VulnCheck published an advisory.
Malicious-pickle detection bypass in picklescan before 0.0.30 allows attackers to smuggle undetected remote code execution payloads past the scanner by abusing the torch.utils.bottleneck.__main__.run_autograd_prof gadget, which was absent from picklescan's dangerous-import blocklist. Because picklescan is used as a security gate to vet untrusted ML model files, a false-negative here means a crafted model passes as safe and executes arbitrary code when subsequently deserialized. Reported by VulnCheck via GHSA-4whj-rm5r-c2v8; no public exploit identified at time of analysis, and it is not on CISA KEV.
Detection bypass in picklescan before 0.0.30 lets attackers smuggle malicious pickle files past the scanner by abusing lib2to3.pgen2.pgen.ParserGenerator.make_label as a reduce callable, so a file that picklescan clears still runs arbitrary commands when downstream code calls pickle.load(). picklescan is the security control itself - a static scanner used to vet ML model artifacts - so this weakness undermines the exact protection teams rely on to catch unsafe pickles. No public exploit identified at time of analysis and it is not on CISA KEV, but the technique is documented in VulnCheck and vendor advisories.
Malicious pickle detection bypass in picklescan before 0.0.30 lets attackers hide code that runs during pickle.load, because the scanner does not flag the idlelib.run.Executive.runcode primitive used in a reduce method. Since picklescan is a security tool relied upon to vet PyTorch/ML model files, this bypass turns a trusted safety check into a false 'clean' verdict, enabling remote code execution and supply-chain attacks against anyone loading an attacker-supplied model. Reported by VulnCheck; no public exploit identified at time of analysis and not listed in CISA KEV.
Arbitrary code execution bypass in picklescan before 0.0.29 lets attackers smuggle malicious Python pickle files past the scanner by abusing the built-in profile.Profile.run function inside a pickle __reduce__ method, which picklescan's blocklist fails to flag. Because picklescan is a defensive ML supply-chain tool meant to certify pickle/model files as safe, the flaw is a security-control evasion: a file marked 'clean' executes attacker code on deserialization. No public exploit is identified at time of analysis, and it is not in CISA KEV; the CVSS 4.0 base score is 7.6 (High).
Malicious-pickle detection bypass in picklescan before 0.0.29 lets attackers smuggle weaponized pickle files past the scanner by abusing `code.InteractiveInterpreter.runcode` inside a `__reduce__` method, leading to arbitrary code execution when the file is later deserialized with `pickle.load()`. picklescan is a security scanner specifically meant to flag dangerous pickles (e.g. in ML model files), so a gap in its blocklist directly defeats the control users rely on. Reported by VulnCheck with an assigned CVSS 4.0 score of 7.6; no public exploit and no CISA KEV listing identified at time of analysis.
Detection bypass leading to arbitrary code execution in picklescan before 0.0.30 allows attackers to smuggle malicious payloads past the scanner by abusing the doctest.debug_script function, which picklescan's analyzer does not recognize as dangerous. Because picklescan is used to vet untrusted pickle/ML model files before loading, a crafted pickle marked 'safe' will execute attacker commands the moment pickle.load is invoked. There is no public exploit identified at time of analysis, and this is not listed in CISA KEV, but the technique is well-understood and was disclosed by VulnCheck.
Scanner-detection bypass in picklescan before 0.0.30 lets a crafted pickle file evade malicious-code detection and execute arbitrary code on deserialization. The tool - a Python security scanner used to vet untrusted pickle/ML model files - fails to flag `cProfile.run` calls embedded in a pickle object's `__reduce__` method, so a payload routed through `cProfile.run` passes the scan and then runs when the file is loaded. Reported by VulnCheck (CWE-502); no public exploit identified at time of analysis and it is not in CISA KEV.
Static-analysis bypass in Picklescan before 0.0.25 lets attackers smuggle malicious pickle files past its malware scanner, leading to arbitrary OS command execution when a victim deserializes the file. Picklescan's denylist fails to flag unsafe Numpy globals, so a reduce method invoking numpy.testing._private.utils.runstring can import os and run commands while being reported as safe. No public exploit has been identified at time of analysis, though VulnCheck's advisory documents the exact gadget; the issue is not in CISA KEV. CVSS 4.0 base score is 7.6.
Detection bypass in picklescan before 0.0.29 allows attackers to smuggle arbitrary-code payloads past the scanner by abusing Python's built-in trace.Trace.runctx in a pickle reduce method, so a malicious model/pickle file is rated safe yet executes code when later deserialized with pickle.load(). picklescan is a security scanner used to vet untrusted ML pickle files (notably in the Hugging Face ecosystem), so this failure defeats the very control teams rely on to catch malicious models. No public exploit identified at time of analysis and the issue is not in CISA KEV; reported by VulnCheck with a CVSS 4.0 base score of 7.6.
Malicious-pickle detection bypass in picklescan before 0.0.28 lets attackers smuggle remote-code-execution payloads past the scanner by hiding them in a pickle reduce method that invokes torch.utils.collect_env.run, which picklescan's blocklist failed to flag. Because picklescan is the gatekeeper many ML pipelines rely on to vet untrusted models (notably scanning Hugging Face artifacts), a 'clean' verdict on a weaponized file directly leads to command execution when the victim deserializes it. Reported by VulnCheck with a fix in 0.0.28; no public exploit identified at time of analysis and not listed in CISA KEV.
Malicious pickle detection bypass in picklescan before 0.0.29 lets attackers smuggle arbitrary code execution payloads past the scanner by abusing the built-in trace.Trace.run function inside a pickle's __reduce__ method. Because picklescan does not flag trace.Trace.run as a dangerous global, a crafted model/pickle file is reported as safe yet executes arbitrary code when later deserialized via pickle.load. No public exploit identified at time of analysis; this is a classic deny-list gap in a security scanner that defenders rely on to gate untrusted ML artifacts.
Detection bypass in picklescan through version 0.0.26 lets attackers smuggle malicious pickle payloads past the scanner by invoking idlelib.pyshell.ModifiedInterpreter.runcode from a __reduce__ method, which picklescan does not blocklist. Because organizations rely on picklescan to vet PyTorch models and serialized Python objects, a payload it marks 'safe' still achieves arbitrary command execution the moment the victim calls pickle.load(), enabling ML supply-chain attacks. Publicly available exploit code exists (GHSA-3gf5-cxq9-w223 ships a working PoC); the CVE is not in CISA KEV and EPSS data was not provided, so active exploitation is unconfirmed.
Detection bypass in picklescan before 0.0.29 allows malicious pickle files to evade scanning by abusing the undetected idlelib.calltip.Calltip.fetch_tip function, enabling arbitrary code execution when the file is later loaded via pickle.load(). Affects ML supply chains relying on picklescan to vet PyTorch models; publicly available exploit code exists in the GHSA advisory, but no public exploit identified in active campaigns at time of analysis.
Detection bypass in picklescan before 0.0.29 allows attackers to craft malicious pickle files using idlelib.debugobj.ObjectTreeItem.SetText in __reduce__ methods that evade the scanner's dangerous-function checks, resulting in arbitrary command execution when the victim subsequently calls pickle.load(). The flaw turns picklescan from a security control into a false-assurance tool for ML pipelines that consume untrusted PyTorch models. Publicly available exploit code exists via the GHSA advisory, though no public exploit identified in active campaigns at time of analysis.
Remote code execution in picklescan versions prior to 1.0.4 allows attackers to bypass the scanner's safety validation by crafting malicious pickle files that import unblocked Python standard library modules. The tool's blocklist (scanner.py _unsafe_globals) omits at least seven stdlib modules - including uuid, _osx_support, _aix_support, _pyrepl.pager, and imaplib - exposing eight functions that execute arbitrary commands via subprocess or os.system. Publicly available exploit code exists in the GHSA advisory, demonstrating CLEAN scan results for files that achieve full RCE on load; this is especially concerning because picklescan is relied on by HuggingFace Hub and similar ML pipelines.
Detection bypass in picklescan versions prior to 0.0.29 allows attackers to smuggle arbitrary code execution payloads through malicious pickle files by leveraging idlelib.autocomplete.AutoComplete.fetch_completions inside the __reduce__ method. Because the scanner does not flag this built-in Python function as dangerous, victims who rely on picklescan to vet PyTorch models or other pickle artifacts will load attacker-controlled code under pickle.load(). Publicly available exploit code exists (in the GHSA advisory), though no active in-the-wild exploitation has been reported.
Detection bypass in picklescan before 0.0.28 allows attackers to embed malicious torch.jit.unsupported_tensor_ops.execWrapper calls in pickle files that evade the scanner and execute arbitrary code when later loaded via pickle.load(). Publicly available exploit code exists in the GHSA advisory, and the flaw directly undermines the security guarantee picklescan is meant to provide for PyTorch model files. No CISA KEV listing and no EPSS data are provided, but the scanner bypass nature makes this a meaningful supply-chain risk for ML pipelines.
Detection bypass in picklescan before 0.0.33 allows attackers to smuggle arbitrary code through malicious pickle files by abusing numpy.f2py.crackfortran.myeval in a __reduce__ method, which the scanner fails to flag as dangerous. Any ML pipeline or model-hosting workflow that trusts picklescan's verdict before calling pickle.load() will execute attacker-controlled commands; publicly available exploit code exists in the GHSA advisory, and the CVSS 4.0 score of 7.6 reflects high confidentiality and integrity impact contingent on user interaction.
Detection bypass in picklescan prior to 0.0.29 allows attackers to smuggle remote code execution payloads through pickle files that the scanner incorrectly classifies as safe. The library fails to flag the built-in profile.Profile.runctx function when used in a __reduce__ method, so a downstream pickle.load() of the scanned file executes arbitrary Python. Publicly available exploit code exists in the GHSA-6vqj-c2q5-j97w advisory, though no active exploitation has been reported.
Detection bypass in picklescan before 0.0.29 allows attackers to smuggle arbitrary code execution payloads through pickle files by abusing the idlelib.autocomplete.AutoComplete.get_entity function inside __reduce__ methods. Because picklescan does not flag this function as dangerous, malicious ML model files (e.g., PyTorch checkpoints) appear safe to scan but execute attacker commands the moment a victim calls pickle.load(). Publicly available exploit code exists in the GHSA advisory, but no public exploit identified at time of analysis in CISA KEV.
Detection bypass in picklescan versions 0.0.26 and earlier (fixed in 0.0.30) allows attackers to smuggle arbitrary code through malicious pickle files by abusing Python's built-in ensurepip._run_pip function, which the scanner failed to flag as dangerous. Organizations relying on picklescan to vet PyTorch models or other serialized Python objects will load the file as safe and trigger remote code execution upon pickle.load(). Publicly available exploit code exists via the GHSA advisory PoC, though no public exploit identified in active campaigns at time of analysis.
Arbitrary code execution in Picklescan before 0.0.33 occurs because the scanner fails to flag the numpy.f2py.crackfortran._eval_length gadget when used inside a pickle __reduce__ method, allowing crafted pickle files to be marked safe while still executing attacker-supplied Python on load. Workflows that rely on Picklescan to vet untrusted pickle or PyTorch model artifacts are exposed to supply-chain poisoning, and publicly available exploit code exists in the GHSA advisory.
Detection bypass in picklescan versions before 0.0.30 allows malicious pickle files to evade security scanning by using cProfile.runctx in __reduce__ methods, leading to arbitrary code execution when the file is loaded via pickle.load(). The flaw undermines the core purpose of picklescan as a defensive tool for ML model security and was reported by VulnCheck with a published proof-of-concept in the GitHub Security Advisory. No public exploit identified at time of analysis as a weaponized in-the-wild attack, but PoC code is published in the GHSA.
Detection bypass in picklescan before 0.0.30 allows attackers to smuggle arbitrary code execution payloads through pickle files by abusing idlelib.pyshell.ModifiedInterpreter.runcommand inside a __reduce__ method, which the scanner fails to flag as dangerous. Any victim who relies on picklescan to vet PyTorch models or other pickle artifacts and then calls pickle.load() will execute attacker-supplied commands. Publicly available exploit code exists (PoC published in the GHSA advisory), no CISA KEV listing, and the issue is fixed in version 0.0.30.
Detection bypass in picklescan versions before 0.0.25 allows attackers to embed remote code execution payloads in pickle files by abusing the built-in timeit.timeit() function inside a __reduce__ method, which is not on the unsafe-globals blacklist. Any organization using picklescan to vet PyTorch or other pickle-based model files is affected, and a working PoC is publicly documented in the GHSA advisory (no public exploit identified at time of analysis as a weaponized tool, but POC code is published).
Detection bypass in picklescan before 0.0.28 allows attackers to smuggle arbitrary code through pickle files by abusing torch.utils._config_module.load_config inside __reduce__ methods, defeating the library's malicious-pickle scanning and enabling remote code execution when the file is later loaded. Publicly available exploit code exists (GHSA-vv6j-3g6g-2pvj includes a working PoC), and the flaw is significant for any ML pipeline that trusts picklescan to vet third-party PyTorch model files. No CISA KEV listing at time of analysis, so exploitation status is limited to public POC rather than confirmed in-the-wild use.
Unsafe pickle deserialization in picklescan before 1.0.1 allows unauthenticated remote attackers to create arbitrary zero-byte files on the server by crafting malicious pickle payloads that instantiate Python's standard-library logging.FileHandler class. This technique bypasses RCE-focused blocklists because it abuses legitimate standard library functionality rather than commonly blocked modules, making it a notable blocklist-evasion primitive. A publicly available proof-of-concept exploit exists; no public exploit identified at time of analysis for active KEV-confirmed exploitation, but the PoC demonstrates concrete filesystem impact including lock-file-based denial of service.
Scanner evasion in picklescan versions prior to 1.0.3 lets an attacker smuggle malicious PyTorch pickle payloads past the scan_pytorch detection routine and gain arbitrary code execution when the model is later loaded with torch.load(). The bypass exploits a parser-differential between picklescan's pickletools.genops()-based magic-number extraction and PyTorch's pickle_module.load(), allowing a __reduce__(eval, ('MAGIC_NUMBER',)) trick to produce files that scan as clean but still deserialize correctly. A detailed proof-of-concept is published in the GHSA advisory and the VulnCheck writeup; no CISA KEV listing or EPSS score was supplied in the input.
Arbitrary code execution in picklescan versions prior to 1.0.1 allows attackers to bypass the scanner's malicious pickle detection by obfuscating eval calls nested under callable objects via getattr, causing the very tool intended to detect malicious pickles to miss them. Publicly available exploit code exists via the GHSA advisory PoC, though no public exploit identified at time of analysis as actively used in attacks; the CVSS 4.0 score of 9.3 reflects unauthenticated network-reachable impact on confidentiality, integrity, and availability.
Arbitrary code execution bypass in picklescan before 1.0.4 allows attackers to smuggle malicious pickle files past the scanner by invoking the module-level profile.run() function, which is missing from the blocklist that only covers Profile.run and Profile.runctx. The scanner reports zero issues while pickle.loads() triggers exec() of attacker-controlled Python. No public exploit identified at time of analysis beyond the proof-of-concept in the GHSA advisory, and the issue is not listed in CISA KEV.
Arbitrary file read in picklescan versions before 0.0.35 allows remote unauthenticated attackers to exfiltrate sensitive server files by abusing standard-library callables that the tool's RCE-focused blocklist fails to detect. By chaining io.FileIO and urllib.request.urlopen inside a malicious pickle, an attacker can stream contents of files such as /etc/passwd to an attacker-controlled URL when the scanner processes untrusted model artifacts. Publicly available exploit code exists in the GHSA advisory, but there is no public exploit identified at time of analysis in the form of in-the-wild abuse.
Remote code execution against users of picklescan versions prior to 1.0.4 is achievable by smuggling any blocked function past its scanner using pkgutil.resolve_name as an indirection primitive. Because pkgutil.resolve_name is not on the blocklist, an attacker can chain two REDUCE opcodes to resolve and invoke os.system, builtins.exec, subprocess.call, or any other dangerous function while the scanner reports the pickle as CLEAN - a universal blocklist bypass that defeats picklescan's entire safety premise. No public exploit is identified in CISA KEV, but the GHSA advisory authored by VulnCheck publishes a complete working technique, so weaponization is trivial.
Detection bypass in picklescan versions prior to 0.0.27 allows attackers to smuggle malicious Python pickle files past the scanner by exploiting an off-by-one parsing error in STACK_GLOBAL opcode handling. The flaw, reported by VulnCheck and tracked under GHSA-9gvj-pp9x-gcfr, lets crafted pickles trigger an unexpected exception in _list_globals so dangerous imports such as os.system go unflagged; a working PoC is published in the advisory and a vendor patch is available, though no public exploitation against deployments has been observed.
Remote code execution in picklescan before 0.0.33 enables attackers to bypass the tool's malicious-pickle detection by smuggling the unblocked ctypes module into a pickle payload. A working POC demonstrates loading kernel32.dll via ctypes.WinDLL and invoking WinExec to launch arbitrary commands during pickle deserialization scans or downstream loads. Publicly available exploit code exists in the GHSA-4675-36f9-wf6r advisory, and the flaw undermines the very security guarantee picklescan is deployed to provide for ML model pipelines.
Security check bypass in PickleScan versions before 0.0.33 allows attackers to smuggle arbitrary code execution payloads past the scanner by invoking the pty.spawn function, which was omitted from the unsafe globals deny-list. Publicly available exploit code exists (released as part of the HeroCTF 2025 'Irreductible 2' challenge writeup), and the flaw is particularly impactful for platforms like Hugging Face and other ML pipelines that rely on PickleScan to vet PyTorch model files. No public exploit identified at time of analysis in CISA KEV.
Arbitrary file write in picklescan before 0.0.33 lets attackers bypass the tool's dangerous-call blocklist by abusing distutils.file_util.write_file inside crafted pickle payloads. Because picklescan is used as a safety gate before loading ML model pickles, a bypass means malicious models pass scanning and can overwrite files on disk to achieve denial of service or remote code execution. Publicly available exploit code exists in the GHSA advisory, though there is no public exploit identified at time of analysis indicating active exploitation.
Arbitrary code execution in picklescan before 0.0.33 allows remote attackers to bypass the scanner's malicious-pickle detection by using pydoc.locate and operator.methodcaller, which were missing from the deny-list. Any downstream tool that trusts a 'clean' picklescan verdict and then deserializes the pickle (e.g., ML model loaders) will execute attacker-supplied code. Publicly available exploit code exists (GHSA PoC), and CVSS 4.0 is rated 9.3 Critical, though no public exploit identified at time of analysis in CISA KEV.
A Protection Mechanism Failure vulnerability in mmaitre314 picklescan versions up to and including 0.0.30 allows a remote attacker to bypass the unsafe globals check. Rated critical severity (CVSS 9.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
An Improper Handling of Exceptional Conditions vulnerability in the ZIP archive scanning component of mmaitre314 picklescan allows a remote attacker to bypass security scans. Rated critical severity (CVSS 9.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
An Improper Input Validation vulnerability in the scanning logic of mmaitre314 picklescan versions up to and including 0.0.30 allows a remote attacker to bypass pickle files security checks by. Rated critical severity (CVSS 9.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
The unsafe globals in Picklescan before 0.0.25 do not include ssl. Rated medium severity (CVSS 6.8), this vulnerability is no authentication required, low attack complexity. Public exploit code available.
picklescan before 0.0.22 only considers standard pickle file extensions in the scope for its vulnerability scan. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
picklescan before 0.0.21 does not treat 'pip' as an unsafe global. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.