2,500 Companies Got Hit by One Bad Update. Here’s the AI Supply Chain Risk Nobody Is Watching.

In March, a hacking group compromised a widely used open-source AI library called LiteLLM. The malicious packages were live on the public package index for roughly 40 minutes before they were caught. In that 40-minute window, more than 2,500 companies and approximately 434,000 automated build pipelines were potentially exposed, according to research published this week by cybersecurity firm CloudSEK. Nvidia, AWS, Cisco, Salesforce, and Siemens are among the high-confidence matches. None of those companies chose to work with the attackers. Most of them did not even choose LiteLLM directly — it was buried somewhere in a dependency chain nobody was watching closely enough.

What Actually Happened

LiteLLM is an AI gateway library, a piece of infrastructure that sits between applications and the AI models they call, routing requests and managing credentials. It is the kind of tool that gets pulled into a project as a dependency of a dependency, something an engineer adds once and rarely thinks about again. The attackers, a group known as TeamPCP, did not attack LiteLLM directly first. They compromised a security scanner called Trivy that runs inside LiteLLM’s own build pipeline — the tool meant to catch vulnerabilities before code ships. A chain of trust failures starting with that one overlooked credential let the attackers poison the actual LiteLLM package itself.

The malicious version was available for download for about 40 minutes before it was pulled. In software terms, that is nothing. In consequence terms, it was enough time for the poisoned package to get pulled into hundreds of thousands of automated build pipelines running across thousands of companies, silently harvesting credentials during that window. The FBI issued a warning in July that those stolen credentials are still live and usable, meaning the risk did not end when the malicious package was removed. It just went quiet.

Why This Is a Different Kind of Risk Than What We’ve Covered Before

The security stories we have tracked over the past month — the sandbox escape, the Hugging Face breach, the offensive AI models — all involved a specific AI system doing something unexpected. This is different. This is not about an AI model behaving badly. It is about the software supply chain underneath AI infrastructure being just as vulnerable as any other software supply chain, and most companies using AI tools have far less visibility into that layer than they assume.

Modern software is built on dependencies. A single project might pull in dozens or hundreds of open-source libraries, and those libraries pull in their own dependencies, forming a chain that is often several layers deep before anyone traces it back to its source. Most developers, and almost all founders, have no practical way to audit every link in that chain by hand. That is exactly the gap this attack exploited. You do not need to be a target to be exposed. You just need to be using a tool that uses a tool that got compromised.

Why This Matters Even If You Don’t Write Code

If you are a founder who does not personally write code, this might feel like an engineering problem that is not yours to worry about. It is worth understanding anyway, because the exposure here was not really about code — it was about credentials, the keys that let systems talk to each other and access sensitive data. If any part of your business, a contractor’s project, an agency you work with, a SaaS tool you rely on, touches AI infrastructure with a dependency chain that included LiteLLM, there is a real question worth asking rather than assuming it does not apply to you.

The practical version of that question is simple: has anyone on your team, or any vendor you rely on, checked whether they are affected, and have credentials been rotated as a precaution regardless of confirmed compromise. CloudSEK published a list of affected organizations specifically so companies could check their own exposure. That list is worth five minutes of anyone’s time who has any AI infrastructure running through open-source tooling, which by now is most businesses using AI in any serious way.

The Actual Lesson Here

This is not a reason to distrust open-source AI tools broadly. Open-source infrastructure underlies nearly everything in modern software, AI or otherwise, and the transparency of open-source code is often what allows vulnerabilities like this to be found and disclosed at all. The lesson is narrower and more practical: credential hygiene and dependency awareness are not optional anymore, even for businesses that think of themselves as far removed from anything technical.

If you have never asked your development team, agency, or technical contractors a simple question — what happens if one of our dependencies gets compromised, and how would we even know — this week is a good week to ask it. Not out of alarm. Out of the same basic due diligence you would apply to any other vendor holding access to something sensitive in your business.

---

If you want to think through where the same kind of blind spot might exist in your own AI-powered workflows, this is worth revisiting: An OpenAI Model Escaped Its Own Sandbox. Here’s Why Founders Should Care.