On March 24, 2026, at 10:52 UTC, a compromised version of the Python package LiteLLM appeared on PyPI. There was no corresponding release tag on GitHub. No changelog. No pull request. Versions 1.82.7 and 1.82.8 were uploaded directly to the Python Package Index, bypassing the normal release process entirely, and they contained a multi-stage credential stealer designed to exfiltrate SSH keys, cloud provider tokens, Kubernetes secrets, and cryptocurrency wallets from every machine where the package ran.

LiteLLM is the open-source proxy library that gives AI applications a single interface to call over 100 large language model APIs, including OpenAI, Anthropic, Google Vertex AI, and Amazon Bedrock. It has over 40,000 stars on GitHub and approximately three million daily downloads from PyPI. According to cloud security vendor Wiz, LiteLLM is present in 36% of all cloud environments. It sits in the dependency chain of AI agent frameworks, MCP servers, and LLM orchestration tools. A compromise at this layer reaches far beyond any single application.

The threat actor behind the attack is TeamPCP, the same group that compromised Aqua Security’s Trivy vulnerability scanner on March 19 and Checkmarx’s KICS GitHub Action on March 23. The LiteLLM attack represents a deliberate escalation from CI/CD tooling into production infrastructure, and security researchers at multiple firms say the campaign is still active.

How the Compromise Happened

The attack began with Trivy. TeamPCP compromised the Trivy security scanner’s GitHub Actions, force-pushing release tags to point at malicious commits. LiteLLM used Trivy in its CI/CD security scanning workflow, which gave the attacker a foothold in LiteLLM’s build pipeline.

From there, TeamPCP likely compromised the PyPI account of LiteLLM co-founder and CEO Krish Dholakia. ReversingLabs researchers found that Dholakia’s GitHub profile was defaced in an automated sweep on March 24 at approximately 14:00 UTC. Commits were pushed to both the main LiteLLM repository and the litellm-skills repository containing malicious GitHub Action workflows with a known RSA public key associated with TeamPCP payloads.

BerriAI, the company behind LiteLLM, confirmed that “the compromise originated from the Trivy dependency used in our CI/CD security scanning workflow” and that “a maintainer’s PyPI account may have been compromised and used to distribute malicious code.”

A commit pushed to one of the maintainer’s forked repositories contained a single message: “teampcp owns BerriAI”.

The Three-Stage Payload

The malicious code operated in three distinct stages, according to analysis from Endor Labs, Sonatype, and FutureSearch.

Stage 1: Credential Harvesting. A Python script scanned the host machine for SSH private keys, .env files, AWS/GCP/Azure credentials, Kubernetes configurations, database passwords, Git credentials, shell history, and cryptocurrency wallet files. It also ran commands to dump environment variables and queried cloud metadata endpoints (IMDS, container credentials), meaning any machine running on AWS EC2, GKE, or similar cloud infrastructure had its instance-level credentials exposed.

Stage 2: Exfiltration. The collected data was encrypted with AES-256-CBC using a randomly generated session key, which was then encrypted with a hardcoded 4096-bit RSA public key. Everything was packaged into an archive (tpcp.tar.gz) and sent via HTTPS POST to models.litellm[.]cloud, a domain that BerriAI confirmed is not legitimate LiteLLM infrastructure.

Stage 3: Lateral Movement and Persistence. If a Kubernetes service account token was present, the malware enumerated all nodes in the cluster and deployed a privileged pod to each one. Each pod mounted the host filesystem using chroot and installed a persistent backdoor as a systemd user service (sysmon.service). This service polled checkmarx[.]zone/raw every 50 minutes for additional payloads. Sonatype researchers noted that when they attempted to retrieve the payload in a sandbox, the endpoint returned a YouTube link to a remastering of “Bad Apple!!” — an anti-analysis killswitch.

The two compromised versions delivered the payload through different mechanisms. Version 1.82.7 embedded the malicious code in litellm/proxy/proxy_server.py, which activated when the module was imported. Version 1.82.8 added a more aggressive vector: a .pth file (litellm_init.pth) placed at the wheel root. Python .pth files are processed automatically by site.py at interpreter startup, meaning the payload executed on every Python process in the environment, regardless of whether LiteLLM was ever explicitly imported.

The .pth launcher in 1.82.8 spawned a child process via subprocess.Popen, running the payload in the background. FutureSearch discovered the compromise when this mechanism created an unintentional fork bomb — the .pth file triggered on every Python startup, including the child processes it spawned — crashing a developer’s machine when an MCP plugin inside the Cursor IDE pulled the package as a transitive dependency.

Blast Radius

The compromised versions were available on PyPI for approximately two hours before being detected and removed. Given LiteLLM’s three million daily downloads, even that narrow window created significant exposure. BerriAI noted that customers running the official LiteLLM Proxy Docker image were not affected because that deployment path pins dependencies in requirements.txt. Users who installed via pip install litellm without a pinned version during the window, or whose projects pulled LiteLLM as an unpinned transitive dependency, are potentially compromised.

The Python Packaging Authority (PyPA) issued an advisory warning that “anyone who has installed and run the project should assume any credentials available to litellm environment may have been exposed, and revoke/rotate them accordingly.”

After the compromised versions were yanked, PyPI briefly quarantined the entire LiteLLM package. The quarantine was lifted later on March 24 once the maintainers regained control. BerriAI has paused all new releases pending a broader supply chain review.

A Broader Campaign Across Five Ecosystems

The LiteLLM compromise is the latest node in what security researchers describe as a coordinated, expanding supply chain campaign. TeamPCP has now hit five package ecosystems: GitHub Actions, Docker Hub, npm, Open VSX, and PyPI.

The timeline, as reconstructed by ReversingLabs:

  • March 19: TeamPCP compromises Aqua Security’s Trivy vulnerability scanner and related GitHub Actions, force-pushing malicious release tags.
  • March 23: Checkmarx VS Code extensions (checkmarx.ast-results v2.53 and checkmarx.cx-dev-assist v1.7.0) published to the Open VSX Registry with credential-stealing payloads. Checkmarx’s KICS GitHub Action also compromised.
  • March 23–24: LiteLLM maintainer’s GitHub account defaced. Malicious workflows pushed to litellm-skills repository.
  • March 24: LiteLLM versions 1.82.7 and 1.82.8 published to PyPI with the three-stage payload.

Each compromise generates credentials that feed the next attack. Endor Labs researcher Kiran Raj noted: “The pivot from CI/CD (GitHub Actions runners) to production (PyPI packages running in Kubernetes clusters) is a deliberate escalation.”

Socket’s security team described TeamPCP as conducting “a sustained operation targeting high-leverage points in the software supply chain.” On their Telegram channel, TeamPCP themselves posted: “These companies were built to protect your supply chains yet they can’t even protect their own.”

The LAPSUS$ Connection

Wiz, the cloud security vendor acquired by Google, reported that TeamPCP appears to be collaborating with the extortion group LAPSUS$. Ben Read, a Wiz lead researcher, said: “We are seeing a dangerous convergence between supply chain attackers and high-profile extortion groups like LAPSUS$. By moving horizontally across the ecosystem, hitting tools like liteLLM that are present in over a third of cloud environments, they are creating a ‘snowball effect.’”

Gal Nagli, Wiz’s head of threat exposure, wrote on X: “Trivy gets compromised → LiteLLM gets compromised → credentials from tens of thousands of environments end up in attacker hands → and those credentials lead to the next compromise. We are stuck in a loop.”

If the LAPSUS$ connection holds, the stakes escalate considerably. LAPSUS$ previously breached Microsoft, Nvidia, Samsung, Uber, and Rockstar Games through social engineering and credential theft. A partnership with a group that now has a proven pipeline into AI infrastructure dependency chains combines LAPSUS$‘s extortion playbook with direct access to production secrets at scale.

What This Means for AI Agent Infrastructure

LiteLLM occupies one of the most privileged positions in the modern AI stack. It typically holds API keys for multiple LLM providers, sits between applications and model endpoints, and often runs in environments with access to cloud credentials and Kubernetes service accounts. As Sonatype put it: “Compromising a package in this position allows attackers to intercept and exfiltrate valuable secrets without needing to directly breach upstream systems.”

The AI agent ecosystem is built on deeply nested dependency trees. An AI agent framework depends on LiteLLM, which uses Trivy for security scanning, which runs as a GitHub Action. A compromise anywhere in that chain cascades. The LiteLLM incident makes this concrete: a vulnerability scanner used to secure the build process became the attack vector that compromised the package.

For organizations running AI agent stacks, the immediate remediation steps are well-documented: check for versions 1.82.7 or 1.82.8, rotate all credentials on affected machines, audit Kubernetes clusters for rogue pods, and review network logs for egress to models.litellm[.]cloud and checkmarx[.]zone. BerriAI’s full advisory provides detailed instructions.

The harder question is structural. LiteLLM has 480 million total downloads, according to ReversingLabs. A single maintainer account compromise turned a two-hour window into a potential credential breach across 36% of cloud environments. Pinned dependencies and Docker image isolation protected some users. Most of the AI agent ecosystem, built on fast-moving pip installs and unpinned transitive dependencies, had no such buffer.

TeamPCP’s Telegram message ended with a promise: “Many of your favourite security tools and open-source projects will be targeted in the months to come.” They have not yet given anyone reason to doubt that.