LiteLLM Supply-Chain Hack: Why AI Infrastructure Needs Default-Deny Protection

Date: March 28, 2026

LiteLLM supply-chain compromise — malicious PyPI package versions blocked by WCS Trust Lockdown default-deny execution policy

Executive Summary

What happened: The legitimate litellm PyPI package — not a lookalike — was compromised. Versions 1.82.7 and 1.82.8 were replaced with malicious releases that public reporting associates with credential theft, Kubernetes-focused lateral movement, and persistence behavior.
Who is affected: Organizations that installed or ran LiteLLM 1.82.7 or 1.82.8 directly from PyPI. LiteLLM's official security update states that users of the official LiteLLM Proxy Docker image were not impacted by this incident.
Immediate action required: Any environment that ran an affected version should be treated as a potential credential exposure event. Rotate API keys, cloud credentials, Kubernetes secrets, CI/CD tokens, and SSH keys without delay.
The broader lesson: AI infrastructure components handle concentrated privileged access. Supply-chain attacks targeting them are high-value, and default-allow software environments give malicious updates time to execute before defenders respond.

What Happened

In late March 2026, security researchers and PyPI monitors identified that the litellm package — a widely used Python library that provides a unified interface for routing requests across multiple large language model providers — had been compromised at the source. This was not a typosquatting attack using a lookalike name. The official litellm package, published under the BerriAI organization on PyPI, was the target.

Two specific versions, 1.82.7 and 1.82.8, contained malicious code. According to LiteLLM's official security update, users who ran the organization's official LiteLLM Proxy Docker image were not impacted. The vulnerability was present in the raw PyPI package, affecting organizations that installed litellm directly via pip into their own environments.

LiteLLM's security update also indicates that the incident may be connected to a broader supply-chain compromise activity associated with the Trivy security scanner — sometimes referred to in public reporting under the threat cluster label TeamPCP. The full scope of that broader campaign is still being assessed by the research community.

Organizations that installed either affected version and allowed it to run should treat this as an active incident, not a theoretical risk.

Why the LiteLLM Compromise Matters

LiteLLM is not a general-purpose utility. It is an AI gateway component — a routing and abstraction layer that sits between application code and multiple LLM provider APIs. That architectural position makes it a particularly high-value compromise target.

AI infrastructure is a concentration point for privileged access

A single LiteLLM deployment may hold API keys for OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure OpenAI, and other providers simultaneously. It frequently runs in the same environment as or alongside the application logic it serves, meaning it has access to environment variables, configuration files, and secrets that applications need to function.

Depending on how an organization has deployed LiteLLM, the server or container running it may also have access to:

Cloud provider credentials or instance role permissions
Kubernetes service account tokens and cluster secrets
CI/CD pipeline tokens or job secrets
SSH keys for deployment or administrative access
.env files containing database credentials, webhook secrets, or other operational values

An attacker who achieves code execution within a LiteLLM process is not just reading one API key. They may be reading every privileged secret that process can access.

AI gateway infrastructure is underscrutinized

Security teams have decades of experience auditing traditional server software. AI gateway components, LLM proxy layers, and agent orchestration frameworks are newer additions to many organizations' stacks. They are often installed by developers or platform engineers who are moving fast, and they may not receive the same change-control scrutiny applied to network appliances or production databases.

That gap in scrutiny is exactly what supply-chain attacks are designed to exploit.

What the Malicious Releases Reportedly Did

Public reporting and security researcher assessments — not yet confirmed in full detail by LiteLLM — describe the following behavior associated with versions 1.82.7 and 1.82.8:

Credential theft. Researchers reported that the malicious code attempted to harvest credentials and secrets accessible from the runtime environment, including environment variables commonly used to store API keys and cloud authentication material.

Kubernetes-focused abuse and lateral movement. Public reporting indicates the malicious code included logic targeting Kubernetes environments — potentially attempting to access cluster secrets, service account tokens, or other Kubernetes API material available to the running process.

Persistence and backdoor behavior. Researchers reported that the malicious payload attempted to establish persistence on affected systems, though the specific mechanism varies across the two versions.

Execution timing differed between versions. According to public reporting, one of the malicious releases executed its payload during the normal import or proxy usage of the package. The later release reportedly used a .pth file — a Python startup path mechanism — to trigger execution earlier in the Python interpreter lifecycle, before the main application logic ran.

The .pth execution method is notable because it can be harder to detect: the malicious code runs at interpreter startup, before any explicit import of litellm occurs, and before many application-level logging or monitoring hooks are in place.

We are reporting the above based on published researcher assessments. Organizations should monitor for updated official analysis as the investigation matures.

Who May Be Affected

Direct exposure applies to any environment where pip install litellm==1.82.7 or pip install litellm==1.82.8 was run and the installed package was subsequently executed. This includes:

Developer workstations and laptops where LiteLLM is used for testing or prototyping
CI/CD pipelines that install dependencies at build or test time
Production or staging servers running LiteLLM as a proxy or gateway service
AI agent infrastructure and automation environments
Container images that were built after the malicious versions were published (if built from PyPI directly rather than from the official Docker image)

LiteLLM's update is clear that users of the official LiteLLM Proxy Docker image maintained by BerriAI were not impacted. If your deployment pulled from that image path, you are likely not affected — but verify the image provenance.

If there is any uncertainty about which version was installed, treat the environment as potentially compromised and act accordingly.

Why Traditional Security Tools Struggle with This Scenario

Supply-chain attacks succeed in part because they exploit the assumptions security tools are built on.

The delivery channel is trusted. PyPI is a legitimate software distribution platform. The package name is correct. The publisher organization matches. TLS is in place. Email security gateways, web proxies, and network firewalls have no basis to flag a routine pip install command pulling from a known package repository.

Package managers are broadly trusted by default. In most Python environments, pip is allowed to install packages from PyPI without restriction. Developers expect this to work. Security policies that allow Python and pip to run tend to extend implicit trust to everything those tools install, because placing granular controls on individual package installations requires deliberate policy design.

The malicious update arrives through the normal update workflow. An engineer runs pip install --upgrade litellm, or a CI pipeline re-pins to the latest version, or a container image rebuild pulls a fresh version. The action is indistinguishable from legitimate maintenance. There is no attachment, no suspicious link, no social engineering.

Detection-based tools face a timing problem. Behavioral heuristics, EDR agents, and anomaly detectors need time to observe, classify, and alert. A malicious package that exfiltrates credentials on first import may complete its primary objective before any behavioral alert surfaces. The .pth execution path — triggering at interpreter startup — makes this window even shorter.

Default-allow environments assume software arriving through recognized channels is safe. That assumption is the precise gap supply-chain attacks are engineered to exploit.

How White Cloud Security Trust Lockdown Helps

White Cloud Security Trust Lockdown is a Zero-Trust App Firewall that enforces a default-deny, approved-only software execution model. It does not rely on behavioral heuristics or signature matching as its primary defense. Instead, it requires that every executable, script, and importable component be explicitly approved before it can run — verified by handprint identity: a composite of multiple cryptographic hashes and file byte-length that uniquely identifies each file version.

The supply-chain attack scenario under Trust Lockdown

Consider the following scenario:

A Python-based AI proxy service is deployed on a server. The initial deployment is approved — all files, including the installed version of litellm and its dependencies, are verified against the organization's approved Trust List.
A routine update runs: pip install --upgrade litellm. The package manager downloads version 1.82.7, which includes new or modified files that were not part of the previously approved deployment.
When the application attempts to import or invoke the updated library — or when the Python interpreter initializes and processes the malicious .pth startup file — Trust Lockdown intercepts the execution attempt.
The new or modified files do not match any approved handprint in the Trust List. Trust Lockdown blocks execution before the malicious code runs.
The credential theft payload, the Kubernetes enumeration logic, and the persistence mechanism all fail to execute. No credentials are harvested. No lateral movement occurs. The alert fires at the moment of the blocked execution attempt, before any damage is done.

What this requires from your organization

Honest assessment: this level of protection requires policy discipline. Approved-only execution is not a passive defense that works out of the box in every environment. It requires:

An accurate baseline of what software is approved to run on each system
A change-control process for approving package updates before they reach production
Trust Lockdown policies deployed in Block Mode on the hosts where you want enforcement

Organizations that have not yet built that discipline can begin with Monitor Mode — which logs every execution event against the current policy without blocking — to understand what is running before moving to enforcement.

Where this matters most

The environments where a compromised AI component can do the most damage are also the environments where approved-only execution controls have the highest return:

CI/CD runners and build servers (access to pipeline secrets and signing credentials)
AI gateways and LLM proxy hosts (access to concentrated API key material)
Developer workstations with production credential access
Kubernetes nodes and admin hosts with cluster API access
Sensitive Linux hosts in platform and infrastructure teams

"At White Cloud Security, we continue to track and report new hacking methods and tools — not just because of its immediate threat, but because patterns of reuse often expose the playbooks of these cybercriminal groups."

How Trust Lockdown Interrupts the LiteLLM Supply-Chain Attack

Default-Allow vs Zero-Trust comparison

Recommended Immediate Actions

!!! warning "Recommended Immediate Actions"

Identify all systems where LiteLLM 1.82.7 or 1.82.8 may have been installed — check pip freeze outputs, requirements.lock files, container image build logs, and CI/CD dependency caches.
Isolate affected systems from production networks and privileged access paths while investigation is underway.
Rotate all API keys, cloud credentials, SSH keys, CI/CD secrets, and Kubernetes secrets that may have been accessible from affected environments. Treat any secret that was in scope as compromised until proven otherwise.
Review persistence mechanisms and startup paths on affected hosts — including .pth files in Python site-packages directories, cron entries, systemd units, and startup scripts.
Inspect Kubernetes environments for suspicious activity: unexpected service accounts, unusual role bindings, anomalous API server calls, or unexpected outbound connections from cluster nodes.
Move to a known-clean, confirmed-unaffected version of LiteLLM and pin your dependency specifications to prevent unintended upgrades.
Tighten application control and change approval workflows for AI infrastructure, CI runners, and platform hosts — and consider whether these environments should be operating under approved-only execution policy.

Key Takeaways

The legitimate litellm PyPI package was compromised — versions 1.82.7 and 1.82.8 — not a lookalike or typosquatted package.
LiteLLM confirmed that users of the official Proxy Docker image were not impacted; direct PyPI installations of the affected versions were at risk.
The incident may be connected to the broader TeamPCP / Trivy supply-chain activity, according to LiteLLM's security update.
Public reporting describes credential theft, Kubernetes-focused lateral movement, and persistence behavior — with one version using a .pth startup path to execute before the main application logic ran.
AI gateway components are high-value supply-chain targets because they handle concentrated privileged access across multiple providers and services.
Default-deny, approved-only software execution blocks malicious package components that are not on the approved Trust List — stopping the attack before credentials are harvested.
Treat any environment that ran an affected version as a potential credential exposure event and rotate secrets immediately.

The question that changes the outcome is whether each software component was explicitly approved to run on that host. AI infrastructure must be governed with positive control, not assumed trust. If your organization is deploying AI gateway infrastructure or Python-based automation at scale, explore how WCS Trust Lockdown enforces approved-only software execution.