On March 24, 2026, two malicious versions of LiteLLM – the popular AI/LLM proxy gateway present in roughly 36% of cloud environments – were published directly to PyPI. Versions 1.82.7 and 1.82.8 contained a multi-stage credential stealer that harvested cloud keys, Kubernetes secrets, and cryptocurrency wallets, then spread laterally across clusters. They were live for approximately five and a half hours before being removed from PyPI.

LiteLLM is the gateway layer for modern AI infrastructure – proxying API calls to OpenAI, Anthropic, Azure, and dozens of other providers. It runs with access to every API key, cloud credential, and cluster token that those integrations require. Compromise LiteLLM, and you don’t just get one key – you get the keyring.

The compromise is linked to the Trivy supply chain incident we covered last week – LiteLLM’s PyPI publishing token was exposed through a poisoned Trivy binary running inside CI. The token was then used to upload weaponized packages without ever touching LiteLLM’s source code or release workflow.

If LiteLLM is running somewhere in your infrastructure – don’t wait to find out the hard way. We’ve released a dedicated remediation playbook – drop it into your AI coding assistant and skip straight to answers. Details below.

How did the Trivy compromise reach LiteLLM?

LiteLLM’s CI pipeline included a security scanning step (ci_cd/security_scans.sh) that installed Trivy via sudo apt-get install trivy – without pinning a version. When TeamPCP pushed a malicious Trivy v0.69.4 binary to every distribution channel on March 19, LiteLLM’s pipeline pulled the weaponized binary on its next run.

The poisoned Trivy binary ran inside the GitHub Actions runner and scraped process memory via /proc/<pid>/mem, bypassing GitHub’s secret masking to extract the PYPI_PUBLISH_PASSWORD token in plaintext. As LiteLLM co-founder Krish Dholakia confirmed, the token “got sent to Trivy, where attackers got ahold of it.”

Five days later, TeamPCP used that token to authenticate as the legitimate maintainer and upload v1.82.7 and v1.82.8 directly to PyPI – completely bypassing LiteLLM’s CI/CD. These versions never appeared in GitHub Releases.

How did the payload work?

Version 1.82.7 embedded a base64 payload in proxy_server.py, activating when users ran litellm --proxy. Version 1.82.8 escalated – it added a litellm_init.pth file to site-packages that executes during every Python interpreter startup, not just when LiteLLM is imported. Jupyter notebooks, Ansible, test suites, even pip itself – any Python process on the machine triggered the malware.

Once activated, the payload executed three stages:

• Harvest: SSH keys, cloud credentials, Kubernetes secrets, crypto wallets, Slack/Discord tokens – and actively queried AWS APIs using stolen IMDS credentials.
• Exfiltrate: AES-256 encrypted, sent to models.litellm[.]cloud.
• Persist: A systemd service polling checkmarx[.]zone for commands every ~50 minutes, plus Kubernetes lateral movement deploying privileged pods across every node in the cluster.

The identical RSA-4096 key across the Trivy, KICS, and LiteLLM payloads confirms this is one coordinated campaign.

Which versions are affected?

Docker image users were not affected – dependencies were pinned. The full timeline and technical details are tracked in GitHub issue #24518.

What should your team do now?

Check your installed version with pip show litellm. If it’s 1.82.7 or 1.82.8, you’re affected – but version checks alone aren’t enough, since the .pth persistence in v1.82.8 survives package removal. Search for litellm_init.pth in your site-packages, check for ~/.config/sysmon/sysmon.py and ~/.config/systemd/user/sysmon.service on disk, and look for outbound connections to models.litellm[.]cloud or checkmarx[.]zone. In Kubernetes, search for node-setup-* pods in kube-system. Any secret accessible to an environment that ran the compromised versions should be considered stolen and rotated.

Automate your response with our open-source playbooks

Manually auditing every server, container, and virtual environment where LiteLLM might be installed takes time you don’t have when stolen credentials may already be in use.

To help the community respond quickly, we’ve prepared ready-to-run remediation playbooks that compress that work into minutes. Drop them into your AI coding assistant (Claude Code, Cursor, GitHub Copilot), point them at your environment, and get a complete picture of your exposure – or a fully hardened pipeline – without writing a single script.

The Detection & Response playbook answers the question: were we exposed, and what exactly needs to be rotated?

The Hardening & Prevention playbook locks down your Python packaging, CI/CD pipelines, and dependency management against this entire class of supply chain attack – not just this incident.

Indicators of compromise

Key takeaways

Supply chain attacks cascade. One poisoned Trivy binary extracted credentials from every pipeline that ran it – and those credentials opened doors to entirely separate ecosystems. LiteLLM was one downstream victim. Checkmarx KICS was another. There will be more.

Pin everything. LiteLLM’s pipeline ran apt-get install trivy without a version pin. That single unpinned dependency created the entire attack chain. Pin your packages, your GitHub Actions (to commit SHAs), and your Docker images (to digests).

.pth files are a blind spot. Python’s .pth mechanism executes during any interpreter startup, survives package removal, and passes pip’s integrity checks. If you’re not scanning for malicious .pth files, start now.

Have you checked for exposure? We’d like to hear how your team is responding – especially if you’re seeing the .pth persistence or Kubernetes lateral movement.

*** This is a Security Bloggers Network syndicated blog from Legit Security Blog authored by Omer Guetta. Read the original post at: https://www.legitsecurity.com/blog/when-your-scanner-becomes-the-weapon-from-trivy-to-litellm