PyTorch Security Guide (2026)

PyTorch is the dominant deep-learning framework for research and, increasingly, production inference. It underpins a large fraction of the models on public hubs, the training code in academic and industrial labs, and the serving stacks behind modern AI products. On PyPI the torch package sees very high download volume, and it arrives transitively through Hugging Face libraries, Lightning, and countless model repositories. Because PyTorch's core workflow is loading model weights — often weights someone else produced — its most serious security history centers on deserialization: torch.load has historically been able to execute arbitrary code from a crafted checkpoint. If you serve or fine-tune models you did not train yourself, this is the single most important thing to understand.

The notable historical CVEs

PyTorch's published advisories cluster around unsafe code execution — in checkpoint loading, in the JIT front end, and in the distributed runtime. These are all real, published advisories:

• CVE-2025-32434 — the big one. torch.load was believed safe when called with weights_only=True, but a bypass allowed a crafted checkpoint to achieve remote code execution even with that flag set. Fixed in PyTorch 2.6.0. This invalidated the common assumption that weights_only=True made loading arbitrary checkpoints safe on older versions.
• CVE-2022-45907 — torch.jit.annotations.parse_type_line used eval unsafely, allowing arbitrary code execution when processing crafted type annotations. Fixed in 1.13.1.
• CVE-2024-5480 — the torch.distributed.rpc framework did not properly verify the functions invoked during remote procedure calls, allowing arbitrary command injection against a distributed training or inference cluster. Rated high to critical severity.

Alongside the CVEs, PyTorch was also the target of a notable supply-chain incident: in December 2022, an attacker published a malicious torchtriton package to PyPI that shadowed the dependency PyTorch's nightly builds expected to install, a classic dependency-confusion attack. It exfiltrated environment data from machines that installed the nightly build before it was caught. It is a reminder that the framework's dependencies, not just its own code, are part of your attack surface.

Common misuse and risks

• Calling torch.load on untrusted checkpoints. This is the core risk. The default legacy behavior deserializes with pickle, which can run arbitrary code, and CVE-2025-32434 showed that even weights_only=True was not a durable guarantee on older versions. Treat a .pt/.pth/.bin checkpoint from an unverified source as executable data.
• Assuming a flag makes loading safe. Relying on weights_only=True on a pre-2.6.0 build gave a false sense of security.
• Exposing the distributed RPC framework. torch.distributed.rpc is designed for a trusted cluster network. Exposing it to untrusted input (CVE-2024-5480) invites remote code execution.
• Installing nightly or unpinned builds carelessly. The torchtriton episode shows how an unpinned or misconfigured install channel can pull a malicious package.

How to use PyTorch safely

Set the version floor: run PyTorch 2.6.0 or later, which fixes the torch.load weights_only bypass (CVE-2025-32434) and builds on the JIT and RPC fixes. Anything older leaves you exposed to at least one code-execution path.

Then treat model loading and installation as trust decisions:

• Only load checkpoints you trust and can verify, and prefer the safetensors format for weights — it is a non-executable serialization designed precisely to avoid the pickle-based code-execution problem.
• Use weights_only=True on a current version, but understand it is defense-in-depth, not a license to load anything: the safest posture is verified provenance plus a safe format.
• Do not expose torch.distributed.rpc to untrusted networks. Keep distributed training on an isolated, authenticated network segment.
• Pin dependencies and lock your install channel. Use a lockfile, prefer stable releases over nightly in production, and configure your package manager so it cannot resolve internal-looking names from the public index — the defense against dependency confusion.
• Sandbox untrusted inference. Run models of uncertain origin in an isolated process with restricted filesystem and network access.

How to monitor PyTorch with SCA and reachability

PyTorch shows up in nearly every ML dependency tree, often several layers deep through model and training libraries. A version-only scanner flags it broadly; what matters is whether you are on a patched release and whether your code actually reaches a dangerous call — torch.load on external input, or an exposed RPC endpoint.

Safeguard's software composition analysis resolves your full Python dependency graph, including the transitive torch and companion libraries you did not choose directly, and adds call-path reachability so a deserialization CVE your code can trigger is separated from a dormant one. When a fix exists, autonomous auto-fix opens a tested pull request that bumps the version, and Griffin AI explains the safest change — usually "move to safetensors and pin 2.6.0." Developers run the same analysis locally and in CI with the Safeguard CLI, and teams weighing tools can review the pricing options.

Bring continuous, prioritized dependency analysis to your ML services — get started free or read the documentation.

Frequently Asked Questions

Which PyTorch version is safe in 2026?

Run PyTorch 2.6.0 or later. That release fixes CVE-2025-32434, the torch.load bypass that allowed remote code execution even with weights_only=True, and it sits above the JIT eval fix (CVE-2022-45907) and the distributed RPC fix (CVE-2024-5480). Older builds are missing at least one code-execution fix.

Is torch.load safe if I set weights_only=True?

On a current version it is much safer, but treat it as defense-in-depth rather than a guarantee. CVE-2025-32434 showed the flag could be bypassed on older builds, so the durable posture is verified provenance plus a non-executable format like safetensors. Never load a checkpoint from an unverified source and assume a flag protects you.

What was the torchtriton incident?

In December 2022 an attacker uploaded a malicious torchtriton package to PyPI that shadowed a dependency PyTorch's nightly builds expected, a dependency-confusion attack that exfiltrated data from machines installing the nightly channel. The defense is pinning dependencies with a lockfile and configuring your package manager so internal-looking names cannot resolve from the public index.

How do I know if a PyTorch CVE actually affects my app?

Use reachability-aware SCA. It traces whether your code reaches the vulnerable behavior — for instance calling torch.load on externally supplied data or exposing the RPC framework — so you can prioritize the genuinely exploitable findings over CVEs that sit in code paths you never run.