Pickle deserialization vulnerabilities have quietly become one of the most consequential classes of security flaws in the machine learning supply chain. The most notable recent example, CVE-2025-32434, shows that even PyTorch's dedicated safe-loading mode was not immune: a maliciously crafted model checkpoint could still trigger arbitrary code execution on the machine loading it, undermining years of guidance that told practitioners "just use weights_only=True." For a security category that regulators increasingly expect organizations to manage — model provenance, artifact integrity, third-party AI risk — this is a case study in why a pickle deserialization vulnerability in a widely used ML framework deserves the same scrutiny as a remote code execution bug in a web server.
What Happened
PyTorch's torch.load() function has historically relied on Python's built-in pickle module to deserialize model checkpoints. Pickle is, by the Python documentation's own admission, not designed to be secure against maliciously constructed data — unpickling untrusted input can execute arbitrary code because pickle streams can embed instructions to import modules and call functions during deserialization. This is the root mechanism behind nearly every PyTorch pickle exploit reported over the past several years, and it is not unique to PyTorch: scikit-learn's joblib.load(), pandas' read_pickle(), and older TensorFlow/Keras checkpoint paths all inherit the same fundamental weakness because they sit on top of the same serialization primitive.
To address this, PyTorch introduced a weights_only parameter for torch.load(), intended to restrict deserialization to tensor data and a narrow allow-list of safe types, blocking the arbitrary class instantiation that makes pickle dangerous. Starting with PyTorch 2.6 (released in early 2025), weights_only=True became the default behavior specifically because unsafe model loading via full pickle deserialization had become common enough in the ecosystem to warrant a safer default.
CVE-2025-32434 disclosed that this protection was incomplete. Researchers found that the allow-list and type-checking logic underpinning weights_only=True could still be bypassed under certain conditions, allowing a specially crafted checkpoint to reach code paths that execute attacker-controlled logic during load — even when the caller believed they were using the "safe" API. In practice, this meant that guidance many teams had already adopted as their primary mitigation did not fully close the door on exploitation.
Affected Versions and Components
The vulnerability affects torch.load() in PyTorch releases prior to the version that shipped the fix for this specific bypass, meaning organizations relying solely on weights_only=True in earlier 2.x releases were still exposed. Because the flaw sits in the deserialization path rather than in a single API call, it affects any workflow that loads .pt or .pth checkpoint files from an untrusted or unverified source — including model files pulled from public hubs, shared via CI/CD artifact stores, or distributed through third-party integrations.
The downstream impact reaches beyond raw PyTorch usage. Hugging Face's transformers library, which wraps torch.load() for many model-loading code paths, responded by adding version checks that block weights_only loading unless the installed PyTorch version contains the fix, effectively forcing an upgrade path for any pipeline that loads PyTorch checkpoints through the Transformers ecosystem. Any internal tooling, MLOps platform, or inference service that accepts user-supplied or externally-sourced model files inherits this exposure as well, since the vulnerable code executes wherever deserialization happens — training servers, inference endpoints, notebooks, and CI runners alike.
CVSS, EPSS, and KEV Context
NVD's entry for CVE-2025-32434 reflects a Critical-severity rating, consistent with the outcome of successful exploitation: arbitrary code execution with the privileges of the process loading the model, which in many ML environments means direct access to GPU infrastructure, cloud credentials mounted into training jobs, and any data reachable from that host. As of this writing, the CVE does not appear in CISA's Known Exploited Vulnerabilities (KEV) catalog, and there is no confirmed evidence of mass in-the-wild exploitation tied specifically to this CVE. That absence should not be read as low risk, however — pickle-based model exploits are, by nature, supply-chain attacks that trigger only when a victim voluntarily loads a poisoned file, which makes them harder for network-based telemetry and EPSS-style exploitation-prediction models to observe compared to internet-facing vulnerabilities.
This is not a hypothetical attack path. In February 2024, security researchers at JFrog publicly documented a malicious model uploaded to the Hugging Face Hub that used a crafted pickle payload embedded in a PyTorch checkpoint to open a reverse shell back to an attacker-controlled host the moment the file was loaded — a real-world PyTorch pickle exploit sitting on a public model repository, waiting for someone to run torch.load() on it. A few months later, in June 2024, Trail of Bits published research on an attack technique dubbed "Sleepy Pickle," demonstrating that pickle payloads embedded in model files could not just gain code execution but silently patch model weights or inference logic post-load — turning a seemingly benign model artifact into a persistent, hard-to-detect backdoor rather than a one-time exploit.
Timeline
The underlying risk in pickle-based model formats has been understood since pickle's design: the Python documentation has long warned against unpickling data from untrusted sources. What changed is the exposure surface, as pickle became the default serialization format for one of the most widely deployed ML frameworks in production. The JFrog disclosure in February 2024 demonstrated real-world exploitation of PyTorch pickle exploit techniques against public model repositories. The Sleepy Pickle research in June 2024 broadened the community's understanding of what a pickle deserialization vulnerability can accomplish beyond simple shell access. PyTorch's shift to weights_only=True as the default in the 2.6 release (early 2025) was the framework's direct response to this pressure. CVE-2025-32434, disclosed in 2025, then revealed that the bypass mitigation itself had a gap, prompting both a PyTorch-side fix and defensive changes in downstream consumers like Hugging Face Transformers, which added version gating to prevent unsafe model loading paths from being reachable on unpatched installations.
Why This Pickle Deserialization Vulnerability Matters for ML Supply Chains
What makes this issue distinct from a typical application CVE is where the trust boundary sits. In a conventional software supply chain, you scrutinize source code and dependencies. In an ML pipeline, the "dependency" is frequently a binary model checkpoint — often hundreds of megabytes to tens of gigabytes — pulled from a public hub, a partner's storage bucket, or a fine-tuning vendor, with no equivalent of a code review before it is deserialized and executed. A pickle deserialization vulnerability in the loading path means the model file itself is a code execution vector, not just a data artifact. That reframes model files as first-class supply chain risk on par with container images and open-source packages, and it explains why regulatory and compliance frameworks focused on AI risk management increasingly call out model provenance and integrity verification as control requirements rather than optional hygiene.
Remediation Steps
- Upgrade PyTorch to a version that contains the fix for CVE-2025-32434, and audit any pinned or vendored PyTorch versions in containers, training images, and dependency lockfiles.
- Never fully trust
weights_only=Trueas a standalone control. Treat it as defense in depth, not a guarantee, given the documented bypass — pair it with source verification. - Prefer safetensors over pickle-based formats wherever possible. The safetensors format was purpose-built to store tensor data without executable pickle opcodes, eliminating the arbitrary code execution ML pipelines are exposed to when loading
.pt/.pthcheckpoints from unverified sources. - Scan model artifacts before loading them. Tools such as Protect AI's ModelScan, Trail of Bits' Fickling, and Hugging Face's picklescan can flag suspicious opcodes in pickle streams before they ever reach
torch.load(). - Only load models from verified, signed sources, and validate checksums or signatures against a known-good manifest rather than trusting a hub listing or filename alone.
- Sandbox model loading in CI/CD and inference environments — run deserialization in a restricted, network-isolated, least-privilege context so that a successful exploit cannot reach cloud credentials, secrets, or lateral network access.
- Maintain an inventory of model provenance, including where each checkpoint originated, its hash, and its scan history, so that a future CVE affecting your model formats can be triaged quickly instead of requiring a manual hunt across every service that loads a checkpoint.
How Safeguard Helps
Safeguard treats ML model artifacts as first-class components of the software supply chain, not as opaque binaries outside the reach of security tooling. For organizations managing exposure to issues like this pickle deserialization vulnerability, Safeguard provides continuous scanning of model files and their serialization formats to flag unsafe pickle opcodes, unverified provenance, and known-vulnerable framework versions before artifacts reach production. Safeguard's policy engine can enforce controls at the CI/CD gate — blocking untrusted .pt/.pkl uploads, requiring safetensors or signed formats, and preventing deployment on PyTorch versions still exposed to CVE-2025-32434 — while generating the provenance records and audit evidence that regulatory and compliance frameworks expect for third-party AI and ML risk management. Combined with real-time CVE and KEV monitoring across the ML toolchain, Safeguard gives security and compliance teams a single source of truth for whether unsafe model loading is happening anywhere in their environment, and the automated guardrails to stop it before it becomes an incident.