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.

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.