Compromised PyTorch Dependency Chain (torchtriton)

What happened

Catalogued by MITRE ATLAS as AML.CS0015, PyTorch’s pre-release nightly builds were compromised from December 25–30, 2022 via a dependency-confusion attack. A malicious package named torchtriton was uploaded to public PyPI, and because PyPI took precedence over PyTorch’s intended private index, installs of PyTorch-nightly pulled the attacker’s package instead. On install, its bundled binary exfiltrated system information, environment variables, /etc data, and SSH keys to a remote host.

It’s a foundational example that the ML software supply chain is a first-class attack surface: the model code was fine, but the dependency resolution delivered malware to anyone installing the framework during the window.

Why it maps to ATLAS

• AML.T0010.001 — AI Supply Chain Compromise: AI Software: a core ML framework dependency was subverted.
• AML.T0037 — Data from Local System: the payload collected local system data and secrets.
• AML.T0025 — Exfiltration via Cyber Means: the collected data was sent to a remote server.

Detection notes

Dependency confusion is preventable: pin package indexes, reserve/namespace internal package names on public registries, and hash-pin ML framework dependencies. Sandbox build and dev environments and restrict install-time egress — a package that reads ~/.ssh or phones home during installation should never be normal.

Detection

Log sources

• Package install source (PyPI vs private index) audit
• Endpoint telemetry on ML build/dev hosts
• Egress from install/post-install scripts

Signals

• A dependency resolving from public PyPI over the intended private index
• Post-install binary reading /etc, env vars, or ~/.ssh
• Outbound connections during package installation

Mitigations

• Prevent dependency confusion: pin indexes, namespace/reserve internal names
• Vet and hash-pin ML framework dependencies; monitor install scripts
• Sandbox build/dev environments; restrict install-time egress