PyTorch nightly builds pulled malicious dependency

The PyTorch compromise was dependency confusion in a high-value machine-learning stack. PyTorch nightly builds depended on torchtriton, an internal package served from PyTorch's own index. PyTorch said PyPI took precedence in the mixed-index install flow, so an attacker could publish the same package name publicly and win resolution.

On December 26, 2022, the attacker published torchtriton 2.0.0 to PyPI. Checkmarx reported that the public package copied the legitimate project and added two changes: a malicious ELF binary under triton/runtime/triton and Python glue in __init__.py to execute it. The package also used starjacking to borrow legitimacy from the real repository.

The binary targeted x64 Linux systems and ran when the triton package was imported. It collected nameserver configuration, hostname, username, working directory, environment variables, /etc/hosts, /etc/passwd, .gitconfig, .ssh, and the first 1,000 files under the user's home directory. Exfiltration went through encrypted DNS queries to *.h4ck.cfd using wheezy.io.

PyTorch removed affected nightly packages, replaced the dependency with pytorch-triton, and registered a dummy PyPI package to prevent the same namespace collision. Stable PyTorch packages were not affected. The incident became a reference case for PyPI dependency confusion against mixed public and project-hosted package indexes.

Motive

Credential Theft

Cause

Malicious Dependency

Transitive

Yes

• Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022pytorch.org
• PyTorch dependency confusion security alertpytorch.org
• Supply Chain Attack on PyTorch - Dependency Confusion via Malicious Packagesblog.checkpoint.com
• PyTorch dependency confusion 2.0blog.sonatype.com
• PyTorch dependency poisoned with malicious codetheregister.com
• PyTorch, a Leading ML Framework, Was Poisoned with Malicious Dependencyzero.checkmarx.com