The LiteLLM Attack: Why Your AI Tools Are Now a Security Target

On March 24, 2026, two versions of a widely used AI software package were published to the Python Package Index carrying code that stole credentials. They were live for roughly forty minutes. That was enough.

The package was LiteLLM, a tool that lets developers connect an application to many different AI models through one interface. It is popular, it is open source, and it is exactly the kind of component that gets installed once and then forgotten about. If your business does not write software, you have probably never heard of it. You should still care about what happened, and we will explain why.

What actually happened

Versions 1.82.7 and 1.82.8 went live on PyPI at 10:39 UTC and were pulled about forty minutes later. In that window, anyone whose build system automatically pulled the latest version installed code designed to harvest secrets.

The malicious payload went looking for environment variables, SSH keys, cloud provider credentials for AWS, Google Cloud and Azure, Kubernetes tokens, and database passwords. It encrypted what it found and sent it out via a POST request to a domain called models.litellm.cloud, which despite the name has nothing to do with the LiteLLM project.

The maintainers responded quickly and publicly. They told users to treat every secret on affected systems as compromised and rotate it, to search their filesystems for a file named litellm_init.pth, to audit version history across environments and build pipelines, and to pin the package to version 1.82.6 or earlier until a verified release was available.

The uncomfortable part: the way in was a security tool

Here is the detail that should give every business owner pause. The compromise appears to have originated in Trivy, a dependency used in LiteLLM's own security scanning workflow. The attackers then bypassed the official build process and uploaded the poisoned packages to PyPI directly.

Read that again. The scanner that was there to catch malicious code became the route through which malicious code arrived.

And it was not a one-off. Researchers tracking the campaign, attributed to a group operating as TeamPCP, followed the same thread from Trivy through npm and Checkmarx and into PyPI. Three days later, on March 27, versions 4.87.1 and 4.87.2 of the Telnyx package were compromised in the same campaign. This was a deliberate, patient effort to poison the tools that developers trust by default.

Why this matters if you do not build software

Most of our clients do not have a development team. They buy software rather than write it. It would be easy to read this story as somebody else's problem.

It is not, for three reasons.

Your vendors build software. The products your business depends on are assembled from thousands of open source components. When one of those components is poisoned, the blast radius includes every company downstream. You do not need to have installed LiteLLM for a supplier's compromise to become your data breach.

AI tools are entering businesses through the side door. Over the past two years, AI tooling has been adopted faster than almost any technology in recent memory, and much of it has arrived without passing through procurement, legal or IT review. Someone signs up with a company card, connects it to a shared drive, and the organization now has a data pathway nobody has assessed. LiteLLM is a reminder that the AI supply chain is young, fast moving, and being actively targeted.

Forty minutes is not a window you can watch. No small business has a team monitoring package registries in real time. Defense against this class of attack is not vigilance. It is architecture: pinned versions, reviewed dependencies, credentials that are scoped narrowly and rotated routinely, and the assumption that a breach somewhere upstream will eventually reach you.

Five things worth doing this quarter

1. Find out what AI tools are actually in use. Not what is approved. What is in use. Ask the question openly and without blame, because people will only tell you if they are not worried about getting into trouble. You cannot secure a tool you do not know exists.

2. Inventory what those tools can reach. An AI assistant connected to your email and file storage has the same access as the person who authorized it. That is the real exposure, not the tool itself.

3. Rotate long-lived credentials, and stop creating new ones. The LiteLLM payload was valuable precisely because the secrets it stole tend to sit unchanged for years. Short-lived, narrowly scoped credentials turn a catastrophic theft into an inconvenient one.

4. Ask your critical vendors how they manage dependencies. You are entitled to ask. Do they pin versions? Do they review what their build pipeline pulls in? How were they affected in March? A vendor who answers clearly is telling you something useful. So is one who cannot.

5. Write down who does what when it happens. Incident response plans get built after the incident far more often than before it. Yours should name the person who decides to take a system offline, the person who contacts customers, and the person who calls the insurer.

The wider point

Supply chain attacks work because trust is efficient. No business could function if it independently verified every component it depends on. Attackers have understood this for years, and they have moved steadily upstream: from targeting companies, to targeting the software companies use, to targeting the tools that build that software.

The answer is not to trust nothing. It is to know what you are trusting, keep the list current, and limit what any single betrayal can cost you.

If you have never taken stock of the software and AI tools running inside your business, that is a good place to start. It is one of the first things we look at in a Secure Start assessment, and it is usually the part where clients learn something that surprises them.