PyTorch torchtriton Supply Chain Attack 2022: How Dependency Confusion Stole SSH Keys from Nightly Users

On 31 December 2022, the PyTorch team warned that anyone who installed the PyTorch-nightly build on Linux through pip between 25 and 30 December 2022 had pulled in a malicious package. Someone had registered the name torchtriton, a dependency PyTorch shipped from its own nightly index, on the public Python Package Index (PyPI). Because pip preferred the PyPI copy, users got the impostor. Its binary collected environment variables, the user's .gitconfig, the contents of ~/.ssh and the first 1,000 files in the home directory, and sent them out through encrypted DNS queries. CSO Online, citing Snyk's tracking, put downloads at 2,717 over the period. PyTorch renamed the dependency to pytorch-triton, registered a placeholder on PyPI and told users to uninstall and purge their caches. Stable PyTorch releases were not affected. The person behind the domain later said it was research and that the data had been deleted, which has not been independently confirmed.

At a glance

What happened

PyTorch publishes nightly builds of its machine learning framework from its own package index. In late 2022 those builds depended on a package called torchtriton, also served from that index. CSO Online reports that until 25 December no package of that name existed on PyPI. Then one appeared. "Since the PyPI index takes precedence, this malicious package was being installed instead of the version from our official repository," PyTorch explained in its advisory. "This design enables somebody to register a package by the same name as one that exists in a third party index, and pip will install their version by default."

The impostor package carried a binary that ran when the triton package was imported. According to PyTorch, it collected the nameservers from /etc/resolv.conf, the hostname, username, current working directory and environment variables. It read /etc/hosts, /etc/passwd, the first 1,000 files in the user's home directory, $HOME/.gitconfig and everything in $HOME/.ssh, limited to files under 99,999 bytes. It uploaded the data through encrypted DNS queries to subdomains of h4ck[.]cfd, using the DNS server wheezy[.]io. BleepingComputer, analysing the sample, said it also read the user's bash history.

PyTorch's instruction was blunt: "If you installed PyTorch-nightly on Linux via pip between December 25, 2022 and December 30, 2022, please uninstall it and torchtriton immediately". It replaced the dependency with pytorch-triton, registered a dummy package on PyPI so the trick could not be repeated, pulled the affected nightly packages from its download server and asked PyPI to take over the torchtriton name. BleepingComputer reported more than 2,300 downloads of the malicious package in the preceding week; CSO Online cited Snyk's figure of 2,717, with 2,500 on 26 December alone.

The domain's owner then claimed good intentions. In a statement BleepingComputer published, they wrote: "Note that this was not intended to be malicious!" and "At the same time I want to assure that it was not my intention to steal someone's secrets." They said they had reported the issue to Facebook on 29 December and deleted all the data received. BleepingComputer noted the domain had been registered on 21 December 2022, and CSO Online observed that taking home directory files, SSH keys and Git configuration went beyond what testing for dependency confusion would need.

Timeline

How it happened: the identity attack path

1. Name squatted on the public index. The attacker registered torchtriton on PyPI, a name PyTorch used only on its own nightly index.
2. Resolver picks the impostor. When users installed PyTorch-nightly with pip, the PyPI package took precedence and the malicious version was installed.
3. Code runs on import. Importing triton ran the binary inside the developer's or build machine's environment.
4. Credentials collected. The binary gathered environment variables, Git configuration, SSH keys and other files that commonly hold machine credentials.
5. Exfiltration over DNS. The data left as encrypted DNS queries to an attacker-controlled domain, a channel many networks do not inspect.

Impact

• Confirmed: a malicious package was installed by PyTorch-nightly users on Linux for five days and exfiltrated system data and files, including SSH keys, from machines that imported it.
• Scale: 2,717 downloads according to Snyk's tracking cited by CSO Online; how many machines actually ran the binary is not known.
• Claimed: the uploader says the package was research and that the collected data was deleted; this has not been independently verified.
• Potential: stolen SSH keys, Git credentials and secrets in environment variables could give access to source repositories, servers and cloud accounts until rotated.

What this means for NHI governance

The package targeted exactly the places where developer machines keep non-human credentials: SSH private keys, Git configuration and environment variables that often hold API keys and cloud tokens. Each of those credentials belongs to a machine or automated workflow as much as to a person, and none of them expire on their own. Anyone who installed the impostor had to assume their keys were gone and rotate them, whatever the uploader said about deleting the data.

The wider lesson is that package resolution is part of the identity attack surface. When a private or project-specific index sits alongside a public one, whoever controls the public name controls what gets installed. Pinning dependencies with hashes, reserving internal names on public registries, keeping long-lived keys off developer laptops and isolating build environments all reduce the damage. The same pattern runs through the Ultralytics PyPI compromise and the LiteLLM PyPI package breach. Our AI Supply Chain and AI-BOM Guide and SSH Key Management Guide cover the controls.

Recommendations

• Rotate SSH keys and secrets on any affected machine. Treat every key in ~/.ssh, every token in Git configuration and every secret in environment variables as stolen. See the Leaked Credential Response Playbook.
• Reserve internal package names on public registries. Register placeholders for names you serve from private or project indexes, as PyTorch did after the attack.
• Pin dependencies by hash and control index order. Use lock files with hashes and configure package managers so a public index cannot override a private one. See our AI Supply Chain and AI-BOM Guide.
• Keep long-lived credentials off developer machines. Use short-lived SSH certificates and brokered cloud credentials rather than static keys in home directories. See our SSH Key Management Guide.
• Isolate builds and experiments that install nightly packages. Run them in containers or sandboxes with no access to personal keys or production secrets. See our Secrets Management Guide.
• Monitor DNS for exfiltration. Long, encoded subdomain queries to newly registered domains are a common exfiltration signal.

Frequently asked questions

What was the PyTorch torchtriton attack?

Between 25 and 30 December 2022, a malicious package named torchtriton on PyPI was installed with the PyTorch-nightly build on Linux in place of PyTorch's own dependency. It stole system information, environment variables, SSH keys and Git configuration and sent them out over DNS.

Was stable PyTorch affected by the torchtriton compromise?

No. PyTorch said users of its stable packages were not affected. Only users who installed PyTorch-nightly on Linux via pip during the five-day window received the malicious dependency.

What is dependency confusion?

Dependency confusion happens when a package manager can see the same package name in a private or project index and a public registry, and installs the public one. An attacker who registers the name publicly can get their code installed in place of the real dependency.

Related NHI Mgmt Group resources

Ultralytics PyPI Compromise 2024 · LiteLLM PyPI Package Breach · Codecov Breach 2021 · AI Supply Chain and AI-BOM Guide · SSH Key Management Guide

How NHI Mgmt Group can help

Developer and data science machines often hold more long-lived credentials than production servers. We help teams find those keys, replace them with short-lived credentials and plan rotation for the day a dependency turns hostile. See our NHI and AI agent security training.

References

• PyTorch: Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022 (31 December 2022)
• BleepingComputer: PyTorch discloses malicious dependency chain compromise over holidays (1 January 2023)
• CSO Online: PyTorch suffers supply chain attack via dependency confusion (3 January 2023)