Unpopular opinion: the 2,500 organizations that got wrecked in this supply-chain attack didn’t get burned because they were careless. They got burned because they did what every security checklist told them to do. They added a scanner. They added an AI gateway. They wired both into CI with credentials broad enough to be useful. That is the recommended configuration.
Here’s what’s confirmed so far. In 2026, a supply-chain attack exposed terabytes of credentials from over 2,500 organizations, including major tech firms. The original attack occurred on March 24, 2026, and was carried out by a financially motivated group called TeamPCP. Reporting names two open-source projects in the chain: Trivy, the vulnerability scanner, and LiteLLM, a tool that standardizes calls to AI models. Both are tools you install to reduce risk. Both ended up as the delivery mechanism.
Why this one hits reviewers where it hurts
I test toolkits for a living. My default recommendation for anything AI-adjacent has been the same for two years: put a gateway in front of your model calls, run a scanner in your pipeline, ship faster with fewer surprises. I’ve written versions of that advice more times than I want to count. I still think it’s right. I also think I undersold the cost of being wrong about any single dependency in that stack.
The tools involved here are exactly the kind I score well. They install fast, they slot into existing pipelines with minimal friction, and they solve real problems. That’s what makes them popular, and popularity is what makes them worth compromising. A financially motivated group doesn’t target the tool nobody uses. It targets the one sitting in thousands of CI configurations with a service account attached.
The uncomfortable math of AI gateways
LiteLLM’s job is to sit between your code and every model provider you use, so switching from one to another is a config change instead of a rewrite. To do that, it holds keys. Plural. OpenAI, Anthropic, whatever cloud inference you’re paying for, sometimes a database connection for logging and spend tracking.
That’s the tradeoff nobody puts in the README. You consolidate your credentials into one process to make your architecture cleaner. You also consolidate them into one process to make an attacker’s job cleaner. Every convenience layer in an AI stack is a credential aggregator by design. I have not been weighting that heavily enough in reviews, and this incident is a fair reason to change that.
Scanners have a similar shape. To scan effectively, Trivy-class tools need to read your registries, your images, and often your private repos. Read access across your whole software supply chain is the feature. It’s also the blast radius.
What I’m changing about how I evaluate tools
Not much of this is new advice. It’s advice I’ve been treating as optional and shouldn’t have.
- Credential scope gets its own score. If a tool wants keys for six providers, that’s a finding, not a feature bullet.
- Version pinning is table stakes. Floating tags in CI mean you install whatever was pushed most recently, including things nobody meant to push.
- Egress matters more than I’ve been treating it. A scanner that can reach arbitrary external hosts from inside your pipeline is a scanner that can exfiltrate.
- Rotation cadence over rotation policy. Everyone has a policy. Very few teams could tell you the age of the key their gateway is using right now.
- Maintainer and release-process health counts. How a project handles signing, review, and publishing tells you more about your real risk than its feature list does.
The part where I don’t tell you to rip anything out
I’m not going to pretend the answer is dropping these categories of tooling. Hand-rolling your own model routing is worse. Skipping vulnerability scanning is much worse. The teams that got hit were, in a real sense, the ones doing the work.
What changes is the assumption underneath. A security tool is not a trusted component because of what it’s for. It’s a dependency with unusually high privileges and an unusually attractive user list. Treat it the way you’d treat any third-party service holding your production keys, because that’s what it is.
Terabytes across 2,500-plus organizations is not a story about one bad package. It’s a story about how much access we hand to the things we install to keep us safe, and how rarely anyone audits that number. If your own tooling review has never asked what a scanner could steal, that’s the gap this attack found.
🕒 Published: