LiteLLM Supply-Chain Attack: How Trojanized PyPI Packages Turned an AI Gateway Into a Data Exfiltration Tool

Executive Summary

On March 24, 2026, attackers uploaded two trojanized releases of the popular Python library LiteLLM (1.82.7 and 1.82.8) to the PyPI repository. LiteLLM is a widely adopted gateway that abstracts API calls across multiple LLM providers, making it a high-value target embedded in thousands of AI agent deployments. The malicious payload — delivered as Base64-encoded Python — harvested database credentials, cloud runtime secrets, and application configurations, then encrypted the exfiltrated data with AES-256-CBC (session key protected by RSA) before transmitting it to a remote C2 server. The malware achieved persistent access by deploying privileged Kubernetes pods or systemd services, and extended its reach through trojanized OpenVSX and Checkmarx extensions. Victims were observed across Russia, China, Brazil, the Netherlands, and the UAE. Organizations using LiteLLM should immediately verify their installed versions and treat any environment that ran 1.82.7 or 1.82.8 as compromised.

Technical Analysis

Attack Vector: PyPI Package Poisoning

LiteLLM is a gateway library that routes requests to OpenAI, Anthropic, Hugging Face, and dozens of other LLM providers through a unified API. Its position in the AI stack makes it an ideal supply-chain target — it runs on infrastructure that handles API keys, model credentials, and often has access to cloud metadata services.

The attacker uploaded two trojanized releases to PyPI on March 24, 2026:

Any pip install, pip install --upgrade, or CI/CD pipeline that resolved these versions during the exposure window pulled the malicious code.

Payload Execution Chain

Once imported, the trojanized LiteLLM module executed a multi-stage attack:

Stage 1 — Credential Harvesting

The payload scanned the host for:

• Database configurations: MySQL (my.cnf), PostgreSQL (postgresql.conf), MongoDB connection strings
• Cloud runtime secrets: AWS Instance Metadata Service (IMDS) for IAM roles and temporary credentials, ECS task credentials via container metadata endpoints
• Application secrets: Environment variables, .env files, NPM configuration (~/.npmrc with registry tokens)
• Kubernetes secrets: Service account tokens, kubeconfig files

Stage 2 — Encrypted Exfiltration

The harvested data was compressed into an archive, then encrypted using a layered scheme:

1. A random AES-256-CBC session key encrypts the data archive
2. The session key itself is encrypted with a pre-initialized RSA public key embedded in the payload
3. The encrypted bundle is transmitted to the C2 server over HTTPS

This means intercepting the traffic is insufficient for recovery — only the attacker’s RSA private key can decrypt the session key. The encryption also evades DLP systems that scan for plaintext credentials in outbound traffic.

Stage 3 — Persistent Access

The malware deployed environment-appropriate persistence:

The Kubernetes vector is particularly dangerous: a privileged pod has access to the host’s filesystem, network namespace, and can escalate to cluster-admin if RBAC is misconfigured. Even if the original LiteLLM container is terminated, the persistence pod continues operating.

Extended Attack Surface

The campaign wasn’t limited to PyPI. According to Securelist, the attackers also distributed malicious code through:

• OpenVSX — the open-source VS Code extension marketplace
• Trojanized Checkmarx extensions — targeting static analysis tool users

A Node.js variant was also identified, which persisted locally rather than escalating to Kubernetes privileges. This multi-vector approach suggests a coordinated campaign targeting the entire development toolchain.

Impact Assessment

Who Is Affected

Any organization that installed litellm==1.82.7 or litellm==1.82.8 from PyPI is potentially compromised. Given LiteLLM’s role as an AI gateway, affected environments likely include:

• AI/ML platforms that use LiteLLM to route API calls to LLM providers
• CI/CD pipelines that install Python dependencies from PyPI
• Kubernetes clusters running AI workloads with LiteLLM as a dependency
• Development workstations where developers test LLM integrations

What Was Stolen

The payload specifically targeted:

• Database credentials and connection strings (MySQL, PostgreSQL, MongoDB)
• AWS IAM temporary credentials and instance metadata
• ECS container credentials and task definitions
• NPM registry tokens
• Kubernetes service account tokens and kubeconfig files
• Application environment variables and .env files

With these credentials, the attacker can access databases, impersonate cloud services, publish to NPM registries, and move laterally across cloud infrastructure.

Geographic Distribution

Securelist observed victims across Russia, China, Brazil, the Netherlands, and the UAE — indicating a broad, opportunistic campaign rather than targeted espionage against a specific region.

Detection & Response

How to Check If You’re Affected

1. Check installed version:

pip show litellm | grep Version

If the output shows 1.82.7 or 1.82.8, the environment is compromised.

2. Check lockfiles:
Search requirements.txt, Pipfile.lock, or poetry.lock for these versions. Check CI/CD build logs for pip install output during March 24–25.

3. Check for persistence artifacts:

On Linux hosts:

# Look for suspicious systemd services
systemctl list-units --type=service | grep -i llm
ls /etc/systemd/system/ | grep -i llm

On Kubernetes:

# Look for unexpected privileged pods
kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.containers[].securityContext.privileged==true) | .metadata.name'

4. Check for IMDS access:
Review AWS CloudTrail logs for unexpected GetMetaData or GetInstanceProfile calls from hosts running LiteLLM.

Incident Response

1. Isolate any system that ran the trojanized versions — it has active persistence mechanisms
2. Do not attempt to clean — the Kubernetes privileged pod and systemd service can re-download payloads. Rebuild from a clean state.
3. Rotate ALL credentials accessible from the compromised environment: database passwords, AWS access keys, NPM tokens, Kubernetes service account tokens
4. Audit Kubernetes clusters for unauthorized privileged pods and remove them
5. Check outbound traffic logs for encrypted connections to unfamiliar endpoints during and after March 24
6. Re-install LiteLLM from a verified source: pin to a known-safe version and validate the SHA-256 hash

Mitigation & Remediation

Broader Implications

This attack represents a significant evolution in supply-chain threats:

1. AI infrastructure is now a first-class target — LiteLLM sits at the intersection of cloud credentials, LLM API keys, and production data. Compromising it provides access to the most sensitive assets in an AI deployment.

2. Multi-vector distribution — the campaign simultaneously targeted PyPI, OpenVSX, and Checkmarx, covering Python, Node.js, and IDE extensions. This is not a single-channel attack; it’s a coordinated campaign across the development toolchain.

3. Encryption-wrapped exfiltration defeats traditional DLP — the AES-256-CBC + RSA layered encryption means the stolen data is unreadable even if intercepted. Organizations need to detect the exfiltration behavior (unexpected outbound connections), not the content.

4. Kubernetes persistence raises the stakes — a privileged pod in a misconfigured cluster can survive indefinitely and serve as a platform for further attacks against the entire cluster.

Timeline

Sources & References

1. Securelist (Kaspersky). An AI Gateway Designed to Steal Your Data — Supply-Chain Attack on LiteLLM. Link
2. CyberSIXT. Supply-Chain Attack on LiteLLM. Link

Sources

1. An AI gateway designed to steal your data
2. An AI gateway designed to steal your data - CyberSIXT Summary