On March 24, 2026, LiteLLM — a Python package for routing requests to LLM providers, with over 95 million monthly downloads according to Mozilla AI — was compromised. A threat actor group identified in the Mozilla AI post as TeamPCP obtained the LiteLLM maintainer’s PyPI publishing credentials and uploaded malicious versions 1.82.7 and 1.82.8 directly to the Python Package Index. The GitHub source repository was not altered.

The payload in the compromised versions targeted SSH keys, cloud provider credentials, Kubernetes secrets, API keys, cryptocurrency wallets, and database passwords, exfiltrating them to an attacker-controlled server, according to Mozilla AI’s post-incident analysis.

How the attack worked

TeamPCP used the maintainer’s PyPI credentials to upload the malicious package, bypassing the GitHub repository entirely. The Mozilla AI post describes a specific mechanism: the payload used a .pth file, which it describes as a little-known Python mechanism that auto-executes code when the Python interpreter starts. This means the malicious code ran without requiring an explicit import litellm statement — installing the package was sufficient for the payload to execute.

Beyond credential theft, the payload attempted to establish persistence via systemd and to move laterally through Kubernetes clusters.

The Mozilla AI post cites Andrej Karpathy as noting that the compromised version was live for less than an hour and was discovered only because a bug in the malware caused a machine to crash. The post states that without that bug, the compromise could have gone undetected for days or weeks.

Mozilla AI states the critical detail directly: “The GitHub source was clean. The PyPI package was not. Anyone who reviewed the code on GitHub and assumed the published package matched it was wrong.”

Why LLM gateway libraries are high-value targets

The Mozilla AI post frames LiteLLM’s position in typical AI infrastructure as the reason it is an attractive target. LLM gateway libraries hold API keys for multiple providers — OpenAI, Anthropic, Google, Azure, Cohere, and others — by design. Compromising one package yields access to the credentials for all providers in an organisation’s stack.

Five mitigations

Mozilla AI’s post outlines five responses, ranked by the breadth of protection each offers.

Pin versions and verify hashes. Using exact version specifiers in requirements.txt combined with pip install --require-hashes prevents installation of versions whose hashes do not match. Hash values for any package version are available on PyPI via the package’s file listing.

Audit .pth files. The post provides a shell command to identify .pth files in the Python site-packages directory that contain import or exec statements — the signatures of malicious use. The post notes that legitimate .pth files should contain only directory paths.

Use PyPI trusted publishers. For maintainers publishing their own packages, PyPI’s trusted publisher mechanism ties releases to specific GitHub Actions workflows using OIDC-based authentication. This removes stored API tokens or passwords from the publishing path entirely, which the post describes as eliminating the attack vector used against LiteLLM. Mozilla AI states this is the only measure in the list that eliminates the vector rather than mitigating a specific exploit.

Compare distributed artifacts against source. The post recommends downloading the published wheel file and diffing it against the tagged source for critical infrastructure dependencies, rather than assuming they match.

Run a private package mirror with an allowlist. For production deployments, routing package installation through a private mirror or proxy — the post names devpi and Artifactory as examples — allows organisations to block compromised versions before they reach their infrastructure.

Mozilla AI’s own approach

The post describes how Mozilla AI’s own package, any-llm, handles publishing: releases go to PyPI exclusively through GitHub Actions using PyPI trusted publishers, with no maintainer holding a PyPI API token. The post frames any-llm as a drop-in replacement for OpenAI-compatible proxies for organisations considering moving off LiteLLM, and links to a two-step migration guide.

The post closes with the assertion that an LLM gateway should be treated with the same security rigour as a database or secrets manager. LiteLLM’s maintainers were not quoted in Mozilla AI’s post, and the post does not note whether a request for comment was made.