A Package Named After a Real One Stole Their SSH Keys
In December 2022 the PyTorch nightly build was compromised for about five days, and the entry point was a name. PyTorch shipped an internal dependency called torchtriton, served from its own package index. An attacker registered a package with the same name on public PyPI, and for anyone who installed the nightly during the window, the resolver preferred the public index and pulled the attacker's build instead. That build shipped a malicious binary that ran when the triton package was imported. It read the machine's environment variables, its nameservers, /etc/passwd, and every file in the user's ~/.ssh directory, then exfiltrated them to an attacker-controlled server. The PyTorch team documented all of it in their compromised nightly dependency writeup.
Read what actually happened there. Nobody exploited a bug in PyTorch's code. Nobody broke authentication. A developer typed pip install, and a name collision decided which of two packages that command trusted. The malicious code then ran before any of the developer's own logic did, because pulling in a dependency means running its code, at install time through a setup script or the first time you import it.
This is the shape of every threat in this lesson. Your LLM application is a thin layer of code you wrote, sitting on a deep stack you did not: base model weights from a hub, the datasets that shaped them, a tokenizer, hundreds of transitive packages, and increasingly a set of third-party tools and servers your agent calls. You trust all of it by default, and each piece is an entry point. The previous lesson controlled what leaves your boundary. This one controls what arrives at it.
You Wrote the Top Box. Everything Under It Runs as You.
Start by looking at the whole stack honestly, because the risk lives in the parts you never think about.
The box at the top is the part you review in pull requests: your prompts, your business logic, your glue. It is a small fraction of what runs in production. Under it sit third-party tools and servers, a package tree of hundreds of transitive dependencies, the model weights and tokenizer, and the datasets behind them. Every one of those layers executes with the same privileges as your top box. The same service account, the same network reach, the same access to your secrets and your GPUs.
That is the property that makes supply chain security its own discipline. A vulnerability three layers down is not somebody else's problem that stays contained to their code. It is your incident, running with your credentials, on your infrastructure. The torchtriton payload did not need any privilege the developer did not already have. It inherited all of it the moment it ran.
So the question for the rest of the lesson is narrow and repeatable. For each layer, where did this come from, what exact bytes am I running, and who vouched for them. When you cannot answer, you are not trusting the artifact. You are hoping.