Picklescan Can Be Bypassed: 8 Flaws Let Malicious AI Models Pass as Safe (CVE-2026-3490), Update to v1.0.4

picklescan, the tool used to check whether a distributed AI model hides dangerous code, has been hit by eight vulnerabilities that let attackers slip past the check itself. The most severe, CVE-2026-3490, scores a perfect 10.0 on the 10-point severity scale (CVSS). All of them are the same kind of flaw: even a model that picklescan reports as "clean (safe)" can run the attacker's code on your PC or server the moment it is loaded.

picklescan is the de facto tool that Hugging Face, the world's largest AI model hub, uses to automatically scan uploaded models. In other words, these flaws punch a set of holes straight through the safety net that AI engineers worldwide have relied on as a "seal of approval." Every fix has landed in the latest picklescan 1.0.4, and users need to update right away.

This article explains what picklescan protects, why eight separate "detection bypasses" were possible, and what developers should do now. It also covers the structural reason scanning tools keep getting broken, and a safer way to handle models.

What picklescan is: a "dangerous-code scanner" for AI models

To follow this, you first need to understand "pickle." pickle is a built-in Python format for saving and restoring the state of data and programs. It is convenient, but it has always carried one trait: simply restoring (loading) a file can execute the instructions written inside it. That is not a bug; it is pickle's design.

And the standard model-saving format of PyTorch, widely used across AI, relies on this dangerous pickle. When you load a model with torch.load(), any code embedded inside runs as is. Anyone can upload a model to Hugging Face, and others casually download and load it. That opens the door to attacks that "post a malicious model and take over the machine of whoever downloads it."

picklescan exists to head off that danger. It parses the contents of a pickle file, checks whether "dangerous functions" such as os.system or exec are being called, and warns "Dangerous" if it finds any. Hugging Face runs every uploaded model through picklescan on the server side, combined with other tools such as ProtectAI and ClamAV. We have repeatedly covered cases where the tools meant to defend us get broken, but this time the target is a front-line tool guarding the safety of AI models.

The catch is that picklescan's check works by matching against a list of dangerous functions (a blocklist). If an attacker uses a function that is not on the list, the danger slips through. All eight of the flaws found this time exploit holes in that list.

Who crafts a model marked "safe," and why

The people this flaw works for are the ones in a position to hand you a downloadable model as something "safe" for your build. That seat belongs to an uploader who posts a model under a name one character off a popular one, someone who tweaks a well-rated model and reposts it as a "faster" or "Japanese-ready" build, and an insider who can edit a model file shared inside the company. None of them needs you to write code or click a shady link. It works off the everyday act of you going out, finding a handy-looking model, and pulling it in.

Their aim is not loud destruction but quietly walking off with the keys on the developer's machine the moment the model loads. Open the model with torch.load() and the code planted in the file runs on the spot, reading out Hugging Face and OpenAI API keys, AWS and GCP cloud credentials, GPU-server logins, and unreleased training data and models, then shipping them outward. Because it happens after picklescan has already shown a green "safe," the person who triggered it feels no sign that anything ran. The more privileged the production inference server and the closer it sits to internal data, the larger the payoff from poisoning a single model that runs there.

The cleanup falls on the developer who pulled the model in and the organization they belong to. If the stolen keys let the attacker reach further servers and data, the damage does not end at one machine: rotating every leaked credential, tracing which models were poisoned, and assessing the impact on users of any AI service that shipped with the tainted model all follow. Heavier still, the premise that "scanned means safe" collapses, leaving you to re-question every model you ever pulled in on that same judgment. That is why the root fix lands on moving to a file format where slipping past the scan no longer matters (safetensors) and raising picklescan itself to v1.0.4. First, let's walk through what actually happens across the eight flaws.

What happens: the scan says "safe," but the code runs anyway

The eight flaws use different techniques, but the result is the same. An attacker crafts a doctored pickle file (an AI model), picklescan reports "no dangerous functions found," yet when PyTorch actually loads it, the attacker's planted code runs. The shared trait is that the scan result and the real behavior diverge.

The methods fall into two broad camps. One is to substitute the dangerous action with a function that is not on the list. picklescan watches names like os.system, but Python's standard library holds plenty of "unwatched functions" that achieve the same thing. The attacker simply uses those. The other is to exploit a bug in picklescan's own parser, confusing or halting the scan partway. The scan stops with an error while PyTorch loads the file fine, so the danger sails through.

Below, the eight CVEs flagged by our automated detection are reviewed one by one, from most to least severe, with the technical category (CWE) and the fixed version.

The fixed versions look scattered, but upgrading to the latest 1.0.4 closes all eight. Rather than patching each one separately on an old release (0.0.27 or 0.0.33), standardizing on the latest version is the sure path.

The eight vulnerabilities

CVE-2026-3490: a "universal bypass" that resolves any function by name (CVSS 10.0)

The most severe of the eight, a perfect 10.0. Python has a standard feature, pkgutil.resolve_name, that takes a name given as a string (e.g. os:system) and pulls out the matching function at runtime. By calling this first, an attacker obtains a dangerous function without that name ever appearing on the list at all. Because it bypasses no matter what the list contains, it is called a "universal bypass." A technical analysis and the RAXE Labs advisory (GHSA-vvpj-8cmc-gx39) are public; the fix landed in 1.0.4. It is the clearest symbol of the blocklist approach's limits.

CVE-2026-53873: running code via the profiler (CVSS 9.8)

The standard profile module, which measures execution speed, has a function profile.run() that runs whatever string it is given. picklescan's list missed this "module-level profile.run()," and attackers could call an exec()-equivalent through it to run arbitrary code (NVD, CWE-184). Fixed in 1.0.4.

CVE-2026-53874: hiding eval behind getattr (CVSS 9.8)

By nesting the dangerous action under a callable object with getattr, an attacker hides a dangerous eval call from the scanner. It goes undetected in the pickle file and only runs at load time (NVD, CWE-502). Fixed in 1.0.1.

CVE-2025-71320: pydoc.locate and operator.methodcaller (CVSS 9.8)

A flaw that abuses two functions not on the list, pydoc.locate and operator.methodcaller, to slip past the safety check (NVD, CWE-184). These are also tools for pulling another function out by name, the same idea as CVE-2026-3490. Fixed in 0.0.33.

CVE-2025-71321: overwriting files at will (CVSS 9.8)

Because the list did not watch distutils.file_util.write_file, an attacker could overwrite any file on the system (NVD, CWE-502). Rewriting a config file or a startup script leads straight to service disruption or code execution. Fixed in 0.0.33.

CVE-2025-71323: hitting the OS directly via ctypes (CVSS 9.8)

ctypes is a standard module that lets Python call low-level OS features directly. Because it was not on the list, an attacker could load Windows' core file (kernel32.dll) via ctypes.WinDLL and operate the system directly (NVD, CWE-184). It bypasses the scan at the deepest level. Fixed in 0.0.33.

CVE-2025-71325: exploiting a parser bug (CVSS 9.8)

Rather than smuggling in a dangerous function under another name, this one exploits a bug in picklescan's parser itself. A flaw in tracking the read position of pickle's internal instructions (the STACK_GLOBAL opcode) meant that crafting the instruction's arguments confused the scan and let the danger slip by (NVD, CWE-391). Fixed in 0.0.27.

CVE-2025-71322: command execution via pty.spawn (CVSS 8.8)

A flaw that runs arbitrary commands using pty.spawn, which was not included in the list (NVD, CWE-693). At 8.8 it is the least severe of the eight, but it still ends in code execution, so the real risk stays high. Fixed in 0.0.33.

In the same wave, several other standard modules such as uuid and imaplib were also found missing from the list, as reported in picklescan's official advisory listing. It is not one or two holes; the evidence backs the view that the problem stems from the structure of the blocklist approach itself.

Why it keeps getting broken: the limits of the blocklist approach

This is not the first time picklescan has been broken. It has a history of "broken, then patched, then broken again." In 2025, security firms Sonatype and JFrog published bypass techniques one after another, and this batch of eight sits on that same line. Here is the timeline.

← Swipe to move

Why does the same tool keep getting broken? Because picklescan's check relies on a "list of dangerous things" (a blocklist). The blocklist approach enumerates dangerous functions one by one and watches for them, but Python's standard library holds countless functions that achieve the same danger under a different name. Close one and the attacker simply hunts for the next overlooked function. The RAXE Labs advisory also notes that "blocklist approaches are structurally incomplete for serialized object analysis." The cat-and-mouse game structurally never ends.

This pattern of "the defending tool itself becoming the attack surface" is not unique to picklescan. We have tracked cases like the security scanner Trivy being compromised repeatedly and the chained supply-chain attack that started with Trivy. The very mechanisms meant to guarantee safety, precisely because they are trusted, cause greater damage when broken.

What to do right now

"Just update picklescan" is not enough. Since the scan was bypassed, you also need to re-trust past results. In priority order:

1. Update picklescan to 1.0.4 or later. Run pip install --upgrade picklescan. If you install it automatically in CI or containers, check that a pinned version has not been left old. This closes all eight flaws.

2. Re-evaluate models that old versions marked "safe." Models you pulled in after passing a pre-fix picklescan check may actually have been dangerous. Especially for PyTorch models from untrusted sources, re-scan with the latest version or reconsider how you handle them. The assumption "it came back safe before, so it's fine" has now broken.

3. Move to a safer model format (safetensors). The fundamental fix is to move away from the pickle format that can execute code at all. safetensors, developed by Hugging Face, stores only numeric data and has no room to execute code; ONNX is similar. Distribute and load in such formats wherever possible, and the worry of a bypassed scan disappears. Not using the dangerous mechanism is far surer than relying on a scan.

4. Use defense in depth, assuming the scan can be bypassed. Load models in a disposable, network-isolated environment (a sandbox), and do not grant production servers excessive cloud privileges. The scan is only the first layer; a design that does not depend on it alone matters. To continuously inspect dependencies prone to contamination, the mindset of an OSS supply-chain monitor and scanner helps.

The danger of casually trusting and loading an external AI model is a recurring problem beyond picklescan. We have also covered the SGLang flaw where a malicious AI model takes over the server and the vLLM case where a setting that trusts and loads external models is abused.

CISA KEV status

As of June 18, 2026, these eight are not listed in the catalog of vulnerabilities that the U.S. agency CISA has confirmed as "actively exploited" (the KEV catalog). Still, picklescan is used at the foundation of AI model distribution, and these flaws can lead directly to large-scale supply-chain attacks via mass distribution of malicious models. We keep a running list of CVEs that CISA has confirmed as under attack in our CISA KEV dashboard (Japanese).

FAQ

Conclusion

picklescan, the tool that scans AI models for dangerous code, has eight flaws that let attackers slip past the scan. The most severe, CVE-2026-3490, scores a perfect CVSS 10.0 and can resolve any function by name, neutralizing the entire blocklist. Even a model picklescan marks "safe" can hijack your PC or server the moment it loads, and since it runs behind hubs like Hugging Face, the blast radius is wide.

The response: first, update to the latest 1.0.4. Then re-evaluate models you pulled in after an old version judged them "safe," and migrate where possible to the code-free safetensors format. The history of this scanner being broken again and again shows the limits of enumerating danger with a list. Rather than leaning entirely on the scan, avoiding the dangerous mechanism itself and isolating model loading—defense in depth—will matter more and more in AI development.

References

• ▸ NVD - CVE-2026-3490 (pkgutil.resolve_name universal bypass, CVSS 10.0)
• ▸ NVD - CVE-2026-53873 (exec via profile.run)
• ▸ NVD - CVE-2026-53874 (hiding eval behind getattr)
• ▸ NVD - CVE-2025-71320 (pydoc.locate / operator.methodcaller)
• ▸ NVD - CVE-2025-71321 (arbitrary file write via distutils)
• ▸ NVD - CVE-2025-71322 (pty.spawn)
• ▸ NVD - CVE-2025-71323 (ctypes)
• ▸ NVD - CVE-2025-71325 (STACK_GLOBAL parser bug)
• ▸ picklescan official security advisories (GitHub)
• ▸ RAXE Labs - PickleScan Universal Blocklist Bypass and Stdlib RCE Modules
• ▸ Sonatype - Bypassing picklescan: Four Vulnerabilities
• ▸ JFrog - Unveiling 3 Zero-Day Vulnerabilities in PickleScan
• ▸ ReversingLabs - Malicious ML models on Hugging Face (nullifAI)
• ▸ Hugging Face - safetensors (a safe model format)