Image: Unsplash.
Use this if your team runs LiteLLM anywhere: as the proxy in front of your model providers, as a Python library inside an app, or as something an agent framework pulled in without asking. The poisoned releases were up for under an hour on one day in March. That's short, but a stolen cloud key doesn't expire on its own, so the question isn't whether the window closed. It's whether anything of yours installed from it.
What happened, briefly
On March 19, 2026, attackers used credentials kept after an incomplete rotation to publish a malicious Trivy 0.69.4 release and to repoint 76 of 77 version tags in aquasecurity/trivy-action and all seven in aquasecurity/setup-trivy, according to the NVD record for CVE-2026-33634. Google tracks the group, TeamPCP, as UNC6780.
On March 24, LiteLLM 1.82.7 and 1.82.8 appeared on PyPI. LiteLLM's incident report says they were live from 10:39 UTC for about 40 minutes before PyPI quarantined them, and that it believes the compromise came from the Trivy dependency in its CI/CD scanning workflow. The payload hunted for environment variables, SSH keys, cloud credentials, Kubernetes tokens and database passwords, and sent them to models.litellm.cloud, a domain LiteLLM doesn't own. Version 1.82.8 added a litellm_init.pth file that Python runs at startup, so it fired whether or not your code imported LiteLLM.
Screenshot: "Security Update: Suspected Supply Chain Incident", LiteLLM, March 24, 2026.
How the token reached the attackers is still told three ways. LiteLLM's report says the attacker bypassed its official CI/CD and uploaded straight to PyPI; CloudSEK says the poisoned build published the releases; PyPA's advisory describes a token exposed through Trivy and then used to upload, The Hacker News reported. For your audit it doesn't matter. The packages were real LiteLLM version numbers on the real index.
The best-known victim is Mercor, the $10 billion AI training data startup, which admitted a breach on March 31. A hacker group claimed 4TB of its data, which Mercor never confirmed, Meta paused its contracts, and five contractors sued, one of them naming LiteLLM and the startup that handled LiteLLM's security certifications as defendants, TechCrunch reported. Mercor's own June 25 update says only "a very limited subset" of its nearly five million experts had sensitive information affected.
In August, CloudSEK published a lookup built from roughly 434,000 captured files that maps potential exposure to more than 2,500 organizations. Treat that as a list to check, not a victim count: CloudSEK says so itself, and SecurityWeek later added SOCRadar's finding that most of those organizations were likely hit earlier, through Trivy.
Aikido Security's Bad Dependencies podcast walked through the chain from Trivy to LiteLLM on March 30:
The steps, in order
1. Find every LiteLLM install and its version. Run pip show litellm on every service and runner that has it, and search lockfiles and Dockerfiles for 1.82.7 or 1.82.8. Don't stop at the services you know about. LiteLLM's own list of who may be affected includes anyone who got it as a transitive, unpinned dependency through an agent framework, an MCP server or an orchestration tool.
Screenshot: "Who is affected", LiteLLM security update.
2. Decide whether you're in the window. LiteLLM treats any pip install or upgrade on March 24 between 10:39 and 16:00 UTC as suspect, plus Docker images you built yourself that day with an unpinned pip install litellm. You're out of scope if you only ran the official ghcr.io/berriai/litellm image, used LiteLLM Cloud, stayed on 1.82.6 or earlier, or installed from the GitHub source.
3. Look for the indicators. A litellm_init.pth file in site-packages, and any outbound traffic to models.litellm[.]cloud or checkmarx[.]zone. If you find the file, LiteLLM's advice is to remove it, investigate the host, and keep the artifacts if someone is doing forensics.
4. Check your own CI for Trivy and the campaign's traces. Search workflow files for aquasecurity/trivy-action and aquasecurity/setup-trivy referenced by a tag rather than a commit SHA, and note whether they ran around March 19. Then search your GitHub organization for repositories named tpcp-docs or docs-tpcp, which the FBI lists as indicators; Aqua notes they may carry a tpcp-docs- prefix, so an exact-name search can miss them.
5. Pull provider usage logs, then rotate. Export API usage and billing from each model provider and cloud account the host could reach before you revoke anything, so you can see what a stolen key was used for. Then rotate every secret LiteLLM lists: API keys, cloud access keys, database passwords, SSH keys, Kubernetes tokens, and anything in environment variables or config files. The FBI's July 2 advisory, FLASH-20260702-01, warned that affiliated actors are likely to use these credentials long after the compromise, which is why we'd rotate now even if March feels like old news.
6. Move to a supported release line. LiteLLM said its first clean release after the incident was 1.83.0, built by a new CI/CD pipeline. Since June 29, 2026 it actively supports only the four most recent stable minor lines, with a new line about every week. An install frozen in the spring is past end of life and missing later fixes: CVE-2026-42208, a SQL injection in the proxy's key check (affected 1.81.16 through 1.83.6, fixed in 1.83.7), and CVE-2026-42271, which CISA added to its KEV catalog on June 8 and which has been chained with the Starlette flaw CVE-2026-48710. Our LiteLLM KEV patch guide covers those.
Screenshot: "LiteLLM version support: focusing on the four most recent stable lines", LiteLLM, June 20, 2026.
7. Pin what you install, and verify it. The exposed installs were the unpinned ones: pip install litellm resolved to whatever was newest that hour. Pin exact versions in a lockfile with hashes, pin GitHub Actions to commit SHAs instead of tags, and verify LiteLLM's Docker images, which it signs with cosign from 1.83.0-nightly onward.
A r/Python thread opened the day after the attack, asking how people protect themselves from this. u/atomicant89 put the trade-off plainly: "If you don't pin them, you leave yourself vulnerable to attacks like this, but if you do, you leave yourself vulnerable to vulnerabilities that are fixed in later versions." The most upvoted answer, from u/Sufficient-Rent6078, was a cooldown: uv can skip packages "that are too bleeding edge (e.g. everything that is out there for less than a week.)" We'd take both: pin, and only move a pin to a release that's been out for a few days.
https://www.reddit.com/r/Python/comments/1s3gjdy/protection_against_attacks_like_what_happened/
8. Put the gateway on your vendor register with an owner. An open-source gateway you host isn't a vendor with a DPA, so it tends to fall out of vendor reviews. Give it a row anyway: version line, who tracks its advisories, and when it was last upgraded.
What to log and keep
Write down, per system: the LiteLLM version found and where, whether it fell inside the March 24 window, which indicators you checked and what you found, every secret rotated and when, and the provider logs you exported. If personal data was reachable with a stolen key, add the date you became aware and your notification decision. Under GDPR Article 33 the controller notifies the supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it", unless the breach is unlikely to result in a risk to people. That log is what you'd hand a regulator, an insurer or a customer who asks.
For the wider vendor process, see the AI supply chain security checklist and the AI vendor due diligence checklist.
What we could not confirm
We read LiteLLM's incident report, its version-support and security posts, the NVD record, CISA's KEV data, Mercor's update, and reporting by The Hacker News, SecurityWeek, TechCrunch and Cybernews. We didn't read CloudSEK's report, PyPA's advisory or the FBI's FLASH advisory directly; those details come from The Hacker News. We couldn't find a source for the earlier version's counts of affected domains and monthly downloads (TechCrunch says only that LiteLLM is "downloaded millions of times a day"), so they're gone.
Correction, October 15, 2026: the August version called the CVE-2026-42271 and Starlette CVE-2026-48710 chain a CVSS 10.0 flaw added to CISA's KEV catalog on June 8. CVE-2026-42271 alone was added that day and scores 8.8 (CVSS v3.1); the Starlette flaw was added on September 2. A second check the same day found more errors: the exposure window was March 24 only (10:39 to 16:00 UTC by LiteLLM's guidance), not March 24 to 26; Mercor's 4TB loss is a hacker group's claim Mercor never confirmed; the five contractor lawsuits weren't reported as federal suits filed in one week, and one of them named LiteLLM as a defendant; the counts of contractors' identity documents exposed, affected domains and monthly downloads had no source; CVE-2026-42208 was fixed in 1.83.7, not 1.83.10; and the GDPR clock runs from becoming aware of a breach, not from a breach being "likely".
Related Reading
- LiteLLM 1.107.0 compromised: the October release and the keys to rotate
- CISA's KEV List Adds LiteLLM Flaw: Patch by September 16
- AI Agent Data Controls Register: A Free Template
- AI Supply Chain Security Checklist 2026
- AI Vendor Due Diligence Checklist 2026
- Vetting AI Tools for Fake Malware and Typosquatting
- JadePuffer Ransomware: 8 Gaps in Your AI Vendor Security Checklist
- MCP Server Security Governance Checklist 2026
- AI Agent API Token Leak: 24-Hour Incident Response Playbook
- OpenCode Security Breach: What to Do With Your API Keys
- ConnectWise Cloud Backup breach: what to check in Microsoft 365
