LiteLLM Supply Chain Incident: Access Risks Across the AI Stack

Siwoo Lee
6 hours ago
5 min read

This case demonstrates how centralizing access and secrets can amplify the impact of a supply chain attack

It has been confirmed that versions 1.82.7 and 1.82.8 of the litellm package distributed on PyPI were tampered with and contained malicious code. According to LiteLLM’s official security notice on March 24, 2026, these versions were compromised and have since been removed from PyPI. This incident can be classified as a supply chain attack, where an open source component that developers trusted as legitimate was actually distributed with embedded malicious code.

LiteLLM is a Python library and proxy that connects multiple LLM services through a unified interface, allowing developers to integrate and use different AI services in a consistent way. According to analysis by Wiz, LiteLLM was observed in 36% of cloud environments. BleepingComputer also reported that the package is widely used, with over 3.4 million downloads per day and approximately 95 million downloads in the past month.

The key point of this attack is not the LLM itself, but what level of access and sensitive information was stored in the intermediary tool connecting multiple AI services. The malicious versions were designed to collect and exfiltrate environment variables, SSH keys, AWS, GCP and Azure credentials, Kubernetes tokens, database passwords, and CI/CD secrets.

Tools like LiteLLM often manage multiple API keys and infrastructure credentials in one place. This attack specifically targeted that centralized concentration of permissions and secrets. As a result, if an organization was managing multiple model API keys and infrastructure secrets through LiteLLM, the potential impact could be significantly broader.

This incident serves as a reminder of what organizations should prioritize first from an AI security perspective. Many teams focus on model output quality or data handling risks. However, in real-world environments, tools that connect multiple AI services and the permissions granted to them can become a critical attack vector.

LiteLLM simplifies integration across AI services, but it also creates a structure where permissions and sensitive information are naturally centralized. In a supply chain compromise like this, attackers are not limited to collecting a few API keys. They can potentially access cloud credentials, CI/CD secrets, SSH keys, and Kubernetes tokens. The real question is not how many models are connected, but rather how much access that connecting layer holds.

This incident is also linked to the earlier Trivy supply chain compromise. Trivy is a widely used open source security scanner for container images, file systems, Git repositories, and Kubernetes environments. LiteLLM indicated that its publishing access may have been compromised through elements related to Trivy used in CI/CD security checks. Snyk described this as a case where the earlier Trivy supply chain compromise extended into LiteLLM’s PyPI publishing pipeline. Aqua Security also confirmed actions such as removing malicious releases, rotating secrets and tokens, and initiating investigation and recovery processes.

Key Points of LiteLLM Incident:

There are 3 main reasons why this incident matters:

First, the target was not the AI application itself, but the AI operational chain;
Second, version 1.82.8 was designed to execute code automatically when the Python environment starts, even without directly running LiteLLM
Third, the impact depends not on LiteLLM alone, but on how many credentials, tokens, and permissions were stored alongside it

This is not just a case of a compromised Python package. It demonstrates how centralizing access and secrets can amplify the impact of a supply chain attack.

Impact Scope

Based on currently available information, the scope is as follows:

Item	Details
Affected package	litellm (PyPI)
Malicious versions	1.82.7, 1.82.8
Safe baseline	Versions 1.82.6 and below are considered the last known safe versions

According to LiteLLM’s official notice, if LiteLLM was installed or upgraded between March 24, 2026 10:39 UTC and 16:00 UTC, and the version was not explicitly specified, it is likely that one of the malicious versions was installed. Even if LiteLLM was not installed directly, systems may still be affected.

This happens because:

A user installs another AI tool
That tool depends on litellm
During installation, litellm is automatically fetched from PyPI
If the latest version at that time was malicious, it is installed as a dependency
As a result, the malicious package is introduced indirectly

The key point is that the other tool itself is not malicious. The issue is that it pulled a compromised dependency during installation.

IOC

File IOC

litellm-1.82.7.whl
- SHA-1: 78cd382040eda14e2f8a17ee7387cffdabe96ab5
- SHA-256: 8395c3268d5c5dbae1c7c6d4bb3c318c752ba4608cfcd90eb97ffb94a910eac2
litellm-1.82.8.whl
- SHA-1: 3fcc7360a2738ad2656e17c7d4ed3e651ff7d73a
- SHA-256: d2a0d5f564628773b6af7b9c11f6b86531a875bd2d186d7081ab62748a800ebb
proxy_server.py
- SHA-1: 9e7587b990ae57319a6afedeba3b8873f6238206
- SHA-256: a0d229be8efcb2f9135e2ad55ba275b76ddcfeb55fa4370e0a522a5bdee0120b
litellm_init.pth
- SHA-1: 2d94efc6d49e05b314a9da55804f6a0d57154b18
- SHA-256: 71e35aef03099cd1f2d6446734273025a163597de93912df321ef118bf135238

Domain IOC

models[.]litellm[.]cloud
checkmarx[.]zone
checkmarx[.]zone/raw

Recommendations

This incident requires more than just removing the package.

1. Assessment

Check if pip install litellm or upgrades were performed on March 24, 2026
Verify whether version pinning was used
Review Docker images built during the affected timeframe
Check whether other AI tools installed litellm as a dependency
Inspect Python package paths for litellm_init.pth
Look for abnormal outbound connections from Python processes

2. Containment

Add file IOC to blocklists in security solutions
Block domain IOC at firewall, proxy, or DNS layers

3. Follow up Actions

Rotate all API keys, tokens, credentials, and passwords stored on affected systems
Review access scope across cloud, IAM, Kubernetes, databases, and CI/CD
Reduce permissions granted to AI tools, proxies, and integration layers

PAGO MDR Center Perspective on the LiteLLM Incident

PAGO MDR Center does not treat this type of incident as a simple IOC based response.

Instead, it operates through a continuous lifecycle: Threat Research → Threat Hunting → Detection Engineering → Detection Operations

This cycle is ongoing and continuously refined. The identified malicious files have already been classified and integrated into detection and prevention systems:

litellm-1.82.7.whl
litellm-1.82.8.whl
proxy_server.py
litellm_init.pth

Beyond this, PAGO MDR Center applies continuous threat hunting and detection engineering to identify similar attack patterns. In supply chain attacks like this, detection must go beyond file indicators. It requires connecting behaviors such as:

package installation
file creation
credential access
external communication

This approach allows detection even when attackers modify hashes or file names.

The key is not simply identifying malicious files, but understanding the sequence of actions and translating that into detection logic that works in real environments.

This incident is not about whether AI itself is dangerous. It shows that risk increases when permissions and sensitive data are concentrated in the systems that connect and operate AI services.

In the LLM era, the primary attack surface is no longer just the model. It is the tools, proxies, and infrastructure layers that manage access, credentials, and integrations.

Organizations need to look beyond prompt control and model behavior, and focus on:

how permissions are centralized
how secrets are managed and separated
how dependencies are installed and trusted
how deployment pipelines are secured

About PAGO Networks

The Global MDR Frontline | Owning the Decisions That Matter Most

PAGO Networks goes beyond traditional MDR that only analyzes threats or provides recommendations.

It focuses on making decisions before incidents escalate, intervening when necessary, and taking responsibility for critical outcomes.

By combining validated AI technologies with real operational experience, PAGO delivers security decisions tailored to each customer’s environment and stands behind those decisions.

This is how PAGO defines the Global MDR Frontline.

References

Written by: Siwoo Lee Threat Analyst | DeepACT MDR Center

Suspicious Activity?