TL;DR: In March 2026, the group TeamPCP hijacked the CI pipeline of Trivy, a widely used container scanner, then used stolen credentials to publish two malicious LiteLLM releases to PyPI (CVE-2026-33634). AI training startup Mercor lost 4TB of contractor data as a result, drawing 5 lawsuits and a Meta work stoppage. In August, CloudSEK revealed the blast radius reaches roughly 2,488 organizations. If your stack touches LiteLLM, run this 7-point audit now.
If your team routes requests to OpenAI, Anthropic, or any other model provider through an open-source gateway, there is a good chance that gateway is LiteLLM. It ships from BerriAI, it is downloaded roughly 95 million times a month, and for most teams it sits quietly in the background doing exactly what it is supposed to do: standardize API calls, handle failover, and track spend across providers.
In March 2026, that quiet infrastructure became the entry point for one of the more consequential AI supply chain attacks disclosed this year. A hacking group tracked as TeamPCP did not attack LiteLLM directly. It attacked the tool LiteLLM's own build pipeline trusted, and used that foothold to poison two LiteLLM releases that anyone, anywhere, could install with a single pip install.
Five months later, in August, security researchers published a new estimate of how far the damage reached: roughly 2,488 organizations. If your team has ever run LiteLLM, self-hosted or otherwise, this is worth twenty minutes of your time today.
What actually happened, in order
The attack did not start with LiteLLM. It started with Trivy, an open-source container and dependency scanner made by Aqua Security that gets installed automatically inside countless CI pipelines, including LiteLLM's own.
March 19, 2026: TeamPCP, tracked by Google as UNC6780, retained access to Trivy's GitHub infrastructure after an earlier, incomplete credential rotation. The group force-pushed malicious commits to 76 of 77 trivy-action version tags and all seven setup-trivy tags, and published a malicious Trivy 0.69.4 release. Any CI job that referenced Trivy by a mutable tag, rather than a pinned commit hash, pulled the tampered version automatically.
Shortly after: Because LiteLLM's own build pipeline installed Trivy as part of routine scanning, the compromised action gave TeamPCP read access to the runner environment, including LiteLLM's PyPI publishing token.
March 24, 2026: Using that stolen token, TeamPCP published two malicious LiteLLM releases, versions 1.82.7 and 1.82.8, to the Python Package Index. The packages carried credential-stealing code capable of harvesting cloud keys, SSH keys, Kubernetes tokens, and database passwords from any system that installed them. They sat live on PyPI for roughly 40 minutes before removal, which was long enough for automated build systems around the world to pull them.
March 26, 2026: CISA added the compromise to its Known Exploited Vulnerabilities catalog as CVE-2026-33634.
March 31, 2026: Mercor, a $10 billion AI training data startup that supplies vetted contractors to OpenAI, Anthropic, and Meta, confirmed a breach traced to the LiteLLM compromise. Attackers made off with roughly 4 terabytes of data, including source code and identity documents for more than 40,000 contractors: Social Security numbers, passport scans, W-9 tax forms, and recorded AI interview videos. Meta paused all work with Mercor indefinitely. Contractors filed five federal lawsuits against Mercor in a single week, each alleging the company failed to protect the data it collected from them.
August 12, 2026: Threat intelligence firm CloudSEK published an analysis of roughly 434,000 CI/CD files the attackers captured during the campaign, and mapped potential exposure to approximately 2,488 corporate domains, a figure other outlets rounded to "more than 2,500 organizations." The Hacker News reported a more conservative estimate of 2,100-plus. Either way, Mercor was the highest-profile casualty, not the only one.
Why this matters even if you have never heard of Mercor
Most AI vendor risk conversations start and end with the SaaS layer: which model provider do we use, do they train on our data, do they have a DPA. That conversation misses an entire category of risk that small teams building on AI increasingly carry themselves, the open-source infrastructure sitting between the application and the model provider.
LiteLLM is exactly that category. Teams adopt it because it is free, well-documented, and solves a real problem: routing calls across OpenAI, Anthropic, Gemini, and self-hosted models through one interface, with built-in retry logic and spend tracking. It is the kind of dependency a two-person engineering team adds in an afternoon and then stops thinking about.
That is precisely the profile TeamPCP exploited. Nobody had to trick a person into clicking a phishing link. Nobody had to guess a password. The attackers compromised a scanning tool that almost no one audits, rode it into a build pipeline that almost no one audits either, and came out the other side controlling a package that tens of thousands of teams install without a second thought.
If your team's CI pipeline referenced the compromised Trivy action by a floating tag rather than a pinned SHA, or if anything in your stack installed LiteLLM between March 24 and March 26, 2026, you were exposed to the same credential-harvesting payload Mercor was.
The 7-point audit
Run through this list today. Each step takes a few minutes.
1. Check what version you actually have installed. Run pip show litellm on every service that imports it, and grep requirements.txt, poetry.lock, Pipfile.lock, and any Dockerfiles for a pinned litellm==1.82.7 or litellm==1.82.8. Check container image layers too, since a poisoned dependency baked into an image months ago can persist long after your source repo was updated.
2. Check your CI for the compromised Trivy action. Search every GitHub Actions workflow file for aquasecurity/trivy-action or aquasecurity/setup-trivy. If any reference uses a mutable tag (@master, @v0.29) instead of a pinned commit SHA, and that workflow ran between mid and late March 2026, treat every secret available to that workflow as potentially exposed.
3. Rotate every credential the affected pipeline could reach. This means cloud provider keys, SSH keys, Kubernetes service account tokens, database passwords, and every LLM provider API key the LiteLLM proxy was configured with. Do not rotate selectively based on what you think was accessed; the malicious releases were built to harvest broadly.
4. Pull usage logs before you rotate anything. Export API usage and billing history from every LLM provider for the affected window. Unexpected spend or requests from unfamiliar IP ranges are your fastest signal of what an attacker actually did with a stolen key, versus what they merely could have done.
5. Upgrade to a currently supported release line. LiteLLM ships new stable releases roughly weekly and, since June 2026, actively patches only the four most recent minor versions. An install frozen at an old version is not just missing the March fix, it is also exposed to later disclosures: CVE-2026-42208 (SQL injection in the proxy's API key verification, fixed in 1.83.10), CVE-2026-30623 (command injection via the MCP stdio transport, fixed in 1.83.7), and the chained CVE-2026-42271 plus CVE-2026-48710, an unauthenticated remote code execution flaw rated CVSS 10.0 that CISA added to its KEV catalog on June 8, 2026.
6. Pin dependencies by hash, not just version. A version pin like litellm==1.82.7 did nothing to stop this attack, because the attacker published that exact version number under a legitimate-looking release. Hash-pinning in your lockfile, combined with a private package mirror or proxy that only serves versions you have explicitly reviewed, would have blocked it.
7. Add open-source AI infrastructure to your vendor risk policy explicitly. Most AI acceptable-use and vendor-approval checklists ask about SaaS providers: model vendors, data processors, subprocessors. Add a line item for self-hosted, open-source AI infrastructure your team runs itself, gateways, orchestration tools, vector databases, and specify who owns patch tracking and CVE monitoring for each one.
Your breach notification clock does not care whose fault it was
If your team processes personal data through a pipeline that included a compromised LiteLLM install, and that data was reachable by a credential the attackers could have harvested, your breach notification obligations do not wait for you to finish assigning blame between Trivy, TeamPCP, or LiteLLM's maintainers. Under GDPR Article 33, the 72-hour clock starts at the moment you become aware a breach is likely, not at the moment you confirm exactly what was taken. Most US state breach notification statutes tie their own trigger to discovery in the same way, not to attribution.
This is the practical reason "we use a well-known open-source tool" does not hold up as a defense with regulators or with plaintiffs' attorneys. Mercor's five lawsuits were not filed against TeamPCP or against LiteLLM's maintainers. They were filed against Mercor, because Mercor held a direct duty to the contractors whose data it collected, regardless of how many layers of open-source infrastructure sat between that data and the eventual attacker. The same logic applies to any small team running its own AI stack. Your customers' and your employees' data protection expectations attach to you, the company they gave data to, not to your dependency tree.
That is the real reason to treat the audit above as more than a one-off security exercise. It is the evidence you would need to produce if a regulator, an insurer, or a plaintiff's attorney later asked what you knew, when you knew it, and what you did about it once you found out.
The structural lesson for AI governance
The Mercor breach reads, on the surface, like a story about one company's bad month. It is really a story about where AI vendor risk actually lives now. A small team can run a careful review of its model provider's data handling, sign a solid DPA, and still be fully exposed, because the exposure was never in the model provider relationship. It was three layers down, in a container scanner that neither the team nor its AI vendor directly controls.
That is a hard problem to solve with a vendor questionnaire. It is a more tractable problem to solve with process: know what open-source infrastructure sits in your AI stack, pin it, patch it on a schedule, and assign an owner. Most small teams have this discipline for their primary application dependencies already. Few have extended it to the AI gateway they added in an afternoon eighteen months ago and have not looked at since.
If you have not audited what is actually running in your AI stack recently, this is the week to do it. The AI supply chain security checklist and AI vendor due diligence checklist both give a broader framework to build this into a recurring process rather than a one-time fire drill.
Related Reading
- 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
Sources: SecurityWeek, "Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack", The Hacker News, "Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations", TechCrunch, "After data breach, $10B-valued startup Mercor is having a month", Cybernews, "Meta suspends work with Mercor after security breach", Mercor, "Update on Mercor Security Incident", LiteLLM, "Security Update: CVE-2026-42208 in LiteLLM Proxy", LiteLLM, "Security Update: CVE-2026-30623", NIST NVD, CVE-2026-33634.
