# How LiteLLM Turned Developer Machines Into Credential Vaults for Attackers
## The AI Gateway That Became a Backdoor
The most active piece of enterprise infrastructure in any company isn't the production server cluster or the CI/CD pipeline — it's the developer workstation. That laptop is where credentials are created, tested, cached, copied, and reused across services, bots, build tools, and now local AI agents. In March 2026, a threat group known as TeamPCP proved just how valuable those machines are. Their supply chain attack on LiteLLM, the wildly popular open-source AI gateway proxy downloaded roughly 3.4 million times per day, turned an ordinary pip install into a full-spectrum credential harvesting operation. Within a 40-minute window on March 24, the compromised package was pulled over 119,000 times — and the fallout is still being measured.
## Background and Context
LiteLLM occupies a uniquely privileged position in the modern AI development stack. It serves as a unified proxy layer that lets developers route requests across dozens of LLM providers — OpenAI, Anthropic, Google, Azure, AWS Bedrock, and more — through a single interface. By design, it needs access to API keys for every provider it touches. That architectural reality made it an irresistible target.
The attack didn't start with LiteLLM itself. TeamPCP first compromised Trivy, an open-source vulnerability scanner maintained by Aqua Security and widely trusted across the industry. The irony is sharp: a security tool became the attack vector. By poisoning a Trivy GitHub Action used in LiteLLM's CI/CD pipeline, TeamPCP obtained the maintainer's PyPI credentials — then used those credentials to publish two backdoored versions of the litellm package (1.82.7 and 1.82.8) directly to PyPI on March 24, 2026, starting at 10:39 UTC.
PyPI quarantined the packages approximately 40 minutes later, aided by 13 independent malware reports from vigilant community members and automated detection by Sonatype's monitoring tooling, which flagged the anomalous release within seconds of publication. But in those 40 minutes, over 119,000 downloads occurred — and 1,705 downstream PyPI packages were configured to automatically pull the compromised versions as dependencies.
## Technical Details
The payload was sophisticated, multi-staged, and designed for maximum credential extraction with minimal detection.
The attack began with a malicious .pth file (litellm_init.pth) embedded in the package. Python .pth files execute automatically on every Python process startup when present in the environment's site-packages directory — meaning the malware activated not just when importing litellm, but whenever *any* Python script ran in that environment. This persistence mechanism ensured broad execution coverage even if the developer never explicitly called LiteLLM functions.
Once triggered, the payload executed a systematic sweep of the compromised machine, targeting an extensive inventory of credential types:
~/.kube/config), Docker registry tokens, Helm values files.bash_history, .zsh_history, and all .env filesThe exfiltration was carefully engineered. All harvested data was encrypted using a randomly generated AES-256-CBC session key, which was then wrapped with a hardcoded RSA-4096-OAEP public key — ensuring only the attacker could decrypt the bundle. The encrypted payload was transmitted via HTTPS POST to models.litellm.cloud, a domain designed to blend into normal LiteLLM traffic patterns.
But credential theft was only stage one. The malware also attempted lateral movement across Kubernetes clusters accessible from the compromised machine, leveraging stolen kubeconfig files to enumerate and access adjacent services. In stage three, it installed a persistent systemd service configured to poll for additional payloads, establishing a long-term foothold independent of the original Python package.
## Real-World Impact
The scale of exposure was staggering. GitGuardian's post-incident analysis identified 33,185 secrets exposed across 6,943 machines, with 3,760 credentials confirmed still active at the time of disclosure. Because LiteLLM sits at the intersection of cloud infrastructure and AI services, compromised machines typically yielded not just one or two credentials but entire portfolios of access tokens spanning multiple cloud providers, SaaS platforms, and internal services.
The downstream dependency chain amplified the blast radius further. With 1,705 packages automatically pulling the compromised versions, organizations that never directly installed LiteLLM found themselves exposed through transitive dependencies — a hallmark of modern supply chain attacks.
Perhaps the most consequential breach traced to this campaign occurred at the European Commission. CERT-EU attributed a major data breach — involving 92 GB of compressed data exfiltrated from the Commission's AWS infrastructure — to TeamPCP, with the initial access vector traced back through the Trivy compromise chain.
## Threat Actor Context
TeamPCP, also tracked under aliases including DeadCatx3, PCPcat, ShellForce, and PersyPCP, has been documented by CrowdStrike, Wiz, and SANS as a cloud-native threat actor specializing in exploiting misconfigured Docker APIs, Kubernetes clusters, and Redis servers. The group maintains a public presence on X (formerly Twitter) under the handle @pcpcats.
What distinguishes TeamPCP's March 2026 campaign is its ambition and sophistication. Rather than targeting a single ecosystem, the group executed a month-long campaign spanning five ecosystems: GitHub Actions, Docker Hub, npm (via the CanisterWorm malware), OpenVSX, and PyPI. By first compromising security tools — Trivy and Checkmarx's KICS — TeamPCP demonstrated an understanding that security tooling often runs with elevated privileges and occupies trusted positions in CI/CD pipelines. Poisoning the scanner to compromise the scanned represents a fundamental inversion of the security model that many organizations rely on.
## Defensive Recommendations
Organizations should treat this incident as an assumed-breach scenario if any system ran litellm 1.82.7 or 1.82.8 during the exposure window. Immediate actions include:
1. Rotate everything: Assume any credential present on an affected machine is compromised. This includes SSH keys, cloud provider credentials, Kubernetes configs, API keys stored in .env files, database passwords, and LLM provider tokens.
2. Audit transitive dependencies: Check whether any installed packages pulled the compromised LiteLLM versions as indirect dependencies. Tools like pip-audit and safety can assist.
3. Search for persistence mechanisms: Look for unexpected systemd services or .pth files in Python site-packages directories. The systemd backdoor polls for additional payloads and may survive package removal.
4. Adopt Trusted Publishers: PyPI's Trusted Publishers feature ties package uploads to verified CI/CD workflows, eliminating the risk of credential-based package uploads. LiteLLM has since adopted this mechanism.
5. Pin and verify dependencies: Use hash-pinned requirements and verify package checksums against known-good values. Automated pull of latest versions without verification is the core enabler of supply chain attacks.
6. Monitor .pth files: Add detection for new or modified .pth files in Python environments — these execute silently and are frequently overlooked by endpoint security tools.
7. Segment developer environments: Developer workstations should not have persistent access to production credentials. Use short-lived tokens, credential vaulting with just-in-time access, and separate environments for development and production.
## Industry Response
The security community's response has been swift and multi-layered. PyPI's incident report, published April 2, detailed the timeline and collaborative remediation with both LiteLLM and Telnyx (which suffered a parallel compromise). The platform credited its community-driven malware reporting feature, reintroduced in 2024, with accelerating the quarantine timeline.
Microsoft published detailed detection and investigation guidance for organizations using Trivy in their CI/CD pipelines. Datadog Security Labs, Trend Micro, Snyk, and Kaspersky all released independent technical analyses, providing IOCs and detection signatures. SANS Institute published a comprehensive case study examining how security scanners can themselves become weapons.
The incident has reignited industry debate about the fragility of the open-source supply chain, particularly as AI tooling rapidly becomes foundational infrastructure. The fact that a single compromised security scanner could cascade into credential theft across thousands of machines — through a package that exists specifically to manage API keys — illustrates a systemic risk that no single technical control can fully address.
The developer workstation has always been a high-value target. LiteLLM simply proved that in the age of AI agents, it has become the single richest credential store in the enterprise — and the supply chain is the shortest path to it.
---
**