What the LiteLLM Supply-Chain Breach Reveals About Open Source Risk

In short: On 24 March 2026, two releases of LiteLLM, a widely used open-source AI library, were published to PyPI (1.82.7 and 1.82.8) with credential-stealing code inside. Datasets that surfaced in August showed that roughly 434,000 files collected in this campaign could be linked to close to 2,500 organisations. In this post we cover what is actually verified, the common "it won't happen to us" assumptions, and a concrete supply-chain checklist you can start on this week.

What happened? The verified summary

LiteLLM is a Python library and proxy that lets applications connect to dozens of AI providers through a single interface. According to the project's official security update, the compromised 1.82.7 and 1.82.8 releases were live on PyPI from 10:39 UTC on 24 March 2026 for about 40 minutes before PyPI quarantined them. The malicious code collected environment variables, SSH keys, cloud provider credentials, Kubernetes tokens and database passwords and sent them to the attacker's server.

LiteLLM was not the first link in the chain. The LiteLLM team believes the intrusion started with the Trivy dependency used for security scanning in its CI/CD pipeline. Trivy's GitHub security advisory explains that on 19 March the attacker used compromised credentials to publish a malicious Trivy release and to point 76 of the 77 version tags in the trivy-action repository at credential-stealing code. In other words, a security scanner became the tool for stealing another project's publishing keys.

In August the picture grew. As Help Net Security reported, Hudson Rock found 433,909 files and 118,829 CI runner dumps in a 153 GB archive and attributed them to 2,488 corporate domains. CloudSEK also said its dataset of roughly 434,000 files potentially affected close to 2,500 organisations, while stressing that these figures describe exposure, not confirmed breaches. So saying "434,000 CI/CD pipelines were taken over" is not accurate; the accurate wording is roughly 434,000 stolen files.

The damage a package can do is measured not by its download count, but by where it runs and what it can reach.

Why the "it won't happen to us" assumptions don't hold

"We download from the official source, so we're safe"

The malicious releases were not distributed from a fake site but from LiteLLM's official PyPI package. The source code on GitHub was clean; the problem was in the distributed package and the publishing credential. Any install that did not pin a version (using pip install litellm or litellm>=...) could have picked up the malicious release during those 40 minutes.

"We don't use LiteLLM"

You may not use it directly. LiteLLM's advisory states plainly that the malicious release could also arrive through a transitive dependency or a Docker build. The Trivy case is even more instructive: a tool installed to improve security became the entry point for the attack.

"We changed the passwords, case closed"

According to Trivy's advisory, credentials were rotated after the first disclosure in early March, but the rotation was not atomic: not all credentials were revoked at the same time, and that window of a few days may have been enough for the attacker to keep access. The 19 March attack came through that gap. Independent researcher Kevin Beaumont also wrote that, within the terms of its responsible disclosure policy, he tried the leaked credentials of a large US tech company that had said it "rotated them all", and that almost every one still worked.

"The problem is AI"

Beaumont's summary is clear: this is a massive supply-chain breach caused by poor AI security, but AI itself is not the threat. The real problem is organisations rushing AI into production while their DevOps security lags behind. Everything that was compromised was classic development infrastructure: package publishing tokens, CI secrets and cloud keys.

"It happened once, it's over"

It isn't. On 21 October 2026 LiteLLM was hit a second time: release v1.107.0 was live for about 1 hour 45 minutes on PyPI and about two and a half hours in Docker images. This time the attacker used stolen GitHub CLI OAuth tokens belonging to three engineers. Two incidents in the same project within seven months show that supply-chain risk is not a one-off stroke of bad luck but a permanent business risk.

A supply-chain checklist for businesses

None of the steps below require a large security budget. In custom software and SaaS projects, they are also the cheapest security measures to put in place when they are built in from the start.

1. Pin versions and use a lockfile. Exact versions with == in requirements.txt, poetry.lock or uv.lock for Poetry/uv, and package-lock.json on the Node side should all be committed. A project that uses a lockfile and exact versions will not pick up a newly published malicious release on its own, even if it builds during those 40 minutes.
2. Turn on hash verification. With pip install --require-hashes, the SHA-256 digest of every package is checked; even if the publisher side is compromised, a package that doesn't match the digest in your lockfile is not installed. LiteLLM also published digests of its safe releases after the incident.
3. Pin GitHub Actions to a commit SHA. Tags like @v1 or @0.34.0 can be moved; the Trivy attack exploited exactly that. Trivy's advisory also recommends pinning to the full SHA.
4. Generate an SBOM. A software bill of materials in CycloneDX or SPDX format lets you answer "do we have 1.82.7?" in minutes. A team that doesn't know on the day of an incident spends hours building an inventory.
5. Give CI tokens least privilege. A build job should not see the publishing key, and a test job should not see the cloud admin key. In GitHub, make the permissions: block read-only by default and bind secrets only to the job and environment that need them.
6. Remove long-lived publishing tokens. PyPI's Trusted Publishing lets you publish with a short-lived OIDC identity issued by your CI instead of a permanent API token. If there is no permanent key to steal, the "upload directly with a stolen token" scenario seen with LiteLLM is largely closed off. Sigstore signatures and PyPI attestations also let you verify where a package was built.
7. Make secret rotation a drill. List which secret is used where; rotate and revoke at the same time, and test that the old key really no longer works. The Trivy case showed that a half-finished rotation may be no better than none.
8. Score your dependencies. OpenSSF Scorecard automatically rates an open-source project's practices such as branch protection, signed releases and dependency pinning. It is worth a look before you add a critical dependency.
9. Automate updates, but don't leave them unchecked. Dependabot or Renovate open updates as separate PRs; nothing reaches the main branch without passing tests. Holding new releases for a few days with Renovate's minimumReleaseAge setting can make a 40-minute malicious release window completely irrelevant to you.

So what should you do today?

If your team does AI integration in Python, start with your build logs from 24 March and 21 October: was LiteLLM 1.82.7, 1.82.8 or 1.107.0 installed? If so, treat every secret that environment could reach as leaked, rotate it and revoke the old one. Then apply the first three items on the list above; that is where the biggest gain is.

If you want to set up AI integration on a secure architecture, in our AI integration projects we can design a setup that keeps provider keys out of the build pipeline and runs with least privilege. For the data protection side, see our post on responsible AI and KVKK compliance, and for your site's overall compliance, our data protection checklist. If you are just getting started with AI, our step-by-step integration guide is a good place to begin.