PyTorch's policy puts the burden of safe use on you. It says running untrusted models is equivalent to running untrusted code, and that topics under its Using PyTorch Securely section are not considered vulnerabilities of PyTorch. Crashes, resource exhaustion and malformed objects are filed as regular bugs.
Why this matters for your risk assessments
When an advisory mentions a deep learning framework, teams often assume the maintainers will ship a fix and the risk will go away. For many model loading issues, the policy says otherwise. The framework offers tools, such as weights_only loading, and it expects you to choose safe inputs and environments.
Knowing where the line is helps you decide what you must fix yourself.
What the policy says
Based on the published security document:
- Untrusted models. Running untrusted models is equivalent to running untrusted code. Prefer a secure, isolated environment such as a sandbox.
- torch.load. It has a significantly larger attack surface but is more flexible about what it can serialize, so prefer safer formats when sharing and loading weights.
- weights_only. With it set, the policy says deserialization itself will not allow remote code execution or out-of-bounds access. It does not guarantee the usability of the resulting objects. For distributed checkpoints, the protections of torch.load do not apply.
- What is not a vulnerability. The policy says none of the topics under Using PyTorch Securely count as vulnerabilities of PyTorch. It lists crashes and out-of-bounds access from invalid inputs, numerical accuracy issues, internal or unsafe functions, denial of service through resource consumption, local cache trust and malformed deserialized objects as regular bugs.
What you take from it
| Policy statement | Your action |
|---|---|
| Untrusted model equals untrusted code | Sandbox the first load, no credentials |
| Prefer safer formats | Use safetensors where offered |
| weights_only limits deserialization risk | Set it explicitly in every load |
| Distributed checkpoints are outside torch.load protections | Load them only from sources you control |
| Resource exhaustion is a regular bug | Set memory and time limits on inference jobs |
| Local cache trust is not a vulnerability | Protect the cache directory's permissions |
Cache and file permissions
The note about local cache trust is easy to skip. If another user or process can write to the folder where your model files are cached, they can change what your code loads. Keep that directory owned by the service account and read only to others.
ls -ld ~/.cache
Check who owns the cache on shared machines.
Update your own policy to match
A short internal rule set follows from this document: sandbox unknown models, explicit weights_only, safer formats first, limits on resources, and an owner for each model. Compare with our pre-import checklist.
Where Safeguard fits
Framework releases still matter. Safeguard offers SBOM and dependency scanning, with reachability analysis, to track which versions you run and which findings apply. A free scan is available at gold.safeguard.sh/scan.
Quick check
If PyTorch does not call it a vulnerability, can I ignore it?
No. It means the fix is on your side: safer inputs, isolation and limits.
Is weights_only enough for distributed checkpoints?
The policy says its protections do not apply there, so only load such checkpoints from sources you control.
Sources
Last reviewed: 19 October 2026.
