TeamPCP backdoored LiteLLM on PyPI after the Trivy compromise

LiteLLM was hit by the growing TeamPCP supply chain campaign on March 24, 2026, when attackers published two malicious PyPI versions, 1.82.7 and 1.82.8. Berri AI, which maintains LiteLLM, confirmed the compromise and said it traced back to a compromised Trivy security scan dependency in its CI/CD path.

The incident matters because the malicious packages did not just break builds. Security researchers say they contained a credential harvester, Kubernetes-focused lateral movement logic, and persistence mechanisms designed to survive beyond the initial install. Endor Labs said the payload targeted SSH keys, cloud credentials, Kubernetes secrets, cryptocurrency wallets, and .env files.

Anyone who installed and ran those compromised versions should assume secrets were exposed. Berri AI told users to rotate all credentials present as environment variables or config files on any system where LiteLLM 1.82.7 or 1.82.8 was installed.

What the malicious LiteLLM packages did

Endor Labs described the attack as a three-stage payload. It said the malware first harvested credentials, then attempted Kubernetes lateral movement by deploying privileged pods, and finally installed a persistent backdoor that polled attacker infrastructure for follow-on payloads.

Wiz reported that the two malicious LiteLLM versions used different execution methods. According to Wiz, version 1.82.7 ran the payload when litellm.proxy.proxy_server was imported or when litellm --proxy was used, while version 1.82.8 added a more dangerous .pth-based launcher that executed automatically whenever Python started.

That .pth detail matters because it widened the blast radius. Berri AI’s GitHub issue says litellm_init.pth ran automatically at Python interpreter startup, which meant the attacker did not need the victim to import LiteLLM directly after installation.

LiteLLM compromise at a glance

Item	Confirmed details
Affected package	LiteLLM on PyPI
Malicious versions	1.82.7 and 1.82.8
First public detection	March 24, 2026
Confirmed by maintainer	Yes, Berri AI confirmed compromise
Likely initial source	Compromised Trivy scan dependency in CI/CD
Most dangerous mechanism	.pth auto-execution in version 1.82.8

Why version 1.82.8 was worse

Version 1.82.8 appears to have been the more dangerous of the two releases. Berri AI issue reports and Wiz’s analysis both say the wheel contained a malicious litellm_init.pth file placed at the wheel root, causing code to run automatically on Python startup.

Wiz says the .pth launcher spawned a child Python process in the background, which made the behavior stealthier and less tied to normal LiteLLM execution. That means environments with Python installed, including developer workstations, CI runners, and production containers, could trigger the payload in broader circumstances than users might expect.

By contrast, 1.82.7 appears to have relied on code injected into litellm/proxy/proxy_server.py, which still made it dangerous but somewhat more tied to module import or proxy-specific execution paths.

How this connects to the wider TeamPCP campaign

The LiteLLM incident did not happen in isolation. Endor Labs and Wiz both frame it as a follow-on attack tied to TeamPCP’s earlier compromises involving Trivy and other supply chain components. In that sense, LiteLLM looks like a pivot target chosen because upstream CI/CD exposure yielded fresh credentials for the next stage.

That pattern matches the public statement from Endor Labs, which warned that the campaign was likely still expanding. Its researchers said TeamPCP had shown a consistent pattern where one compromised environment yielded credentials that unlocked the next target.

Wiz made the same broader point in stronger terms, saying the compromise reflected an ecosystem-wide cascade where one breach fed the next. That framing fits what defenders have already seen across Trivy, KICS, and other TeamPCP-linked incidents.

What teams should check immediately

• Whether any environment installed LiteLLM 1.82.7 or 1.82.8
• Whether litellm_init.pth exists in site-packages
• Outbound traffic to models.litellm.cloud or checkmarx.zone
• Unusual privileged pods in Kubernetes clusters
• Unexpected systemd persistence such as sysmon.service

What Berri AI and defenders say to do now

Berri AI says compromised packages 1.82.7 and 1.82.8 were removed, maintainer accounts were rotated, and no new LiteLLM releases would ship until the release chain had been reviewed. It also said LiteLLM proxy Docker image users were not impacted because dependencies were pinned in requirements.txt.

The response for exposed users is more urgent. Berri AI says anyone who had those versions installed should rotate all credentials that were present as environment variables or config files on the affected system. PyPI-related advisories and third-party vendor reports echo that same guidance.

Security teams should also isolate affected hosts, check Kubernetes clusters for rogue pods, remove persistence, and audit CI/CD workflows that used Trivy or KICS during the compromise windows. Those steps appear consistently across vendor guidance and fit the malware behavior reported by Endor Labs and Wiz.

FAQ