No, not from an untrusted source. PyTorch's security policy says distributed checkpoints are meant to restore the state of a trusted distributed job from storage you control. The weights_only protection of torch.load does not apply to them, so loading one may execute arbitrary code.
What a distributed checkpoint is
When a training job spans many GPUs, each process holds a shard of the model and optimizer state. PyTorch has a package for saving that state in a coordinated way, called distributed checkpointing. It includes conversion helpers between formats, such as turning a regular saved file into the distributed layout.
These checkpoints are an operational artifact. They exist so your own job can pause and resume.
Why the usual safety option does not help
Many teams learned to pass weights_only when loading a regular checkpoint with torch.load, which restricts what the loader will reconstruct. That helps, with known limits that are covered in separate posts on this blog.
The PyTorch SECURITY file states that for distributed checkpoints the trust model is different. Because the checkpoint is always assumed to come from a trusted source, the weights_only protections of torch.load do not apply there. Loading one, like any other distributed operation, may execute arbitrary code with the privileges of the user running PyTorch. It tells users to load only checkpoints that their own infrastructure produced and stored.
It also says these are not artifacts you download from the internet or accept from untrusted third parties. That includes the format conversion utilities in the checkpoint package.
What to do when someone sends you one
| If the file is | Do this |
|---|---|
| Produced by your own job and stored in your bucket | Load as normal, with write access to that bucket limited |
| From a partner or vendor | Ask for a different export, such as a Safetensors file, and say why |
| From a public link | Do not load it on a machine that holds credentials or data |
| Needed for research on an unknown file | Use an isolated container with no network, no mounted secrets and throwaway storage |
Protect your own checkpoints too
Because the policy trusts your storage, the weak point becomes who can write there.
- Limit write access to the checkpoint location to the training job's identity.
- Keep checkpoints out of buckets that other teams or outside parties can write to.
- Record a hash when a job writes a checkpoint, and check it before resuming from one. A changed hash means stop and investigate.
- Separate training and serving. A serving fleet should load exported, reviewed weights, not raw training checkpoints.
- Keep credentials out of training environments where you can, so a bad load has less to reach.
sha256sum checkpoint_dir/* > checkpoint.sha256
sha256sum -c checkpoint.sha256
Network exposure is the sibling risk
The same policy section warns that distributed features have no authorization and send messages unencrypted, and that anyone with network access to a distributed program could run code as the user running it. So the checkpoint rule and the network isolation rule belong together: trusted files, on a trusted network.
Quick check
Is converting the checkpoint to another format safe?
Not if the conversion itself loads untrusted data. The policy names the conversion utilities as part of the trusted-source assumption, so do any conversion in a sandbox.
Does my cloud storage permission model fix this?
It helps, since the policy assumes storage you control. The key is limiting who can write to it.
Where Safeguard fits
Safeguard offers dependency scanning and policies and gates for your ML code's libraries, and compliance evidence automation to record the controls you run. A free scan is available for repositories.
Sources
- PyTorch SECURITY.md, read 19 October 2026.
Last reviewed: 19 October 2026.
