PyTorch Security: Notable CVEs and How to Harden Your Loading Path

If you look at PyTorch’s most serious CVEs in order, a single shape repeats: loading data — usually a model checkpoint — causes code to run. The framework’s numerical core is mature and rarely the source of a critical entry; the dangerous surface is the I/O boundary where bytes you did not produce get turned back into Python objects. Every one of the CVEs below is verified against the NVD record before it is cited here, and the pattern across them is more instructive than any single score.

The flagship: torch.load RCE even with the “safe” flag

CVE-2025-32434 ↗ is the one to internalize. NVD records it as a remote command execution vulnerability in PyTorch when loading a model using torch.load — and critically, it applied even with weights_only=True, on versions 2.5.1 and prior. CVSS base score 9.8 (critical). The fix is PyTorch 2.6.0, which also makes weights_only=True the default.

The reason this matters beyond its score: for years the standard mitigation advice was “pass weights_only=True and you’re safe.” This CVE proved that guidance was a flag on top of a fundamentally unsafe loader, and a parser bug was enough to defeat it. If your runbook still says “we set weights_only, we’re fine,” that runbook had an expiry date and CVE-2025-32434 was it.

The original eval-in-the-loader bug

CVE-2022-45907 ↗ (CVSS 9.8) is older and narrower but worth knowing as the archetype: in PyTorch before the trunk fix, torch.jit.annotations.parse_type_line could cause arbitrary code execution because eval was used unsafely. A type annotation string flowing into eval is the same class of mistake as a serialization opcode that calls a function — code execution arising from data that was supposed to be inert. Different code path, identical lesson.

Distributed RPC: powerful by design, dangerous by default

CVE-2024-48063 ↗ records that in PyTorch <= 2.4.1, the RemoteModule has a deserialization RCE (CVSS 9.8). One honest caveat: this entry is disputed — multiple parties argue it describes intended behavior of the distributed framework rather than a flaw, since torch.distributed.rpc is explicitly documented as trusting its peers. That dispute is itself the takeaway. PyTorch’s RPC layer assumes a trusted network. If you expose it to anything you do not fully control, you have handed out code execution, CVE or no CVE. Treat the RPC port like an unauthenticated shell and network-isolate it.

Not everything is RCE — and the score reflects that

CVE-2024-31580 ↗ is a heap buffer overflow in /runtime/vararg_functions.cpp in PyTorch before 2.2.0, scored 4.0 (medium). It is a real memory-safety bug, but its modest score and local-leaning vector are an antidote to treating “PyTorch CVE” as automatically code-red. A buffer overflow reachable only when you feed a crafted model through a specific runtime path is a very different exposure than an unauthenticated load that runs a shell command. Read the affected component before you panic-patch.

Worth tracking even at low score

CVE-2025-3136 ↗ reports memory corruption in torch.cuda.memory.caching_allocator_delete (c10/cuda/CUDACachingAllocator.cpp) in PyTorch 2.6.0, scored only 3.3 on CVSS v3.1. It is included here precisely because it is minor: it shows the same recent PyTorch version (2.6.0) that fixed the critical load bug still carries low-severity issues. Currency is not a one-time event. You upgrade to escape 32434 and you inherit a new, smaller backlog — which is normal and fine, as long as you keep tracking.

The hardening that actually holds

The CVEs above are not independent surprises; they are repeated confirmations of one exposure — we deserialize artifacts we did not produce. Hardening therefore targets the exposure, not each entry:

• Change the format, not the flag. Prefer safetensors for weights. It is a header plus raw tensor bytes with no callable invocation on load, so it removes the code-execution sink rather than guarding it. This is the single highest-leverage change, and it is what defangs the entire 32434 lineage.
• Stay on a current PyTorch. 2.6.0+ both fixes CVE-2025-32434 and makes weights_only=True the default. Upgrading is the fix; a flag was never the fix.
• Scan artifacts before they reach the loader. Hugging Face runs scanning on the Hub; picklescan and Trail of Bits’ fickling can flag dangerous opcodes in CI before a file ever touches torch.load. Note that scanners have their own gaps, so treat scanning as defense in depth, not a guarantee.
• Isolate the RPC layer. If you use torch.distributed.rpc, the CVE-2024-48063 dispute is your warning label: it trusts peers by design. Keep it on a private network segment with no untrusted reachability.
• Pin and verify provenance. Pull checkpoints by digest, record the hash that was scanned, and reject anything that does not match at load time.

How to read the next PyTorch CVE

When the next entry lands, do not start from the CVSS number. Start from one question: does this code path touch bytes I did not produce and verify? A 9.8 in torch.load is an emergency if you load community checkpoints at runtime and nearly inert if every artifact is built in-house from trusted source and stored content-addressed. A 4.0 buffer overflow can be more urgent than a 9.8 for a team whose architecture happens to reach the vulnerable path with attacker-influenced input. The score is computed against a generic threat model; your deployment is the real one.

See also

• Unsafe model deserialization: the pickle problem behind ML CVEs
• Reading an ML library CVE beyond the CVSS score