LiteLLM hit by supply chain attack that turns Python library into credential-stealing backdoor

LiteLLM infected with credential-stealing code via Trivy

Python interface for LLMs infected with malware via polluted CI/CD pipeline Two versions of LiteLLM, an open source interface for accessing multiple large language models, have been removed from the Python Package Index (PyPI) following a supply chain attack that injected them with malicious credential-stealing code. Specifically, LiteLLM v1.82.7 and v1.82.8 have been taken down because they contain credential-stealing code in a component file, . Krrish Dholakia, CEO of Berri AI, which maintains LiteLLM, said in an online post that the compromise appears to have originated from the use of Trivy in the project's CI/CD pipeline. Trivy is an open source vulnerability scanner maintained by Aqua Security that many other projects include as a security measure. The malware campaign began in late February, when the attackers took advantage of a misconfiguration in Trivy's GitHub Actions environment to steal a privileged access token that allowed the manipulation of CI/CD, according to Aqua Security. The software was subverted on March 19, when attackers referred to as TeamPCP used compromised credentials to publish a malicious Trivy release (v0.69.4), and again on March 22, when malicious Trivy versions v0.69.5 and v0.69.6 were published as DockerHub images. But Aqua Security explains that the approach taken by the attackers was more sophisticated than just uploading a new malicious version of Trivy. "By modifying existing version tags associated with [the GitHub Action script] trivy-action, they injected malicious code into workflows that organizations were already running," the company said. "Because many CI/CD pipelines rely on version tags rather than pinned commits, these pipelines continued to execute without any indication that the underlying code had changed." Dholakia said that LiteLLM's PYPI_PUBLISH token, stored in the project's GitHub repo as an variable, got sent to Trivy, where attackers got ahold of it, then used it to push new LiteLLM code. "We have deleted all our PyPI publishing tokens," he said. "Our accounts had 2fa, so it's a bad token here. We're reviewing our accounts, to see how we can make it more secure (trusted publishing via JWT tokens, move to a different PyPI account, etc.)." In another twist, the GitHub vulnerability report appears to have been targeted with a spam attack designed to distract and obscure useful comments about the report. At 05:44 AM PDT, dozens of presumably AI-generated variations of "Thanks, that helped!" flooded the repo. According to security researcher Rami McCarthy, 19 of the 25 accounts used to post were also used in the Trivy spam campaign. The Python Packaging Authority (PyPA) has published a security advisory about the LiteLLM compromise. "Anyone who has installed and run the project should assume any credentials available to [the] LiteLLM environment may have been exposed, and revoke/rotate them accordingly," the advisory says. ®

A popular Python library just became a backdoor to your entire machine

If you work with AI APIs and local LLMs, there's a good chance you've at least heard of LiteLLM. It's one of the most popular Python libraries for interacting with large language models, offering a single unified interface to forward requests to OpenAI compatible endpoints, Anthropic, Google, and dozens of other providers through a single wrapper. It has over 40,000 stars on GitHub, and it's an important dependency in a lot of AI tooling. It's also been compromised on PyPI, and the malicious versions are stealing everything they can find on your machine. On March 24, 2026, version 1.82.8 of LiteLLM was pushed to PyPI containing a malicious .pth file called "litellm_init.pth". That file executes automatically on every Python process startup, meaning you don't even need to import the library for it to run. What's more, version 1.82.7 has also been compromised. On the latest version, simply having it installed is enough, but 1.82.7 requires an import for the payload to activate. The only reason anyone noticed the malware in the first place was out of sheer luck. It was first spotted by FutureSearch when an MCP plugin running inside Cursor pulled the package as a transitive dependency, and the machine ran out of RAM due to an exponential fork bomb. This is a developing story. This isn't a rogue package upload The fingerprints point to a familiar name This is where things get much worse. A commit pushed to one of the LiteLLM maintainer's forked repositories simply reads "teampcp owns BerriAI," which is about as blunt a calling card as you'll find. TeamPCP is the same threat actor responsible for compromising Aqua Security's Trivy vulnerability scanner on March 19 and Checkmarx's KICS GitHub Action on March 23. Whether this is genuinely TeamPCP or someone borrowing the name to muddy attribution isn't confirmed yet, but the technical overlap is hard to ignore. The attack follows the same playbook that TeamPCP has used over the last week: compromise a maintainer's account or credentials, push malicious versions to package registries, and deploy a multi-stage credential stealer. In the Trivy attack, they force-pushed release tags in the trivy-action GitHub Action to point at malicious commits. With KICS, they hijacked a ton of release tags in under four hours. The LiteLLM compromise shares the same encryption scheme and exfiltration pattern, though that alone doesn't rule out a copycat with access to the same publicly documented techniques. The LiteLLM maintainer's GitHub issue about the compromise, issue #24512, was closed as "not planned." Whether that means the account is still compromised or the maintainer simply closed it without context is unclear, but the calling card commit to a forked repository around the same time suggests the former. The payload is a three-stage credential stealer SSH keys, cloud tokens, crypto wallets, and more The malicious code in the compromised versions looks a lot like what was found in the Trivy compromise, according to FutureSearch's report. It operates in three stages, and if you've seen that payload, this will look familiar. First, it harvests everything it can find. SSH keys, environment variables, AWS credentials, GCP service account tokens, Azure secrets, Kubernetes configs, database passwords, .gitconfig, shell history, and even cryptocurrency wallet files. It also queries cloud metadata endpoints, which means if you're running this on an EC2 instance or a GKE pod, it's pulling instance credentials too. Here's the full list, according to the opened GitHub issue: * System info: hostname, whoami, uname -a, ip addr, ip route * Environment variables: printenv (captures all API keys, secrets, tokens) * SSH keys: ~/.ssh/id_rsa, ~/.ssh/id_ed25519, ~/.ssh/id_ecdsa, ~/.ssh/id_dsa, ~/.ssh/authorized_keys, ~/.ssh/known_hosts, ~/.ssh/config * Git credentials: ~/.gitconfig, ~/.git-credentials * AWS credentials: ~/.aws/credentials, ~/.aws/config, IMDS token + security credentials * Kubernetes secrets: ~/.kube/config, /etc/kubernetes/admin.conf, /etc/kubernetes/kubelet.conf, /etc/kubernetes/controller-manager.conf, /etc/kubernetes/scheduler.conf, service account tokens * GCP credentials: ~/.config/gcloud/application_default_credentials.json * Azure credentials: ~/.azure/ * Docker configs: ~/.docker/config.json, /kaniko/.docker/config.json, /root/.docker/config.json * Package manager configs: ~/.npmrc, ~/.vault-token, ~/.netrc, ~/.lftprc, ~/.msmtprc, ~/.my.cnf, ~/.pgpass, ~/.mongorc.js * Shell history: ~/.bash_history, ~/.zsh_history, ~/.sh_history, ~/.mysql_history, ~/.psql_history, ~/.rediscli_history * Crypto wallets: ~/.bitcoin/, ~/.litecoin/, ~/.dogecoin/, ~/.zcash/, ~/.dashcore/, ~/.ripple/, ~/.bitmonero/, ~/.ethereum/keystore/, ~/.cardano/, ~/.config/solana/ * SSL/TLS private keys: /etc/ssl/private/, Let's Encrypt .pem and .key files * CI/CD secrets: terraform.tfvars, .gitlab-ci.yml, .travis.yml, Jenkinsfile, .drone.yml, Anchor.toml, ansible.cfg * Database credentials: PostgreSQL, MySQL, Redis, LDAP config files * Webhook URLs: grep for Slack/Discord webhook URLs in env and config files Second, it encrypts the stolen data with a 4096-bit RSA key and AES-256-CBC, bundles it into a tar archive, and sends it to models.litellm[.]cloud, a domain that has nothing to do with LiteLLM's actual infrastructure. Thirdly, it attempts to move laterally. According to FutureSearch, it seems that the malware tries to create privileged Alpine pods in the kube-system Kubernetes namespace and installs a persistent backdoor at ~/.config/sysmon/sysmon.py with an accompanying systemd service. That backdoor polls a command-and-control server for updated payloads. What you need to do right now Check your environments immediately If you use LiteLLM, you need to check your installed version now. Run "pip show litellm" and verify you're not on 1.82.7 or 1.82.8. If you are, the damage may already be done, and credential rotation is mandatory. Here's what you should do: * Uninstall the compromised package and clear your pip cache entirely * Search for ~/.config/sysmon/sysmon.py on any machine that had the package installed * Check for unauthorized pods in your Kubernetes clusters, particularly in the kube-system namespace * Rotate every credential that was accessible from the compromised machine, including SSH keys, cloud provider tokens, database passwords, and API keys The fact that this was a .pth file is particularly nasty. Unlike a compromised import, a .pth file runs on every Python process, not just ones that use the library. If you had the package installed in a shared environment, every Python script on that machine was triggering the payload. Supply chain attacks are accelerating, and AI tooling is the new target Installing packages is an act of trust What bothers me most about this attack isn't the technical sophistication, it's the target selection. These are the tools that developers and platform engineers install in production environments and CI pipelines, and installing them would typically be considered a safe act. They're not obscure packages with a handful of downloads. We've already seen these attacks permeate numerous Node JS packages, and it seems that Python is just as much of a target. Subscribe to the newsletter for expert AI supply-chain coverage Protect your stack -- subscribe to the newsletter for deep technical breakdowns of AI tooling supply-chain incidents, clear coverage of attack vectors and exfiltration patterns, and actionable mitigation guidance focused on what to check and what credentials to rotate. Get Updates By subscribing, you agree to receive newsletter and marketing emails, and accept our Terms of Use and Privacy Policy. You can unsubscribe anytime. LiteLLM is a transitive dependency for a growing number of AI agent frameworks, MCP servers, and LLM orchestration tools. That means even if you never ran pip install litellm yourself, it may have been pulled in by something else. The person who discovered this attack only found it because their Cursor IDE pulled it in through an MCP plugin. There's no easy fix for this. Pinning versions helps, but only if you're pinning to a known-good version before the compromise. Lockfiles help, but only if you don't update them blindly. A single compromised maintainer account can cascade through thousands of downstream projects in minutes, and the window between compromise and detection is shrinking but still far too wide. At the time of writing, the package appears to have been locked on PyPI, but if you installed them in that window, the malware is already on your machine. Check your systems and rotate your credentials. Every pip install is an act of trust, and that trust just got a lot harder to hand out.