A sophisticated supply chain attack has compromised LiteLLM, the widely-used Python library for interfacing with large language models, delivering multi-stage credential-stealing malware to systems downloading over 95 million packages per month.
The attack, attributed to TeamPCP—the same threat group behind the recent Trivy supply chain compromises—targeted LiteLLM versions 1.82.7 and 1.82.8 on PyPI. According to Sonatype Security Research, the compromised packages were available for approximately two hours on March 24, 2026, before being quarantined. Given the package’s three million daily downloads, significant exposure likely occurred.
Why LiteLLM Is a High-Value Target
LiteLLM serves as a unified abstraction layer for applications interacting with LLMs from providers including OpenAI, Anthropic, Google, and others. Its position in the AI stack—sitting directly between applications and AI service providers—means it typically has access to API keys, environment variables, and sensitive configuration data. Compromising a package in this position allows attackers to intercept and exfiltrate valuable secrets without directly breaching upstream systems.
The library is a dependency for major AI agent frameworks including CrewAI, DSPy, Browser-Use, and Opik, dramatically expanding the attack’s potential blast radius.
Multi-Stage Payload Architecture
Analysis by Endor Labs reveals the attack involved a subtle but effective injection of just 12 lines of obfuscated code into litellm/proxy/proxy_server.py. The code executes automatically when the module is imported, decoding a large base64 payload and launching it via a Python subprocess.
In version 1.82.8, the attackers escalated by adding a litellm_init.pth file that ensures the payload runs every time the Python interpreter starts—even if LiteLLM is never imported.
The three-layer attack structure:
- Layer 1: Launcher and data exfiltration infrastructure
- Layer 2: Extensive reconnaissance and credential harvesting from SSH keys, AWS/GCP/Azure credentials, Kubernetes secrets, environment files, database configs, and cryptocurrency wallets
- Layer 3: Persistence mechanism via
sysmon.pyservice that polls C2 servers every 50 minutes for additional payloads
Harvested data is encrypted using AES-256-CBC with a randomly generated session key, which is then encrypted using a hardcoded RSA public key. The encrypted archive (tpcp.tar.gz) is exfiltrated to attacker-controlled infrastructure at models[.]litellm[.]cloud and checkmarx[.]zone.
Kubernetes Lateral Movement
Beyond data theft, the malware attempts lateral movement in Kubernetes environments by deploying privileged pods across all nodes in a cluster. These pods mount the host filesystem and install a persistent backdoor as a systemd user service named “System Telemetry Service,” enabling long-term access.
TeamPCP Attribution and LAPSUS$ Connection
Researchers linked the attack to TeamPCP with high confidence based on overlapping infrastructure, tooling, and techniques. Key attribution indicators include identical persistence mechanisms (~/.config/sysmon/sysmon.py), matching C2 domains, consistent exfiltration filenames, and shared Kubernetes-based propagation techniques observed in the group’s Trivy compromise operations.
There is also speculation that TeamPCP may be related to the LAPSUS$ extortion group, though attribution remains under active investigation.
Indicators of Compromise
- Compromised versions:
litellm==1.82.7andlitellm==1.82.8 - C2 domains:
models[.]litellm[.]cloud,checkmarx[.]zone - Artifacts:
tpcp.tar.gz,/tmp/pglog,/tmp/.pg_state - Persistence:
sysmon.pyservice,litellm_init.pth - Kubernetes pods:
node-setup-*
Mitigation Recommendations
Organizations should immediately:
- Verify whether LiteLLM versions 1.82.7 or 1.82.8 were installed
- Remove affected packages and treat impacted systems as fully compromised
- Rotate all potentially exposed credentials including API keys, cloud credentials, and Kubernetes secrets
- Review logs for suspicious outbound connections to the C2 domains
- Check for persistence mechanisms and unauthorized services
- Consider rebuilding affected systems from known clean states
For long-term defense, organizations should pin dependencies to verified versions, compare distributed packages against upstream source code, and adopt secure publishing mechanisms like PyPI Trusted Publishers.
Source: Sonatype Security Research, CyberInsider / Endor Labs
