Between 25 and 30 December 2022, installing PyTorch nightly on Linux with pip pulled a malicious torchtriton from PyPI instead of the one on the project's own index. PyTorch says PyPI took precedence, and the fake package uploaded system data. Stable releases were not affected.
What happened, per PyTorch
The PyTorch team learned on 30 December 2022 of a malicious dependency uploaded to PyPI under the same name as one they ship on their nightly index. Because pip was resolving the name from PyPI first, the public package won. The post says the malicious binary ran when the triton package was imported, which required explicit code and is not PyTorch's default behavior.
The binary collected system information, environment variables, a handful of files such as /etc/hosts and /etc/passwd, the first 1,000 files in the home directory, and the contents of the SSH folder, then sent it out through encrypted DNS queries. File uploads were limited by size.
Why the install order caused it
A project that publishes a package on its own index while also depending on public PyPI creates two places for one name. The tool has to pick one. PyTorch's post links to the pip discussion that explains the public index takes precedence in that setup. An attacker only needs to register the name on the public index first and give it a higher version.
What PyTorch changed
The team removed torchtriton as a dependency, replaced it with a package named pytorch-triton, registered a dummy package under the old name on PyPI, removed affected nightly packages from its index and asked PyPI security for ownership of the name.
How to defend against the same pattern
- If you use a private or secondary index, claim your internal names on the public one with placeholder packages.
- Configure installs to resolve internal names only from the internal source. Do not rely on the default merge of indexes.
- Pin dependencies with hashes in a lockfile and install from it.
- Review new transitive dependencies when they appear in a lockfile diff.
- Treat nightly and development channels as less trusted than stable ones.
How to check an environment
PyTorch published a short script that looks for the malicious binary under triton/runtime, and advised uninstalling torch, torchvision, torchaudio and torchtriton, purging the pip cache, and reinstalling nightlies newer than 30 December 2022. If you installed in the window, treat the files and keys on that machine as exposed.
Try it yourself
Click through it at your own pace, or open it full screen. Look at where each package comes from and which version was resolved.
Quick check
Were stable PyTorch users affected?
PyTorch states that stable packages were not affected.
How do I stop a public package shadowing an internal one?
Resolve internal names only from the internal source, and claim the same names on the public index with placeholders.
Sources
- PyTorch, Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022.
Last reviewed: 19 October 2026.
