LiteLLM supply chain attack: your scanner shipped the malware

The malicious packages were on PyPI for forty minutes. That was enough. CloudSEK published research this week on a LiteLLM supply chain attack that it estimates reached more than 2,500 organizations and roughly 434,000 CI/CD pipelines — and the part worth sitting with is how it got in. Nobody attacked LiteLLM. They attacked the security scanner LiteLLM's build pipeline installed automatically.

What actually happened

Per CloudSEK's report, the threat actor tracked as TeamPCP compromised Aqua Security's Trivy — a vulnerability scanner — and sat inside it for roughly 20 days. LiteLLM's continuous integration pipeline pulled the poisoned Trivy build on its own, as pipelines do. From there the attackers pushed two tainted LiteLLM releases, versions 1.82.7 and 1.82.8, to PyPI in March 2026. They were live for about 40 minutes before removal, SecurityWeek reports.

The payload used a Python .pth startup hook, so it executed when the interpreter started — not only when an app imported LiteLLM. On CI runners it swept environment variables, cloud credential files, Kubernetes configs, SSH keys, package-publishing credentials, and AI provider API keys. CloudSEK's high-confidence exposure list includes Nvidia, AWS, Cisco, and Salesforce. CloudSEK's own summary of the chain: "one unrevoked token, three tools deep."

Note the dates. The compromise ran in March. The research landed in August. Anyone who ran an affected pipeline had five months of exposure before they had a reason to look.

Why it matters for your business

You probably don't run LiteLLM. You almost certainly run a build pipeline that installs things you did not choose. That's the actual lesson here, and it applies to a five-person shop with one GitHub Action just as cleanly as it applies to Nvidia.

Three things follow. First, your dependency risk is not your requirements.txt — it's the transitive closure of every tool your CI touches, including the security tooling. A scanner is a privileged process with network access and repo credentials. It is not automatically on your side. Second, the exposure window is measured from the compromise, not from disclosure, so "we weren't in the news" is not the same as "we weren't hit." Third, if your pipeline holds long-lived credentials — an AWS key, a PyPI token, an ANTHROPIC_API_KEY in a repo secret — a forty-minute window is plenty.

What we do on client builds: pin dependencies to hashes, scope CI credentials to one job with a short TTL via OIDC instead of stored static keys, and keep an artifact log so "what did we install on March 12" is a query, not an archaeology project. None of that is exotic. It's the difference between rotating four tokens and rebuilding your environment from scratch.

Sources: CloudSEK, SecurityWeek.