LiteLLM Hacked Twice in 2026: March vs October
Two malicious LiteLLM releases in 2026 came through different doors. A dated comparison, and what an AI app builder can pin, lock and rotate.
Founder, Newly
Published Last updated
LiteLLM, an open-source gateway many AI apps use to reach model providers, shipped malicious releases twice in 2026. In March a stolen PyPI token, traced to a compromised security scanner in CI, published two bad versions. On October 21 version 1.107.0 came from LiteLLM's own release pipeline. Datadog says no link between them is established.
What happened in March, and what happened in October?
| Detail | March 2026 | October 2026 |
|---|---|---|
| Bad versions | 1.82.7 and 1.82.8 | 1.107.0, plus four Docker tags |
| Live window | March 24 from 10:39 UTC. LiteLLM says about 40 minutes; PyPI counts 2 hours 32 minutes from upload to quarantine | October 21. PyPI 11:39 to 13:23 UTC; Docker Hub 11:46 to 14:20 UTC; GHCR 11:46 to 13:51 UTC |
| How it was published | Uploaded straight to PyPI, bypassing the official CI workflow | Through LiteLLM's release workflow, edited to point at a lookalike repository |
| Stated cause | A PyPI token exposed through the Trivy scanner used in CI | Three developer credentials abused; how the attacker entered an exposed internal deployment is not confirmed |
| What it ran | A credential stealer in a .pth startup file | A credential stealer that runs whenever Python starts, plus a second stage |
| Record | GHSA-5mg7-485q-xm76, no CVE assigned | LiteLLM report, last updated October 21 at 20:30 UTC |
The March facts come from LiteLLM's March update, the GitHub advisory and PyPI's incident report, which says the package was downloaded about 119,000 times in its window. The October facts come from LiteLLM's own report, which is a vendor account. At our check on October 24, 2026 its blog showed no later post, and the fix LiteLLM says goes public on October 27 had not appeared.
How did the two attacks actually differ?
In March the weak point was a tool that ran inside the build. The Trivy scanner's GitHub Actions had their version tags rewritten to point at credential-stealing code, which Aqua's advisory records as 76 of 77 tags in one action (CVE-2026-33634). Microsoft's write-up lists what such a job can expose: cloud keys, database strings, SSH keys and pipeline secrets. LiteLLM says the attacker then uploaded to PyPI directly.
In October the report describes people and infrastructure instead. LiteLLM believes the attacker took tokens from the logs of an internal LiteLLM deployment that was open to the internet, a privileged developer credential overrode branch protections, and the production workflow was pointed at a lookalike repository. The official source tag stayed clean, so reading the repository would not have shown the problem. LiteLLM suspects, but has not confirmed, a recently patched vulnerability as the way into that deployment.
What the two share is the target. A gateway sits next to every provider key, so a bad release runs where the secrets are. Datadog lists cloud credentials, developer keys, AI tool tokens and proxy secrets as targets of the October code.
Does either incident reach my app?
Newly builds a real iPhone and Android app with React Native and Expo. The JavaScript bundle on a phone does not include a Python package, so the app itself is not where LiteLLM would run. Look at what sits behind it: a backend, an AI gateway you host, CI, scripts and any laptop that installs packages for the project. Newly lets you download your code or connect your own repository, so the lockfiles are yours to read.
- Search every repository for
litellmin requirements files, lockfiles and Dockerfiles. - For each hit, find the date the version was last installed and compare it with the windows in the table above.
- For containers, find the digest the running image started from. A tag such as
latestis not an answer.
If a host did run a bad version, treat everything it could read as taken, rotate it at each provider and rebuild instead of cleaning. Our pages on the October incident and rotating app secrets cover the steps, and red.run.cloud has a guide to rotating secrets after a breach.
What would have limited the damage each time?
| Control | Helps in March | Helps in October | How to check yours |
|---|---|---|---|
| Lockfile with hashes | Yes, if locked before March 24 | Yes, if locked before October 21 | --require-hashes in your install step |
| Install delay of a few days | Yes, the window was hours | Yes, the window was hours | A cooldown setting in your installer |
| Image pinned by digest | Not the cause | Yes, the Docker tags were moved to the bad image | @sha256: in the image reference |
| Actions pinned to a commit SHA | Yes, tags were rewritten | Not the stated cause | A 40-character hash after each @ in workflow files |
| Short-lived publishing identity | Yes, a long-lived token was the problem | Partly. The report describes workflow and branch rules being overridden | Trusted Publisher set up in the PyPI project settings |
| Gateway kept off the public internet | No | Yes, LiteLLM says an exposed deployment was the route | Try the admin address from outside your network |
Each row rests on vendor documentation. pip's hash-checking mode uses hashes in your requirements file to catch tampering. GitHub advises pinning actions to a commit SHA and a read-only default token. PyPI Trusted Publishers swap a long-lived token for one that expires after 15 minutes. PyPI also reported that 40 to 50 percent of installs in the March window were unpinned, and it recommends dependency cooldowns. The windows here ran from under an hour to a few hours, so a delay of a few days would have skipped both. That last point is our arithmetic.
Reading this table
No single control covers both incidents. The table is a map of which door each control closes, based on the causes the vendors state, and LiteLLM has not confirmed the October entry route.
What should I check in my own project this week?
- List every place that installs LiteLLM, and the exact version and date of the last install.
- Add hashes to the lockfile and move containers from tags to digests.
- Replace version tags in your GitHub workflows with full commit hashes and set the default token to read-only.
- Check whether any gateway admin page answers from outside your network, and whether its logs contain tokens. Our page on an internal AI gateway on the internet walks through it.
- Write down which provider keys a gateway host can read, so rotation takes minutes when the next notice arrives.
The wider list of poisoned packages and actions is in supply-chain attacks on AI and LLM tooling, and the 15-minute app check covers the rest of the app. For the same weeks, the October 2026 security meltdown tracker lists other notices. Back to the security hub.
Where do you stand?
Everything starts as unknown, because an unchecked item is unknown. Move an item to confirmed only when you hold the evidence under it. No scan, ours included, moves a build machine or private container from unknown to confirmed.
Your LiteLLM supply-chain check
- Detected: You found the problem.
- Unknown: Not checked yet, or the check could not tell.
- Confirmed by owner evidence: You checked and kept the proof.
Your answers stay in this browser tab. Nothing is saved or sent.
Frequently asked questions
Were the March and October incidents the same attack?
Nothing published says so. Datadog wrote on October 21, 2026 that no connection between the two compromises had been established at the time of writing. LiteLLM's October report describes a different chain, with exposed deployment logs and a changed release workflow, and says it hardened its release pipeline after March.
Which LiteLLM versions were malicious?
Two in March: 1.82.7 and 1.82.8. One in October: 1.107.0, plus the Docker tags v1.107.0, latest, main-latest and main-stable during the windows LiteLLM lists. LiteLLM says earlier versions and its private Enterprise release were not affected in October.
I upgraded LiteLLM after each incident. Is that enough?
Upgrading removes the package but not what a process already read. If a bad version ran on a host, rotate every secret that host could read, and rebuild the host or image instead of cleaning it in place. LiteLLM's October report says running pip can re-trigger the startup files.
Does pinning my dependencies fully protect me?
No. A pin to an earlier version or a hash keeps a new bad release from arriving on its own. It does not help if you update during the window, if a pinned file was already bad, or if a secret has been exposed through another route. Pinning narrows the chance, and rotation limits the damage.
My app is an Expo app on a phone. Why is this my problem?
The app bundle on the phone does not contain a Python package. The problem is any server, gateway, build machine or script behind the app that installs LiteLLM. Those hold your provider keys, so check them and your lockfiles.
Sources
Each source was opened and checked on October 24, 2026.
- LiteLLM v1.107.0 security incident report, October 21, 2026, LiteLLM
- LiteLLM security update, March 2026, LiteLLM
- GHSA-5mg7-485q-xm76, two LiteLLM versions published with malware, GitHub Advisory Database
- Incident report: LiteLLM/Telnyx supply-chain attacks, April 2, 2026, PyPI blog
- GHSA-69fq-xp46-6x23, Trivy ecosystem supply chain compromise, Aqua Security, GitHub
- Detecting, investigating and defending against the Trivy compromise, Microsoft Security Blog
- LiteLLM supply chain compromise: what you need to know, Datadog Security Labs
- Security hardening for GitHub Actions, GitHub Docs
- Trusted Publishers, PyPI docs
- Secure installs and hash-checking mode, pip documentation