Security

The repo's SECURITY.md is the authoritative document; this page summarizes the security-relevant code paths and conventions.

Reporting

Per SECURITY.md, security issues should be reported privately to security@pytorch.org (or via the GitHub Security Advisories tab on the repo). The PyTorch project follows a coordinated disclosure timeline.

High-impact code paths

torch.load / torch.save

The historical torch.load(path) was equivalent to pickle.load, which can execute arbitrary code on a malicious file. Years of work have produced:

• weights_only=True — only deserialize a vetted set of types (tensors, dicts, lists, primitives, registered safe globals). The default is now weights_only=True; users who need full unpickling must explicitly opt out.
• Allowlist registration — third-party libraries can call torch.serialization.add_safe_globals([...]) to permit additional types under weights_only=True.
• Format hardening — the zip-based PyTorch format (.pt / .pth) is parsed with strict validation in caffe2/serialize/inline_container.cc.

The relevant code lives in torch/serialization.py and torch/_weights_only_unpickler.py.

torch.jit.load

TorchScript loading parses a binary IR plus pickled constants. Same defensive principles apply — _extra_files, schema validation, and the same zip-container bounds checking. TorchScript is in maintenance mode; new deployments should prefer AOTInductor.

torch.distributed over a network

NCCL/Gloo collectives between nodes assume a trusted multi-host environment — there's no authentication or encryption at the collective layer. Production distributed training relies on the cluster's network isolation, IPSec, or a service mesh for transport security.

The torch.distributed.elastic rendezvous backends (etcd, c10d, rdzv) are similarly trust-the-network. Kubernetes operators add the missing TLS/AuthN layer.

cpp_extension and load_inline

torch.utils.cpp_extension.load_inline(...) compiles user-provided C++/CUDA source at runtime and links it into the process. By design, anything that calls load_inline with attacker-controlled source has full RCE. This is documented; users should treat cpp_extension.load(...) like eval(...).

Custom-op registration

torch.library registrations are global and persistent within a process. A library that registers a kernel for aten::add can intercept every add. There's no permission model — by-design, anything in your Python process trusts everything else.

Container hardening

The official PyTorch Docker images:

• Pin specific Python and CUDA versions.
• Run as root by default (consumers should override).
• Bundle Triton, FlashAttention pre-built kernels, and a recent NCCL.

For untrusted-input deployments, use a hardened base image (distroless, gVisor) and avoid running any code that does deserialization, custom ops, or cpp_extension.

Supply-chain

Surface	Mitigation
PyPI wheels	Signed by maintainers; checksums published
Third-party submodules	Pinned by SHA in .gitmodules; updated explicitly via PR
Vendored libs	Pinned versions in cmake/External/
Tools (lintrunner, clang-tidy)	Pinned binaries downloaded by lintrunner --init

CVE history (selected)

• Multiple torch.load arbitrary-code-execution CVEs (2022–2024) — addressed by weights_only becoming opt-in then default.
• Distributed-elastic rendezvous CVEs — addressed by the rendezvous backend hardening.
• TorchServe CVEs (separate repo pytorch/serve) — included here for completeness; not in the main repo's threat model.

Where to look

File	Purpose
SECURITY.md	Reporting + scope
torch/serialization.py	torch.load/save
torch/_weights_only_unpickler.py	The restricted unpickler
caffe2/serialize/inline_container.cc	Zip-format parser
torch/csrc/jit/serialization/	TorchScript loader
torch/utils/cpp_extension.py	Runtime compile path (treat as eval)
.github/workflows/security-scan.yml (if exists)	CodeQL / dependency scanning