Executive Summary

A severe malware incident (no formal CVE yet, but tracked as a high‑risk supply chain compromise) was disclosed affecting the widely used Python package LiteLLM (PyPI). Attackers from the TeamPCP threat group trojanized LiteLLM by publishing malicious versions 1.82.7 and 1.82.8, allowing them to harvest credentials and deploy backdoors when the package is installed or imported. Due to the potential large‑scale credential theft and persistent access, immediate mitigation is required.

Overview: The LiteLLM Supply Chain Attack

The issue stems from a compromised maintainer account and CI/CD abuse that injected malicious code into the package’s build artifacts. In the backdoored LiteLLM versions, attackers embedded payloads that execute at import time or even at every Python process startup via a crafted .pth file. These payloads harvest SSH keys, cloud provider credentials, Kubernetes secrets, crypto wallet keys, and other sensitive secrets from developer environments, and exfiltrate them to attacker infrastructure. In some cases, the malware also includes tools for Kubernetes lateral movement and a persistent systemd backdoor for ongoing access.

No authentication is required to trigger the malicious logic: simply installing or importing the affected LiteLLM versions can activate it. The components affected are LiteLLM PyPI package versions 1.82.7 and 1.82.8. LiteLLM is commonly used as a unified interface for calling dozens of large language models in Python applications, and its wide adoption means many development and CI/CD environments may have pulled these tainted releases.

The Impact

At the time of writing, both malicious versions have been removed from PyPI, but proof‑of‑concept exploitation is effectively embedded in the distributed code and there are reports of active credential collection. Regardless of formal exploit tooling, the ease of triggering the payload via normal package installation makes this high risk, especially for development environments with cloud access keys or deployment credentials.

Successful execution could allow attackers to steal cloud and crypto credentials, deploy backdoor services in Kubernetes clusters, and maintain persistent access to build and production systems, leading to data exposure, unauthorized resource usage, and full environment compromise.

Mitigation Recommendations

Users should immediately:

• remove any instances of LiteLLM 1.82.7 and 1.82.8 from their environments
• rotate all credentials and API keys that may have been present 
• pin to a known good version such as 1.82.6 or earlier until a verified patched release is published

Environments that installed the malicious versions—even transiently—should assume compromise and rotate secrets accordingly, as the malware is capable of silent exfiltration.

How can Orca help?

Orca enables customers to quickly identify assets running vulnerable or tainted package versions, understand their exposure in context—including internet accessibility, runtime reachability, and asset criticality—and prioritize remediation based on real risk rather than CVSS alone. Orca’s platform highlights affected assets directly in the newItem view, helping security teams focus on the most critical remediation paths first.