USA
India
APAC
Middle East
Global
LiteLLM Supply Chain Compromise: When Your AI Dependency Becomes an Attack Vector
What happens when the tools your developers trust the most become the weapons used against you? That is not a hypothetical — it is exactly what TeamPCP pulled off with their latest campaign. By slipping malicious code into LiteLLM versions 1.82.7 and 1.82.8 on PyPI, the attackers turned a widely-adopted AI proxy library into a credential harvester, a Kubernetes worm, and a persistent backdoor — all at once.
This was not an opportunistic smash-and-grab. It was a deliberate, multi-stage escalation by a threat group that has been quietly working its way up the software supply chain — from security scanners, to developer tools, and now directly into production AI workloads. If your organisation uses LiteLLM, the time to act is now.
Affected Versions: LiteLLM v1.82.7 and v1.82.8 are confirmed malicious. Safe versions: ≤ 1.82.6. If you have either affected version installed, treat your environment as compromised until remediation is complete.
Attack Overview
The TeamPCP threat group executed a large-scale software supply chain attack by compromising the LiteLLM Python package on PyPI. The malicious versions embedded hidden payloads capable of three distinct functions: credential harvesting, Kubernetes cluster propagation, and persistent remote access via a disguised backdoor service.
The attack targeted sensitive environments including cloud infrastructure, CI/CD pipelines, and Kubernetes clusters — some of the most critical components in modern software delivery. The payload triggered automatically on import, requiring no user interaction beyond a routine package install or update.
Technical Breakdown
Initial Compromise Vector
The attackers uploaded two trojanised versions of LiteLLM to PyPI — v1.82.7 and v1.82.8. The malicious payload was inserted into:
litellm/proxy/proxy_server.py (base64-encoded payload) |
Execution was triggered automatically when the module was imported — a common and effective technique that requires zero additional interaction from the victim. Any environment that ran a routine pip install or upgrade during the exposure window could be affected.
Advanced Persistence in v1.82.8
Version 1.82.8 introduced a particularly insidious persistence mechanism: a malicious .pth file.
litellm_init.pth → placed in site-packages |
Python .pth files are executed on every interpreter startup — regardless of whether LiteLLM is ever imported again. This means that even if the package is uninstalled, the backdoor persists. The payload used subprocess.Popen to spawn background execution and evade detection tools that only monitor package-level activity.
Stage 1 — Credential Harvesting
Once triggered, the malware immediately began collecting sensitive data from the compromised environment:
- SSH keys and configurations
- Cloud credentials — AWS, GCP, Azure
- Kubernetes tokens and secrets
- Environment variables and .env files
- Database credentials
- TLS private keys and CI/CD secrets
- Cryptocurrency wallets
System reconnaissance was also performed to profile the target:
hostname | whoami | uname -a | ip addr | printenv |
Stage 2 — Kubernetes Lateral Movement
If a Kubernetes service account token was available in the environment, the malware escalated its impact dramatically. It enumerated all cluster nodes, then deployed privileged pods on each node — named with the pattern node-setup-{node_name} using an alpine:latest base image.
Each deployed pod performed a chroot into the host filesystem, enabling the attackers to:
- Read and exfiltrate any file on the underlying host node
- Install persistence mechanisms directly on the host OS
- Propagate the compromise across the entire Kubernetes cluster
Stage 3 — Persistent Remote Access
The final stage installed a systemd-based backdoor, deliberately disguised to blend into a legitimate system service:
Service Name: System Telemetry Service Binary Path: ~/.config/sysmon/sysmon.py Service File: ~/.config/systemd/user/sysmon.service
C2 Polling: checkmarx[.]zone/raw (every ~50 minutes) Kill-switch: Stops execution if C2 response contains youtube[.]com |
Data Exfiltration
Harvested credentials and system data were packaged into an encrypted archive and exfiltrated over HTTPS:
Archive: /tmp/tpcp.tar.gz Exfil Channel: HTTPS POST Destination: models.litellm[.]cloud |
Attribution: TeamPCP and the Expanding Campaign
This attack is attributed to TeamPCP, a threat group that has systematically targeted trust points in the software supply chain. Their progression tells a clear story of deliberate escalation — each compromised tool providing broader access than the last.
The campaign now spans multiple ecosystems: PyPI, GitHub Actions, Docker Hub, npm, and Open VSX. This multi-platform reach is not accidental — it reflects a systematic strategy to compromise assets at every layer of the modern development and deployment pipeline.
Key Insight: The abuse of security tools — Trivy is a vulnerability scanner — as attack vectors creates a particularly dangerous blind spot. Organisations that trust their security tooling implicitly are most at risk. When the scanner itself is compromised, it can disable or circumvent the very controls designed to catch it.
Evasion Techniques
TeamPCP employed several techniques to evade detection and prolong persistence:
- Base64 obfuscation of the embedded payload in proxy_server.py
- Background execution via subprocess.Popen to avoid foreground process monitoring
- Abuse of Python .pth auto-loading — persists even after package removal
- Systemd service disguised as ‘System Telemetry Service’ to blend with legitimate processes
- Kill-switch mechanism: execution halts if C2 response contains youtube[.]com — a technique to disable payload in sandboxed/analysis environments
- Reuse of tooling and infrastructure from previous Trivy compromise
Indicators of Compromise (IOCs)
File Hashes (SHA-256)
71e35aef03099cd1f2d6446734273025a163597de93912df321ef118bf135238 a0d229be8efcb2f9135e2ad55ba275b76ddcfeb55fa4370e0a522a5bdee0120b 6cf223aea68b0e8031ff68251e30b6017a0513fe152e235c26f248ba1e15c92a |
Network Indicators
https://models.litellm[.]cloud (data exfiltration endpoint) https://checkmarx[.]zone/raw (C2 polling endpoint) |
Filesystem Artefacts
~/.config/sysmon/sysmon.py ~/.config/systemd/user/sysmon.service /tmp/tpcp.tar.gz /tmp/session.key /tmp/payload.enc /tmp/session.key.enc /tmp/.pg_state /tmp/pglog |
Kubernetes Indicators
Rogue pod name pattern: node-setup-{node_name} Pod image: alpine:latest |
Recommendations
Immediate Actions (Priority)
Act Now: If LiteLLM v1.82.7 or v1.82.8 is installed anywhere in your environment, treat the system as compromised. Begin credential rotation and forensic investigation immediately, in parallel with remediation.
- Check your installed LiteLLM version and remove v1.82.7 / v1.82.8 immediately.
- Reinstall from a safe version (≤ 1.82.6) or validate a patched release before deploying.
- Rotate all credentials — API keys, SSH keys, cloud credentials (AWS/GCP/Azure), database credentials, Kubernetes secrets, Git and Docker tokens.
- Revoke and regenerate all PyPI and CI/CD tokens.
- Search for and remove persistence files: ~/.config/sysmon/sysmon.py
- Disable and delete the malicious systemd service: service
- Inspect and clean all Python .pth files in site-packages directories.
- Check for suspicious archive or payload files in /tmp (tpcp.tar.gz, payload.enc, session.key).
Network and Kubernetes
- Block all traffic to models.litellm[.]cloud and checkmarx[.]zone at the firewall and DNS level.
- Audit your Kubernetes cluster for rogue pods matching the node-setup-* pattern and delete them.
- Rotate all Kubernetes cluster secrets and service account tokens.
- Review RBAC policies and restrict service account permissions to least-privilege.
Longer-Term Hardening
- Review and secure all CI/CD pipelines — particularly any using Trivy, which was previously compromised by the same group.
- Replace long-lived static secrets with short-lived, OIDC-based authentication wherever possible.
- Implement package integrity verification (e.g., hash pinning) for all PyPI dependencies in production environments.
- If a compromise is strongly suspected and full remediation is not possible, consider a full system rebuild.
Conclusion
The LiteLLM compromise is not an isolated incident — it is the latest move in a methodical, multi-ecosystem campaign by TeamPCP to exploit the trust developers place in open-source tooling. By targeting a widely-used AI infrastructure library, the attackers gained direct access to some of the most sensitive assets in modern cloud environments: credentials, secrets, and Kubernetes clusters.
The abuse of security tools as attack vectors is particularly dangerous, because it undermines the very mechanisms organisations rely on for protection. When your vulnerability scanner, your dependency proxy, and your AI library can all become weapons, perimeter defences alone are no longer sufficient.
Organisations must treat supply chain security as a first-class concern — with continuous monitoring of package integrity, strict dependency pinning, and rapid incident response capabilities. The sophistication of this campaign is a clear signal: the attackers are not slowing down, and neither should your defences.
If you suspect a breach or notice any unusual activity in your environment, don’t wait. Get in touch with SISA Sappers immediately for expert incident response and forensic support. Talk to our DFIR experts today – Digital Forensics Services dfir
References
- https://docs.litellm.ai/blog/security-update-march-2026
- https://snyk.io/articles/poisoned-security-scanner-backdooring-litellm/
- https://research.jfrog.com/post/litellm-compromised-teampcp/
Facebook
Linkedin 
X
Youtube
