The LiteLLM Supply Chain Attack: How a Security Scanner Became a Backdoor

TechLife
AI , Software
27 Mar, 2026
7 min read

If you work with AI APIs, there’s a reasonable chance LiteLLM is somewhere in your dependency tree — possibly without you ever explicitly installing it. It’s one of the most widely used Python libraries in the AI ecosystem, providing a single unified interface to forward requests to OpenAI, Anthropic, Google, and dozens of other providers. It has over 40,000 GitHub stars and approximately 97 million monthly downloads on PyPI.

On March 24, 2026, it was backdoored.

Versions 1.82.7 and 1.82.8 of LiteLLM were found to contain a multi-stage credential stealer that executed automatically on every Python process startup — not just when the library was imported, but on every Python interpreter invocation on the affected machine. SSH keys, cloud credentials, database passwords, Kubernetes secrets, API keys from .env files: all targeted, encrypted with a 4096-bit RSA public key, and exfiltrated to infrastructure controlled by the attackers.

The affected versions have been removed from PyPI. But if you installed LiteLLM on March 24, 2026 — whether intentionally or as a transitive dependency through your AI tooling — the malware already ran. Credential rotation is mandatory.

How It Happened: The Trivy Connection

This wasn’t a direct attack on LiteLLM’s codebase. It was a supply chain attack that started several steps upstream.

On March 19, 2026, a threat actor known as TeamPCP compromised Aqua Security’s Trivy vulnerability scanner. Trivy is an open-source security tool widely used in CI/CD pipelines to scan container images and dependencies for known vulnerabilities — the kind of thing you’d install specifically to catch security problems. TeamPCP hijacked release tags in the trivy-action GitHub Action, pointing them at malicious commits.

LiteLLM’s CI/CD pipeline used Trivy as part of its build process, pulling it from apt without a pinned version. The compromised Trivy action exfiltrated a PYPI_PUBLISH token from the GitHub Actions runner environment.

With that token in hand, TeamPCP published litellm 1.82.7 at 10:39 UTC and litellm 1.82.8 at 10:52 UTC on March 24, bypassing LiteLLM’s normal release workflow entirely. No corresponding tags exist in the GitHub repository — these were direct PyPI uploads.

The malicious packages were available for approximately three hours before PyPI quarantined them.

Two Versions, Two Attack Methods

The two compromised versions used different injection techniques — apparently the attackers refined their approach between the two uploads.

Version 1.82.7: An obfuscated, base64-encoded payload embedded directly inside litellm/proxy/proxy_server.py at line 128. This injection method required the library to be imported for the payload to execute — specifically, anything importing litellm.proxy.

Version 1.82.8: This version added a file called litellm_init.pth to Python’s site-packages directory. This is the nastier technique. Python’s site module processes .pth (path configuration) files during interpreter startup. Any line in a .pth file that begins with import is executed as Python code — on every Python process startup, with no import of LiteLLM required.

That means: a data scientist running a Jupyter notebook, a DevOps engineer running an Ansible playbook, a developer running unit tests — every one of them triggered the malware if LiteLLM 1.82.8 was installed in the same Python environment. The payload executed before the user’s code ran, and it was double base64-encoded to evade static analysis tools scanning for common malware patterns.

What the Malware Did

The credential stealer operated in three stages:

Stage 1 — Collection: A Python script harvested sensitive files from the host: SSH private keys and configs, .env files, AWS/GCP/Azure credentials, Kubernetes configs, database passwords, and .gitconfig. It also ran commands to dump environment variables and query cloud metadata endpoints (IMDS, container credentials).

Stage 2 — Exfiltration: Collected data was encrypted with a hardcoded 4096-bit RSA public key using AES-256-CBC (random session key, encrypted with the RSA key), bundled into a tar archive, and sent via POST request to https://models.litellm.cloud/ — a domain that has no relation to legitimate LiteLLM infrastructure.

Stage 3 — Persistence and lateral movement: If a Kubernetes service account token was present, the malware read all cluster secrets across all namespaces and attempted to create a privileged alpine:latest pod on every node in kube-system, mounting the host filesystem and installing a persistent backdoor. On the local machine, it attempted persistence via ~/.config/sysmon/sysmon.py with a systemd user service.

One detail security researchers flagged: when the payload’s exfiltration endpoint detected it was being queried from a sandbox or analysis environment, it returned a link to a remaster of “Bad Apple!!” — a technique designed to defeat automated analysis tools and make the attacker mock researchers in the process.

Was This Attack Unique to LiteLLM?

No. LiteLLM was the third target in a coordinated campaign. TeamPCP’s progression:

March 19: Compromised Aqua Security’s Trivy scanner
March 21-23: Hijacked Checkmarx’s KICS GitHub Action release tags
March 24: Used Trivy-stolen credentials to backdoor LiteLLM

The target selection is deliberate: these are security and AI infrastructure tools that live in CI/CD pipelines, development environments, and production systems with elevated access to credentials. Trivy is a security scanner. KICS is an infrastructure scanning tool. LiteLLM is the AI model routing library that holds your API keys to OpenAI, Anthropic, and every other provider you use.

A single compromised maintainer account in this category cascades through thousands of downstream projects instantly.

What You Need to Do Right Now

Check if you’re affected:

pip show litellm | grep Version

If the output shows 1.82.7 or 1.82.8, treat the machine as compromised.

Don’t just upgrade. Upgrading won’t undo damage already done if the payload ran. The malware may have already executed on install.

Rotate all credentials accessible from affected machines:

SSH keys
AWS/GCP/Azure access tokens and service account keys
Kubernetes configs
API keys in .env files (OpenAI, Anthropic, and all other providers)
Database passwords
GitHub tokens

Check CI/CD pipelines: If any pipeline installed LiteLLM between 10:39 UTC and roughly 13:00 UTC on March 24, 2026, treat the runner environment’s credentials as compromised.

Last known-clean version: litellm==1.82.6, published March 22, 2026.

LiteLLM’s maintainers have paused new releases while conducting a broader supply-chain review. The entire LiteLLM package was temporarily quarantined on PyPI pending the investigation; check PyPI’s current status before reinstalling.

The Broader Lesson

The LiteLLM attack illustrates a pattern that security professionals have been warning about for years, now manifesting in AI infrastructure specifically: the attack surface of your AI tooling is your credential surface.

Every library that touches your API keys — whether for routing, caching, evaluation, or logging — is a potential vector. The fact that LiteLLM is a transitive dependency in many AI agent frameworks, MCP servers, and LLM orchestration tools means the blast radius of this attack extends well beyond developers who explicitly use LiteLLM.

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. The most effective mitigation is secrets management: credentials should live in a secrets manager, not .env files, and service accounts should have the minimum permissions required for their function.

The AI tooling ecosystem is moving fast. Fast enough that security hygiene hasn’t always kept pace.

Sources: