If your team has touched LiteLLM 1.82.7 or 1.82.8 since March 2026, the numbers that surfaced in August should get your attention. The LiteLLM supply chain attack was first disclosed as a narrow, hours-long PyPI incident. It turned out to be much bigger. Independent analysis of the attackers’ own exfiltrated data now links roughly 2,488 corporate domains and hundreds of thousands of CI/CD pipeline runs to the compromise.
Here’s why that matters beyond the headline number. LiteLLM is a widely used open-source proxy that lets applications talk to dozens of large language model providers through one interface. It sits between developers and every AI provider key, cloud credential, and CI secret they use which is exactly why this incident carries more weight than a typical malicious package. This article walks through what happened, why the newly disclosed victim numbers changed the picture, and what developers and security teams should actually go check right now.
Quick Answer
The LiteLLM supply chain attack happened on March 24, 2026. Threat actor TeamPCP published two malicious versions LiteLLM 1.82.7 and 1.82.8 to PyPI after compromising the Trivy scanner used in LiteLLM’s build pipeline. The packages harvested cloud, Kubernetes, and AI provider credentials before being pulled within roughly 40 minutes to a few hours. That seemed like the end of it at the time. Then research published in August 2026 by CloudSEK and Hudson Rock showed the fallout reached about 2,488 organizations and over 430,000 CI/CD pipelines – far more than anyone initially assumed.
What Happened: Attack Timeline
The LiteLLM supply chain attack unfolded fast. Its consequences are still being mapped five months later. According to LiteLLM’s own security update, the compromised packages litellm 1.82.7 and litellm 1.82.8 – went live on PyPI on March 24, 2026, at 10:39 UTC and stayed available for roughly 40 minutes before being pulled. Other researchers describe a slightly longer exposure window, closer to two or three hours, once cached mirrors and delayed builds get factored in.
Automated scanning from Sonatype reportedly flagged the packages within seconds of upload. Both versions came down from PyPI shortly after, with version 1.82.6 confirmed as the last known-clean release beforehand. LiteLLM’s maintainers published their own advisory the same day, naming the two compromised versions and confirming they’d been pulled.
But a short window doesn’t mean a small blast radius. Anyone who ran a plain pip install litellm without a pinned version during that stretch – or whose CI/CD pipeline auto-updated dependencies – could have pulled in a backdoored build without ever knowing it.
How the Attackers Got In: The Trivy Connection
This wasn’t a direct attack on LiteLLM’s own infrastructure. LiteLLM’s security advisory points to the Trivy dependency used in its CI/CD scanning workflow as the likely entry point. Trivy is a popular open-source vulnerability scanner from Aqua Security – and it had itself been compromised days earlier.
Aqua’s own account of that earlier incident describes attackers who retained access after an incomplete credential rotation, then pushed malicious commits across nearly all of the trivy-action version tags while publishing a poisoned Trivy release. LiteLLM’s build pipeline pulled in Trivy without pinning it to a verified, hash-locked version. So the poisoned scanner code fed directly into LiteLLM’s own release process.
Exactly how the malicious code then reached PyPI is still disputed across published accounts. One analysis attributes it to the poisoned build itself producing and publishing the malicious releases. LiteLLM’s own incident report instead points to a direct PyPI upload that bypassed its official CI/CD workflow.
Separate research describes attackers targeting PyPI publishing credentials more directly. The accounts don’t fully agree on the mechanics, but they converge on the same root failure: an unpinned, over-trusted dependency inside a build pipeline became the path from one compromised tool to a widely used downstream package.
The incident is now formally tracked under CVE-2026-33634, which covers the broader Trivy/LiteLLM ecosystem compromise and was added to CISA’s Known Exploited Vulnerabilities catalog on March 26, 2026. Later reporting in August confirmed the CVE record now lists the affected LiteLLM versions alongside the Trivy components.
What the Malicious Packages Actually Did
The two malicious releases weren’t equally dangerous. Version 1.82.7 hid its payload inside LiteLLM’s proxy server code, so it only executed for applications actively using the proxy feature. Version 1.82.8 was worse. It shipped a .pth startup file that Python’s interpreter runs automatically at launch before any application code, including an explicit import litellm, ever executes.
Once active, the malware harvested environment variables and sensitive local files such as cloud credential stores and Kubernetes configuration files, and it attempted lateral movement inside Kubernetes clusters. Here’s the part worth flagging for anyone doing incident response: the credential harvesting wasn’t scoped to LiteLLM-specific configuration. It followed whatever the running process had access to cloud, source-control, registry, and AI provider credentials alike.
One detail stood out to researchers. When outbound exfiltration failed, the malware fell back to creating a public repository inside the victim’s own GitHub account and uploading stolen data there as a release asset. That’s a nasty touch, because it makes the leak harder to spot the apparent source of the exposed data is the victim’s own account, not something obviously external.
Why the Victim Count Grew to 2,488 Organizations
For months after the March incident, the story looked contained: a short exposure window, a fast PyPI takedown, a relatively small number of confirmed installs. Then August 2026 happened. Two independent threat intelligence firms published analysis based on the attackers’ own exfiltrated material, and the picture changed considerably.
CloudSEK’s review of roughly 434,000 stolen files pointed to potential exposure across more than 2,500 organizations. Hudson Rock separately reported analyzing a 153GB archive of 433,909 files, including 118,829 CI runner dumps, which it attributed to 2,488 distinct corporate domains. Both firms are careful about what these figures actually represent, though. Attribution is based on evidence contained in the stolen material itself, not confirmed breach reports from each affected company – so a captured file or CI run linked to an organization doesn’t by itself prove that organization suffered follow-on compromise.
Still, even with that caveat, the scale reframes the incident. A short-lived PyPI package compromise turned into one of the larger documented AI software supply chain exposure events of the year. That’s largely a function of where LiteLLM sits in modern development stacks – brokering access to every LLM provider an organization uses, often from inside CI/CD runners that already hold cloud and registry credentials.
CyberInfos Analyst Insight
What makes this incident worth studying isn’t the malware itself. Credential-stealing payloads hidden in poisoned packages aren’t new. It’s the trust chain that carried it: a security scanner got compromised, and that scanner’s unpinned presence in a CI pipeline was enough to poison a downstream package with millions of daily downloads.
For teams building on AI infrastructure specifically, treat this as a preview of a broader pattern rather than a one-off. AI gateways, model routers, and orchestration libraries increasingly sit in the same privileged position LiteLLM did – brokering multiple providers’ credentials at once. A compromise there doesn’t expose one service; it exposes the entire AI provider surface an organization touches. The practical takeaway: apply the same supply-chain scrutiny to these libraries that’s already standard for cloud SDKs and CI tooling, instead of treating them as lightweight utility packages.
Another concern worth sitting with is the five-month gap between the original incident and the disclosure of its true scale. An “it was patched quickly” assessment based on the PyPI exposure window alone can understate real risk when the payload is a credential harvester – stolen secrets stay useful to an attacker long after the vulnerable package version is gone.
By the Numbers
| Metric | Figure |
|---|---|
| Malicious PyPI versions | litellm 1.82.7, 1.82.8 |
| Date published | March 24, 2026 |
| Exposure window on PyPI | ~40 minutes to ~3 hours |
| Organizations linked to stolen data (CloudSEK) | 2,500+ |
| Corporate domains attributed (Hudson Rock) | 2,488 |
| CI/CD pipelines potentially exposed | ~430,000–434,000 |
| Stolen files analyzed (Hudson Rock archive) | 433,909 (~153GB) |
| CI runner dumps attributed | 118,829 |
| CVE tracking the ecosystem compromise | CVE-2026-33634 |
| Threat actor | TeamPCP (tracked by Google as UNC6780) |
Figures reflect CloudSEK and Hudson Rock reporting as of August 2026. Both firms note that dataset presence indicates potential exposure, not confirmed breach, for any individual organization.
Who Is TeamPCP?
TeamPCP has been linked to several other open-source supply-chain compromises across npm and PyPI. That includes a connection to the self-propagating “Shai-Hulud”-style worm that spread through hundreds of package versions earlier in the campaign, harvesting cloud, developer, and cryptocurrency credentials along the way. The LiteLLM incident sits inside a wider effort against open-source tooling commonly used in developer and security workflows. Trivy, and by extension LiteLLM, look like part of that pattern rather than isolated, one-off targets.
Developer Remediation Checklist
- Identify every environment that installed or ran litellm 1.82.7 or 1.82.8, including CI runners, containers, and cached wheel files
- Do not simply upgrade the package the payload may already have executed, so treat the underlying system as compromised, not just the package version
- Pin LiteLLM to version 1.82.6 or an audited release at 1.83.0 or later
- Rotate every credential accessible to the affected process: cloud provider keys (AWS, Azure, GCP), Kubernetes service-account tokens and kubeconfig files, source-control tokens (GitHub, GitLab), package registry credentials, and AI provider API keys
- Search your GitHub organizations for unexpected repositories that may have been created to stage exfiltrated data as release assets
- Look for unauthorized
.pthfiles in Python site-packages directories and unfamiliar persistence mechanisms or services - Review cloud, Kubernetes, source-control, and network logs for activity dating back to the March 24, 2026 compromise window
- Rebuild affected CI runners and containers from known-clean images rather than patching in place
- Confirm your dependency-pinning and hash-verification practices cover indirect build tools, like scanners, as strictly as application dependencies
Detection Guidance for Security Teams
Beyond the checklist above, security teams should treat this as a broader detection exercise rather than a one-time package check:
- Threat hunting: Query EDR/XDR telemetry for outbound connections from build or CI infrastructure to unfamiliar domains around March 24, 2026, and for any process reading cloud credential files or Kubernetes configs outside expected application behavior.
- SOC playbook: Add LiteLLM version verification to onboarding and periodic dependency audits for any team using AI gateway or LLM-proxy tooling.
- IOC handling: Treat any credential that touched an affected environment as compromised by default — don’t wait for confirmation of misuse before rotating.
- Governance: Extend software composition analysis (SCA) coverage to CI/CD tooling itself, not just application dependencies, since this incident originated one layer removed from the package that was ultimately weaponized.
Real-World Examples
A government cloud account. Separate assessment work tied to the underlying Trivy compromise found high-confidence evidence that a European Commission AWS account was compromised through that supply chain, with tens of gigabytes of compressed data exfiltrated. It’s a useful reminder that the compromise propagated beyond LiteLLM users specifically, reaching anyone touched by the earlier Trivy incident.
An open-source project reacting mid-stream. Downstream open-source projects that depend on LiteLLM had to respond in real time. In at least one public case, a maintainer confirmed their own build predated the compromise window — but chose to remove the LiteLLM dependency entirely in a follow-up release anyway, replacing it with direct provider SDKs. Not a strictly necessary move, but a pragmatic one for a team unwilling to keep depending on a single high-privilege gateway package after watching an incident like this play out.
Lessons for the AI Software Supply Chain
Three structural issues stand out here, and all three apply broadly to AI software supply chain risk — not just to LiteLLM:
- Unpinned build-time tools are a blind spot. Most supply-chain hardening focuses on application dependencies. This attack succeeded because a security scanner running inside a CI pipeline wasn’t pinned to a verified version.
- AI gateways concentrate credential risk. Libraries that broker access to multiple LLM providers hold outsized value to attackers, precisely because one compromise yields many providers’ keys at once.
- Exposure scope isn’t fixed at disclosure time. The true blast radius of this incident wasn’t understood until researchers obtained and analyzed the attackers’ own stolen data, months after the packages were pulled. Organizations that assumed they weren’t affected simply because they missed the original window should still check whether their domain turns up in the later victim-mapping research.
LiteLLM’s own response – bringing in outside forensic help, moving toward signed container images for future releases- points to where the broader ecosystem is heading: verifiable provenance for build artifacts, not just scanning for trouble after the fact.
FAQ
What is the LiteLLM supply chain attack?
It’s a March 2026 incident in which threat actor TeamPCP published two malicious versions of the LiteLLM Python package – 1.82.7 and 1.82.8 – to PyPI, after first compromising the Trivy scanner used in LiteLLM’s build pipeline. Both packages carried a credential-stealing payload.
How many organizations were affected by the LiteLLM supply chain attack?
Independent analysis published in August 2026 links the incident to roughly 2,488 corporate domains (Hudson Rock) and over 2,500 organizations (CloudSEK), based on review of the attackers’ own exfiltrated data. Worth noting: these figures reflect potential exposure, not confirmed breaches at every named organization.
Is LiteLLM 1.82.7 or 1.82.8 still available on PyPI?
No. Both versions were quarantined and removed within the exposure window on March 24, 2026. LiteLLM 1.82.6 and versions from 1.83.0 onward are considered clean.
What should I do if I installed LiteLLM 1.82.7 or 1.82.8?
Treat the environment as compromised, not just the package. Rotate every credential that process could reach, rebuild affected systems from clean sources, check for unauthorized .pth files, and review logs going back to March 24, 2026.
Was this a vulnerability in LiteLLM’s code?
No. There’s no CVE against LiteLLM’s own application code, because nothing in the library itself was flawed. The compromise came through a poisoned build-pipeline dependency (Trivy) — not a bug a developer using LiteLLM’s APIs would ever trigger.
Who is behind the LiteLLM supply chain attack?
The threat actor is tracked as TeamPCP, also tracked by Google as UNC6780. This group has been linked to multiple open-source supply-chain compromises, including the Trivy incident that led into this one.
Does upgrading to a newer LiteLLM version remove the malware?
by itself. If the malicious version ran, credentials may already be stolen and persistence mechanisms may already be sitting on the system. A version bump doesn’t undo either of those affected systems need credential rotation and, ideally, a rebuild from known-clean sources.
Is there a CVE for this incident?
Yes. The broader Trivy/LiteLLM ecosystem compromise is tracked as CVE-2026-33634 and sits in CISA’s Known Exploited Vulnerabilities catalog.
How long were the malicious packages live on PyPI?
LiteLLM’s own advisory puts it at approximately 40 minutes. Other researchers estimate a window closer to two or three hours once caching and mirror delays get factored in.
What data did the malware target?
Environment variables, cloud credential files, Kubernetes configuration, source-control tokens, and AI provider API keys essentially any secret the running process could reach.
Final Thoughts
The LiteLLM supply chain attack is a case study in how a short, seemingly contained package compromise can balloon into a multi-thousand-organization exposure event once the full data trail gets analyzed. The immediate technical failure an unpinned, over-trusted build dependency is fixable with standard supply-chain hygiene: pin and hash-verify build tools, not just application dependencies, and give AI gateway libraries the same scrutiny already applied to cloud SDKs, given the credentials they broker.
For any team that touched LiteLLM around March 24, 2026, the immediate action is straightforward: confirm whether 1.82.7 or 1.82.8 was ever installed, and if so, rotate credentials and rebuild rather than assuming a version bump handled it. The longer-term action is more structural extend dependency verification to the tools sitting inside your CI/CD pipeline, not just the packages your application ships with.
