LiteLLM PyPI Package Breach 2026: How a Poisoned Security Scanner Leaked Its Publishing Token and Exposed LLM API Keys

On 24 March 2026, two malicious versions of LiteLLM, the popular open source Python library that routes requests to many large language model providers, were published to PyPI. Versions 1.82.7 and 1.82.8 carried a credential stealer that collected SSH keys, cloud credentials, Kubernetes secrets, environment variables and LLM API keys from any machine that installed them. The attackers did not break into LiteLLM's code repository. They used a PyPI publishing token that had leaked from LiteLLM's own CI pipeline when a compromised copy of the Trivy security scanner ran inside it. Researchers attribute the operation to TeamPCP, the group behind a wider campaign against developer and security tools.

At a glance

What happened

LiteLLM is a library and proxy that gives developers one interface to many LLM providers. The environments where it runs often hold API keys for several model providers, and other AI tools pull it in as a dependency.

The attack started elsewhere. On 19 March 2026, TeamPCP rewrote release tags of the Trivy vulnerability scanner so that they pointed to a malicious release, according to Snyk's timeline. Trivy is widely used in CI pipelines, and LiteLLM's pipeline ran it as part of security scanning. LiteLLM later explained that the compromised Trivy package "ran during the scan, had access to environment variables, and enabled attackers to obtain those credentials." One of those credentials was the PYPI_PUBLISH token used to release LiteLLM, as Snyk and The Register describe. In LiteLLM's own words, "a compromised package in CI had access to secrets it should not have had."

With the token, the attackers did not need to touch LiteLLM's GitHub repository. LiteLLM's advisory says they "bypassed official CI/CD workflows and uploaded malicious packages directly to PyPI." Snyk records version 1.82.7 at 10:39 UTC on 24 March and version 1.82.8 thirteen minutes later. The exfiltration domain, models.litellm.cloud, had been registered the day before.

The two versions triggered in different ways. In 1.82.7, the code sat in proxy_server.py and ran when the proxy module was imported. Version 1.82.8 added a file called litellm_init.pth. Python processes .pth files in site-packages at start-up, so Unit 42 notes that the payload ran "every time any Python process was initialized on a host regardless of whether LiteLLM was ever imported."

The payload worked in three stages, according to Snyk. It first collected SSH keys, .env files, Git credentials, AWS, GCP and Azure tokens, Kubernetes kubeconfig files, Docker configuration and cryptocurrency wallets. Unit 42 adds that it read "high-density environment variables containing LLM API keys (e.g., OPENAI_API_KEY, ANTHROPIC_API_KEY)". It then encrypted the haul with AES-256 and a hardcoded 4096-bit RSA public key, packed it into an archive named tpcp.tar.gz and sent it to models.litellm.cloud. Finally, it installed a persistent backdoor as a systemd service under ~/.config/sysmon/ and, where it found Kubernetes access, deployed privileged pods named node-setup-{node_name} that mounted the host file system.

The compromise was discovered by accident. An engineer at FutureSearch found it after an MCP plugin running inside Cursor pulled LiteLLM in as a transitive dependency. A flaw in the malware made the .pth launcher spawn Python child processes repeatedly, which acted as a fork bomb and crashed the machine. The GitHub issue reporting it was flooded with bot comments; Snyk counted "88 bot comments from 73 unique accounts in a 102-second window".

PyPI quarantined the project and the malicious versions were removed. Sources differ on how long they were available: LiteLLM says they were live from 10:39 UTC "for about 40 minutes before being quarantined by PyPI", while Snyk puts it at around 13:38 UTC, roughly three hours after the first upload. LiteLLM CEO Krrish Dholakia told The Register: "We have deleted all our PyPI publishing tokens."

Timeline

How it happened: the identity attack path

1. Upstream tool compromised. TeamPCP compromised the Trivy scanner, which many projects run in CI with broad access to the job environment.
2. CI secret exposed to the wrong job. LiteLLM's security scan ran the compromised Trivy with access to environment variables that included the PYPI_PUBLISH token. The scanner had no need for a publishing credential.
3. Long-lived publishing token reused. The attackers used the stolen token to upload two versions directly to PyPI, outside the normal release workflow.
4. Automatic execution on install. The .pth launcher in 1.82.8 ran on every Python start-up, so any developer laptop, CI runner, container or AI agent host with the package installed ran the stealer, even if LiteLLM was only a transitive dependency.
5. Non-human identities harvested. The payload collected cloud credentials, SSH keys, Kubernetes tokens, database passwords and LLM API keys, then sent them encrypted to a look-alike domain.
6. Persistence and lateral movement. A systemd backdoor kept access to the host, and privileged Kubernetes pods extended it to cluster nodes where the stolen credentials allowed.
7. Stolen credentials reused later. The FBI warned that affiliated actors are likely to use credentials from the campaign "long after the initial compromise", as The Hacker News reports.

Impact

LiteLLM is heavily used. Snyk put its downloads at about 3.4 million a day. LiteLLM says customers running its official Proxy Docker image were not affected, because that image pins dependencies and did not pull the malicious PyPI versions. Independent verification by Veria Labs found no indicators of compromise in LiteLLM's previous 20 releases, according to LiteLLM's town hall update.

LiteLLM has not published a count of affected users. In August 2026, The Hacker News reported that CloudSEK had obtained a dataset built from roughly 434,000 files captured by the attackers, which it said maps potential exposure to more than 2,500 organisations (the article's headline gives 2,100 or more). CloudSEK stressed that the 434,000 figure "counts captured files and exfiltration events rather than distinct pipelines, runs, or jobs."

The GitHub advisory told anyone who installed and ran the affected versions to "assume any credentials available to litellm environment may have been exposed, and revoke/rotate them accordingly." Because LiteLLM usually sits next to model provider keys, those keys were exposed alongside cloud and cluster credentials, opening the door to LLMjacking.

What this means for NHI governance

Every step of this attack used a non-human identity. A CI secret was exposed to a tool that did not need it. A long-lived publishing token was replayed from outside the pipeline. The payload's target list was a catalogue of machine credentials: cloud keys, Kubernetes service account tokens, database passwords, SSH keys and the API keys that AI applications use to call model providers.

The first governance gap is scope. A security scanner and a release step do not need the same secrets, yet in many pipelines every job in a workflow can read every secret. When a third-party tool is compromised, it inherits whatever the job can see. The second gap is lifetime. A static PyPI token works from anywhere until it is revoked; LiteLLM's move to trusted publishing, which issues short-lived credentials tied to a specific workflow, removes that replay window. The third gap is visibility. Many victims did not know LiteLLM was in their environment, because an agent framework or MCP plugin pulled it in. LiteLLM's advisory warns users that they may be exposed if a dependency "pulled in LiteLLM as a transitive, unpinned dependency (for example through AI agent frameworks, MCP servers, or LLM orchestration tools)".

AI gateway libraries deserve particular care. They concentrate LLM API keys for many providers in one process, which makes them an attractive target. The same pattern appeared in the Miasma and Hades worms and the ChainDrop npm worm, where publishing tokens and developer secrets became the means of spreading.

Recommendations

• Separate CI secrets by job. Give publishing credentials only to the release job, and keep them away from scanning, testing and build steps that run third-party code. The CI/CD Pipeline Identity Security Guide covers how to scope them.
• Replace static publishing tokens. Use PyPI trusted publishing or other short-lived, workflow-bound credentials, and delete old API tokens once the switch is made.
• Pin CI tools and dependencies. Pin GitHub Actions to commit hashes and install scanners and other tools at fixed, verified versions rather than pulling the latest release.
• Know where AI libraries run. Track direct and transitive AI dependencies, including those brought in by agent frameworks and MCP plugins, as described in the AI Supply Chain Security and AI-BOM Guide.
• Treat LLM API keys as production credentials. Store them in a secrets manager, scope them per application, set spending limits and alert on unusual use. See the LLM Provider API Key Security and LLMjacking Guide.
• Rotate everything the host could reach. If 1.82.7 or 1.82.8 was installed, look for litellm_init.pth, the ~/.config/sysmon/ backdoor and node-setup- pods, then rotate cloud, Kubernetes, database, SSH and LLM provider credentials available to that environment.

Frequently asked questions

What happened in the LiteLLM PyPI breach?

On 24 March 2026, attackers published LiteLLM versions 1.82.7 and 1.82.8 to PyPI with a credential stealer. They used LiteLLM's PyPI publishing token, which had leaked when a compromised Trivy scanner ran in the project's CI pipeline. The malware stole cloud, Kubernetes, SSH, database and LLM API credentials from machines that installed it.

Which LiteLLM versions were affected?

Only versions 1.82.7 and 1.82.8 on PyPI. LiteLLM says users of its official Proxy Docker image were not affected, and it advised pinning to 1.82.6 or earlier until a clean 1.83.0 was released on 30 March 2026.

Who was behind the LiteLLM supply chain attack?

Researchers at Unit 42 and Snyk attribute it to TeamPCP, a group that also compromised Trivy, Checkmarx KICS and the Telnyx Python SDK in March 2026. The FBI issued a FLASH alert about the campaign on 2 July 2026.

Related NHI Mgmt Group resources

Miasma and Hades worms · Mastra npm supply chain attack · PyPI breach · AI LLM hijack breach · Secrets Management Guide

How NHI Mgmt Group can help

The LiteLLM breach shows how one exposed CI token can put cloud keys, cluster credentials and LLM API keys at risk across thousands of environments. Our NHI Foundation Level Training Course helps teams find, scope and govern these non-human identities before attackers reach them.

References

• LiteLLM: Security Update, Suspected Supply Chain Incident (24 March 2026, updated 30 March 2026)
• LiteLLM: Security Townhall Updates (27 March 2026)
• GitHub Advisory Database: Two LiteLLM versions published containing credential harvesting malware (GHSA-5mg7-485q-xm76) (25 March 2026, updated 27 March 2026)
• FutureSearch: litellm 1.82.8 Supply Chain Attack on PyPI (24 March 2026)
• Snyk: How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM (24 March 2026)
• Palo Alto Networks Unit 42: Weaponizing the Protectors, TeamPCP's Multi-Stage Supply Chain Attack on Security Infrastructure (31 March 2026, updated 9 April 2026)
• The Register: LiteLLM infected with credential-stealing code via Trivy (24 March 2026)
• The Hacker News: Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations (12 August 2026)