Picklescan Bypass File Extension Mismatch: 6 Controls

picklescan walks the opcode stream of a pickle without executing it and checks every GLOBAL import against two hard-coded dictionaries in scanner.py: an allowlist named _safe_globals and a blocklist named _unsafe_globals. In 1.0.5 the allowlist covers 6 modules and 23 named entries. The blocklist covers 67 modules, 36 of them wildcarded to the entire module and 57 named callables. An import in neither dictionary is reported as suspicious and still passes, unless the scan runs with --strict, which promotes suspicious globals to dangerous.

The blocklist is thorough about what it knows. os, subprocess, pty, ctypes, profile, cProfile, _pyrepl and numpy.f2py are wildcarded whole. Named entries cover builtins.eval, exec, compile, getattr, open and breakpoint, plus _io.FileIO, logging.FileHandler, pkgutil.resolve_name and the attrgetter / itemgetter / methodcaller trio in both operator and _operator.

Each entry exists because somebody disclosed the gadget first. The project's own security advisory tab lists sixty published advisories: 6 critical, 10 high and 44 medium, the earliest published 3 March 2025 and the most recent 2 March 2026, with twenty of them landing between 26 December 2025 and 2 March 2026 alone. The global advisory database returns 77 records referencing picklescan, 18 marked as duplicates, leaving 59 distinct advisories of which 23 carry CVE identifiers.

So a clean report establishes one thing: no currently-blocked callable appeared in the files this version knew how to open. A useful signal, not a gate, and the exit code is where teams turn it into one incorrectly.

That pickle.loads over untrusted bytes is CWE-502 is covered in our audit of three LangChain CVEs in one week. This post is about the narrower case: weight files whose format was chosen by whoever published the checkpoint.

Dispatch happens before parsing: scan_bytes() reads the file extension and routes on it, and that routing table has coverage gaps of its own.

.bin sits in the PyTorch set, so model.bin goes to scan_pytorch(), which calls get_magic_number() to identify the container format. A plain pickle carries no MAGIC_NUMBER integer, get_magic_number() returns None, and scan_pytorch() raises InvalidMagicError. In 0.0.30 scan_bytes() turned that into ScanResult([], scan_err=True) and stopped, never reaching the pickle handler that would have caught posix system. In 1.0.5 the same call site catches InvalidMagicError, seeks the stream back to offset 0, and continues into the zip and pickle paths, which is why the identical model.bin is flagged there.

# On picklescan <= 0.0.30 the extension decides whether the payload is read at all.
picklescan --path model.pkl   # dangerous import 'posix system' FOUND -> Infected files: 1, exit 1
cp model.pkl model.bin
picklescan --path model.bin   # ERROR: Invalid magic number ... -> Infected files: 0, exit 2

# On 0.0.31 and above the same model.bin is correctly flagged, exit 1.

The advisory record is GHSA-jgw4-cr84-mqxg, published in the repository on 8 September 2025 alongside the fix, in the GitHub database on 10 September, and in the national vulnerability database on 17 September. It is classified CWE-20, improper input validation, and CWE-693. Two scores sit on it, a full severity band apart. The project advisory and the national vulnerability database's own primary analysis both give CVSS 3.1 base 7.8 high, vector AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. A CVSS 4.0 base 9.3 critical score contributed by the reporting party rides along in the GitHub database record and in the NVD record as a secondary metric, which is why the GitHub database labels the advisory critical while the project's own tab labels it high. Name the scoring version and the record whenever you quote a number, or two risk registers will carry the same finding at different severities.

Twelve releases shipped from 0.0.30 to 1.0.5, between 26 August 2025 and 1 July 2026. Most of them closed a disclosed bypass or added newly blocked callables.

Two changes ship only in 1.0.5. --strict is the difference between a report you read and a gate that denies by default. And requires_python jumps from >=3.9, which held through 1.0.4, to >=3.11, so a scanner running in a Python 3.10 CI image cannot install the current version at all. Check that before you write the pin, or the resolver quietly selects 1.0.4 and the gate still looks green.

pip install "picklescan>=1.0.5"

# Default-deny scan of an intake directory.
picklescan --path ./model-intake --strict

# 0 = no malware, 1 = malware found, 2 = scan failed.
# CI must treat any non-zero exit as a hard gate failure, not just exit 1.

The full flag surface is -p/--path, -u/--url, -hf/--huggingface, -g/--globals, --strict, --exclude, --include, --exclude-dir, --include-dir and -l/--log, with the three input flags mutually exclusive. There is no JSON output mode and no fail-on threshold, so the exit code is the entire machine-readable interface, which is why the exit-2 case needs its own line in the pipeline.

A blocklist of dangerous callables can be extended forever and still lose to indirection. CVE-2026-3490 is the clean demonstration: pkgutil.resolve_name takes a string like os:system and returns the object it names. A chained REDUCE that calls it obtains any blocked function at load time while picklescan sees only an import of pkgutil.resolve_name, which was not on the list, and never inspects the REDUCE arguments that decide what gets resolved. It was scored 10.0 under both CVSS 3.1 and CVSS 4.0, and was patched by adding one more name to the same list.

Each is a separate mechanism with its own affected range, and conflating them produces bad remediation tickets.

The measured picture agrees. A 2025 study of model loading policies reports that 44.9 percent of popular Hugging Face models still ship in the pickle format, that 15 percent of those cannot be loaded at all under restrictive loading policies, and that the restrictive loader it benchmarks against loads 22 percent fewer benign models than its own approach, which rejects 100 percent of the malicious samples in its dataset while loading 79.8 percent of benign ones. A February 2026 evaluation measured widely-used pickle scanners at 7.23 to 62.75 percent F1 on a 727-file dataset, with picklescan tested at 0.0.30, against 90.01 percent for the learned detector it proposes; on an out-of-distribution set that detector scores 81.22 percent against 76.09 percent for the 2025 policy-based loader.

Nor does the hosting platform close it. The Hugging Face Hub runs a malware scan plus an import listing built on pickletools.genops that enumerates imports without executing code, and the Hub's own security documentation states this is not 100 percent foolproof and that the import lists are maintained best-effort. That is accurate disclosure: no import-listing scanner can be complete against gadget-chain construction.

Inside a private perimeter, three of those six controls change shape.

Vetting collapses to a single event. The file is scanned, hashed and provenance-recorded once during the transfer window, and from then on the serving nodes trust the recorded SHA-256 digest and nothing else. Re-running picklescan on every node spends escort time to learn what the digest already guarantees.

The scanner becomes a frozen artifact. An air-gapped picklescan cannot pull blocklist updates, so "pin the floor and re-check on a schedule" stops being a cron job and becomes a change-window-bound manual task with a named owner. With twelve releases in ten months, a copy four releases old is blind to every bypass class disclosed since, and it stays that way until the next escorted update. That makes the scanner an inventory item with a staleness clock, which is a governance conversation rather than an engineering one.

The sandbox load carries more weight here too. There is no cloud provider egress alarm behind you, so the enclave's own network-deny posture is the entire backstop, which is the same argument as blocking outbound calls at runtime in running vLLM air-gapped. The stores around a privately served model need the same treatment, covered in hardening a self-hosted vector database. For where model intake sits relative to prompt injection, exfiltration and access control, our AI security pillar maps the rest.

For a connected shop the six controls are identical. What on-prem changes is which artifact is authoritative: the digest, not the scan.

Open the pipeline definition that pulls model weights.

List every file extension the gate accepts today. If .bin, .pt, .pth or .ckpt are on it, note which upstream models forced them, because that list is your safetensors conversion backlog and it is usually shorter than people expect.

Find the line that evaluates the scanner result. If it compares against exit code 1, or parses the summary text, change it to fail on any non-zero exit. One line, and it is the difference between catching an extension mismatch and shipping it.

Check the pinned version with pip show picklescan in the CI image, against 1.0.5 and against the Python that image runs, since 1.0.5 needs 3.11. If the pin is old or absent, set it and add the re-check to whatever calendar already holds your dependency review.

Then record a SHA-256 digest for every weight file already in production. Not because you distrust the scan that let them in, but because you cannot prove today which bytes that scan saw.