Twenty-five hundred organizations. That’s the count of confirmed victims in a supply-chain attack that dumped terabytes of credentials belonging to some of the world’s biggest and most sensitive organizations onto the open internet. Not 2,500 individual developers who fell for a phishing email. Twenty-five hundred organizations, major tech firms included, all compromised through the same door.
The attack started on March 24, 2026. The reporting surfaced publicly months later, in August. Do the math on that gap and you get a sense of how long credentials can sit in someone else’s hands before anyone tells you.
What Actually Happened
A financially motivated hacking group called TeamPCP compromised an open-source tool that sat inside thousands of build pipelines. From there, they used that access to reach sensitive data across the organizations that trusted it. The credentials were later leaked in bulk.
Worth flagging, because I’d rather be accurate than tidy: the public reporting on this incident names two different open-source tools. One account points to Trivy, the vulnerability scanner that a very large number of teams run in CI to check container images and dependencies. Ars Technica’s coverage points to LiteLLM, the open-source tool that sits between applications and AI model providers. I’m not going to pretend I can resolve that from where I sit. What I can tell you is that both of those tools occupy the same structural position in a modern stack: quiet infrastructure with broad access, wired into automated pipelines, holding or passing credentials, and almost never reviewed after the day it was installed.
That’s the part that should bother you regardless of which name ends up on the incident report.
The AI Tooling Angle Nobody Wants
This site exists to review AI tools and agents, so let me be direct about what this incident says about that category.
The AI tooling stack is assembled almost entirely out of young open-source projects. Model proxies, orchestration frameworks, vector database clients, agent runtimes, evaluation harnesses, scanners bolted on to satisfy a compliance checkbox. Most of these projects went from a weekend experiment to production dependency in eighteen months or less. Many are maintained by a handful of people. Nearly all of them require credentials to do their job, which is the whole point of a proxy or a scanner. You hand it keys so it can act on your behalf.
Now stack the agent layer on top. An agent framework needs API keys for the models, tokens for the repositories it edits, credentials for the services it calls, and often cloud permissions broad enough to be useful. Teams grant those permissions generously because scoping them tightly is tedious and the demo works either way. The tool becomes a single point that holds every secret the agent might need.
Compromise that point and you don’t get one organization’s keys. You get everyone’s.
Why the Usual Advice Falls Short
The standard response to a supply-chain incident is a list: pin your versions, verify signatures, scan your dependencies, rotate your secrets. All fine. All worth doing. None of it addresses the specific failure here, which is that the thing doing the scanning was itself the problem.
Security tooling gets an unusual amount of trust. It’s the code you install to feel safer, which makes it the last code anyone audits. It runs early in the pipeline, often with elevated permissions, and its output is a green checkmark that ends the conversation. A scanner that reports clean is a scanner nobody looks at.
Same for a model proxy. It works, latency is acceptable, the bill arrives, nobody opens the source.
What I’d Actually Change
- Scope credentials to the task, not the tool. If a scanner needs registry read access, give it registry read access. Not a token that also touches production.
- Treat every AI tool that holds keys as a critical dependency. That means version pinning, change review, and an actual owner, the same treatment your database driver gets.
- Assume rotation will be needed and make it cheap. The organizations that suffered least here are the ones who could invalidate everything in an afternoon.
- Keep an inventory of what has your secrets. Most teams cannot answer that question in under a day. Five months of undetected access is what that costs.
The Uncomfortable Part
I review these tools. I recommend some of them. The honest position is that solid engineering and thoughtful design tell you nothing about whether a project’s release pipeline can be hijacked. A well-built tool with a compromised distribution channel is worse than a mediocre one, because you deployed it more widely.
So the review criteria have to change. Not just does this tool work, but what does it hold, who ships it, and how fast could I cut it off. I’ll be asking those questions going forward. Ask them about whatever you installed last week, before someone else does it for you.
🕒 Published: