The Python package ecosystem suffered another high-impact supply chain compromise: LiteLLM — a popular library that routes requests across large language model providers and sees tens of millions of downloads — shipped malicious code in recent PyPI releases. Two versions published on March 24, 2026 (1.82.7 and 1.82.8) contained an import‑time backdoor that escalates into credential harvesting, lateral movement, and a persistent remote access implant. For organizations that consume open-source packages as part of CI/CD, cloud automation, or developer tooling, this incident is a stark reminder that widely used infrastructure libraries are a prime target for sophisticated attackers.
What happened, in short
Attackers injected malicious payloads directly into the PyPI distributions for LiteLLM while the upstream GitHub repository remained clean. The compromise is attributed to a threat actor named TeamPCP, which has previously targeted developer tooling and supply chain infrastructure. The malicious behavior varied across the two infected releases:
- 1.82.7: A base64-encoded payload was inserted into litellm/proxy/proxy_server.py and executes on module import.
- 1.82.8: The attackers added both the proxy_server payload and a litellm_init.pth file at the root of the wheel; .pth files are processed by Python at interpreter startup, so the payload can run even if LiteLLM is never explicitly imported.
Both malicious versions have since been removed from PyPI, and the last known clean release is 1.82.6. But removal alone does not undo the damage for environments that already installed the package.
How the malware behaves
The injected code launches a multi-stage campaign designed for high-value reconnaissance and persistence:
- Stage 1 — Orchestration: On execution, an unpacker deploys a credential harvester that aggressively searches the host for sensitive secrets.
- Stage 2 — Data collection and exfiltration: The harvester targets SSH keys, cloud provider tokens (AWS, GCP, Azure), database credentials, and cryptocurrency wallets. Stolen artifacts are encrypted using AES-256-CBC combined with RSA-4096, bundled into an archive named tpcp.tar.gz, and exfiltrated to attacker-controlled infrastructure disguised as legitimate project resources.
- Stage 3 — Lateral movement and persistence: If it finds Kubernetes service account tokens, the malware enumerates cluster nodes and deploys privileged containers (alpine images) to gain host-level access. It also installs a user-level systemd service disguised as telemetry (~/.config/systemd/user/sysmon.service) to maintain a persistent backdoor that polls secondary C2 endpoints for additional payloads.
Why this is especially dangerous
Two aspects make this incident particularly severe:
- Interpreter startup execution via .pth: A malicious .pth file ensures the payload runs on any Python invocation that includes site-packages containing the compromised wheel — meaning the malware can execute in CI runners, developer machines, and production containers regardless of whether application code imports LiteLLM.
- Targeting developer and security tooling: TeamPCP’s campaign has focused on ecosystems that hold privileged secrets or run with broad access (GitHub Actions, Docker Hub, npm, OpenVSX). By compromising libraries used in build pipelines or deployment tooling, attackers maximize the chances of capturing high-value credentials and moving into production infrastructure.
Affected package versions
The original report included a packaged table of affected versions. Preserving that table here for clarity:
| Package Name | Version | Publication Date | Injection Vector | Status |
|---|---|---|---|---|
| litellm | 1.82.7 | 2026-03-24 | proxy_server.py (import-time) | Removed |
| litellm | 1.82.8 | 2026-03-24 | proxy_server.py + litellm_init.pth (interpreter startup) | Removed |
Indicators of Compromise (IoCs)
Below are the key IoCs published alongside the advisory — treat these as starting points for detection and hunting:
| Indicator | Type | Description |
|---|---|---|
| models.litellm.cloud | C2 Domain | Exfiltration endpoint for encrypted credential archives |
| checkmarx.zone/raw | C2 Endpoint | Payload delivery domain for the persistent backdoor |
| ~/.config/systemd/user/sysmon.service | Filesystem | Persistent systemd unit hiding the backdoor |
| tpcp.tar.gz | Archive | Named archive containing exfiltrated host data |
| node-setup-* | Kubernetes | Privileged attacker pods deployed in the kube-system namespace |
Immediate response checklist (recommended)
- Inventory and detection
- Scan environments (hosts, containers, CI runners) for installed LiteLLM versions and the presence of litellm_init.pth or modified proxy_server.py files.
- Hunt for the IoCs above and for unexpected ~/.config/systemd/user/sysmon.service units.
- Check recent outbound connections to the listed C2 domains and unusual archive creation patterns (tpcp.tar.gz).
- Containment and eradication
- If any compromised versions are found, isolate affected systems immediately and treat them as fully breached.
- Remove affected packages, but assume persistence may exist; do not rely on uninstall alone.
- Credential and secret rotation
- Rotate all potentially exposed credentials: SSH keys, cloud access keys, database credentials, service principals, and any tokens used in CI/CD.
- Revoke compromised Kubernetes service account tokens and inspect RBAC roles for abuse.
- Rebuild and redeploy
- Rebuild container images and artifacts from trusted, reproducible sources after clearing build caches and verifying dependency sources.
- Recreate CI runners and developer workstations where compromise is confirmed.
- Hardening and long-term changes
- Enforce reproducible builds and signed artifacts where possible.
- Add dependency provenance checks to CI (lockfiles, checksums, package signing).
- Limit where Python site-packages are writable; run builds in ephemeral, immutable environments.
- Implement network egress filtering for build and runtime environments to block unauthorized C2 domains.
Attribution and wider context
Security vendors Endor Labs and JFrog attributed the intrusion to TeamPCP, a group active in targeted supply chain disruption. Recent activity suggests a broader campaign that has hit multiple ecosystems and deliberately focused on security and developer tooling to harvest privileged secrets. This attack is consistent with a high-value, reconnaissance-first strategy aimed at long-term access rather than immediate ransom or disruption.
Final notes for security teams and developers
- Treat any detection of the compromised LiteLLM versions as a severe incident. The combination of interpreter-startup execution and aggressive secret harvesting increases the risk profile for both development infrastructure and production systems.
- Review dependency management practices: minimize transitive dependencies in build pipelines, pin and verify versions, and prefer verified sources for production images.
- Consider adding runtime detection for unusual process behaviors after Python commands and increase monitoring around artifact signing and publish processes within your organization.
Keeping open-source ecosystems healthy requires both better upstream protections and vigilant downstream controls. This compromise shows how one malicious release can ripple through organizations worldwide — the defensive response must be swift, broad, and systematic.
Licensed under CC BY-ND 4.0 International
What the Marquis Breach Teaches Us About Vendor Risk and Ransomware Preparedness
Marquis, a Texas-based provider of digital marketing, CRM and analytics services for…
Aura Exposed: When 900,000 Marketing Contacts Turned Into a Security Crisis
Aura, the consumer digital safety company known for identity protection and fraud…
Stryker Confirms Massive Wiper Strike — Thousands of Devices Erased in Alleged Iran-Linked Operation
Stryker, the global medical technology company, confirmed on March 11, 2026, that…
VoidLink Malware Framework: Key Points on How It Targets Kubernetes and AI Workloads
Title: VoidLink Malware Framework: Key Points on How It Targets Kubernetes and…