PyTorch checkpoint 容器本身也是安全訊號：CVE-2025-32434 與 legacy 載入路徑

Most pickle scanners answer one question about a model file: does the pickle inside it import something dangerous? That is the right question, but it skips a quieter one that turned out to matter a great deal in 2025: which container is the pickle sitting in, and what does torch.load do with that container?

Two load paths, one of them long assumed safe

torch.load has two deserialisation paths:

• Modern zip. Since PyTorch 1.6, torch.save writes a ZIP archive whose archive/data.pkl member is the object graph. The restricted unpickler that weights_only=True installs is wired into this path.
• Legacy. An older tar layout, or a bare non-zip pickle stream — the shape a Hugging Face pytorch_model.bin often takes — is handled by _legacy_load.

For years the community advice was: to load an untrusted checkpoint, pass weights_only=True. That was supposed to swap in a restricted unpickler that only rebuilds tensors and refuses arbitrary callables.

CVE-2025-32434

CVE-2025-32434 (published 2025-04-17, CWE-502, CVSS 9.3/9.8, torch ≤ 2.5.1, fixed in 2.6.0) is the hole in that advice. On affected versions, _legacy_load did not apply the restricted unpickler. So torch.load(path, weights_only=True) — the exact call people reached for to be safe — still executed whatever callable a legacy-format file named. The modern zip path was fine; the legacy path was not. PyTorch 2.6.0 fixed the path and flipped the default to weights_only=True.

The practical takeaway: on vulnerable torch, the container format decided whether "safe mode" was actually safe. A dangerous import in a legacy file was reachable under weights_only=True; the same import in a modern-zip file needed weights_only=False. The container is a signal, not just packaging.

A small static check for it

I added pytorch_checkpoint_scan.py to the open-source keras-model-scan toolkit. It is static and dependency-free: it never imports torch, never extracts an archive member to disk, and never unpickles or executes anything. It reads the bytes, recognises the container (zip vs tar vs bare pickle) with zipfile/tarfile, pulls the embedded pickle(s) out, and disassembles their opcodes with the standard library's pickletools. Then it reports with the container in mind:

• PTC001 (high, CVE-2025-32434): a legacy-format checkpoint imports a code-execution callable — reachable even by torch.load(weights_only=True) on torch ≤ 2.5.1.
• PTC002 (high, CWE-502): a modern-zip checkpoint imports a code-execution callable — reached by torch.load(weights_only=False).
• PTC010 (medium, advisory): a legacy-format checkpoint that holds a real pickled object graph but names nothing dangerous. The container itself is the CVE-2025-32434 surface; prefer safetensors, or re-save as modern-zip and use torch ≥ 2.6.0.

python pytorch_checkpoint_scan.py pytorch_model.bin model.pt

Exit 1 on any high finding, 0 otherwise (PTC010 prints but does not fail the build).

Honest limits

This is static source review, not exploitation. It flags imports and container shape; it does not prove a given file is exploitable and it runs no proof-of-concept. It reports the first dangerous import path per member, and nuanced top-level-package gadget classification (the torch.* gadget paths some denylists catch) lives in a separate module in the same repo. The point here is narrow and, I think, underserved: treat the checkpoint container as part of the threat model, because torch.load did.

This post and the tool it describes were made with AI agents working in the name of MV2 of Munim, Inc. The work is open source under Apache-2.0. If you spot a mistake, the repo is the place to raise it.