LiteLLM supply chain attack on March 24, 2026 compromised two PyPI versions of the popular Python library with a three-stage credential stealer. The malicious code collected SSH keys, cloud credentials, Kubernetes secrets and LLM API keys, encrypted them and transmitted them to an attacker-controlled domain. According to multiple security vendors, the attack is attributed to the same group that had compromised the Trivy scanner just days earlier.
LiteLLM supply chain attack originated from the Trivy compromise
LiteLLM is a Python library that serves as a unified interface to over 100 AI model providers. It is downloaded approximately 3.4 million times per day from PyPI, with the majority being automated CI/CD runs. Circulating victim counts in the hundreds of thousands are unsubstantiated and should be treated with caution.
An LiteLLM supply chain attack report with all verified IOCs, detection commands and a four-phase incident response playbook is available for download.wiwiki
The attack path led through the Trivy CI/CD integration that had been compromised days earlier, which was covered in detail in a previous post. LiteLLM’s build pipeline used Trivy as a security scanner and installed it without version pinning. The compromised Trivy version exfiltrated a PyPI publish token from the GitHub Actions runner environment. Using this token, the threat actor TeamPCP uploaded two malicious versions directly to PyPI, bypassing the regular GitHub release process. Two-factor authentication was active on the maintainer accounts but was circumvented through the stolen API token. LiteLLM’s CEO confirmed this sequence publicly.
How the malicious code in the compromised versions works
Version 1.82.7, published on March 24 at 10:39 UTC, contained twelve lines of obfuscated Base64 code in the file proxy_server.py, executed upon importing the LiteLLM proxy module. Thirteen minutes later, version 1.82.8 followed with an additional, significantly more aggressive vector: a .pth file in the wheel root that Python automatically processes at every interpreter startup. This meant that not just importing the library, but any Python process in the affected environment triggered the malicious code — including pip, pytest or an IDE’s language server. A bug in this implementation caused uncontrolled process multiplication leading to RAM exhaustion, which is what led a developer at FutureSearch to discover the compromise.
The payload operated in three stages: First, it systematically collected credentials from the host, including SSH keys, AWS, GCP and Azure credentials, Kubernetes configurations, database passwords, Git credentials, shell histories and cryptocurrency wallets. It then encrypted the collected data with AES-256-CBC and RSA-4096 and transmitted it to the C2 domain models.litellm[.]cloud, which had been registered the day before. In a third stage, the malicious code installed a persistent backdoor at ~/.config/sysmon/sysmon.py with an accompanying systemd service and attempted to deploy privileged pods on every node in Kubernetes environments.
Who may be affected by the LiteLLM supply chain attack
PyPI quarantined the package at approximately 13:38 UTC, with final deletion of the compromised versions taking place in the afternoon. The conservative exposure window therefore extends from 10:39 to approximately 15:00 UTC. According to the official statement, users of the LiteLLM Docker image, the cloud variant or installations directly from the GitHub repository were not affected. However, any environment that performed an unpinned pip installation of LiteLLM during this window is potentially affected. This explicitly includes transitive installations: the initial discoverer at FutureSearch had never consciously installed LiteLLM — it was pulled in as a dependency by a Cursor MCP plugin.
All documented IOCs and persistence mechanisms to date relate to Linux systems. Whether and how the malicious code affects Windows or macOS is not documented at the time of publication, although the .pth mechanism itself is cross-platform.
What organisations should do now
To check whether systems are affected, run pip show litellm on all machines, CI/CD runners and Docker images, and search for the file litellm_init.pth in site-packages directories. If versions 1.82.7 or 1.82.8 are found, all credentials accessible on the affected system must be treated as compromised and rotated. This applies equally to SSH keys, cloud provider credentials, Kubernetes secrets, LLM API keys, database passwords and CI/CD tokens.
This incident is part of an ongoing campaign that, according to Endor Labs, Snyk and Wiz, has now traversed five ecosystems. The operational takeaway therefore extends beyond this individual case: pin dependencies, replace publish tokens with trusted publishing, introduce egress monitoring for development environments and stop treating CI/CD runners as trusted infrastructure — instead, treat them for what they are: potentially exposed systems.
LiteLLM supply chain attack originated from the Trivy compromise
The LiteLLM supply chain attack on March 24, 2026 compromised two PyPI versions of the popular Python library with a three-stage credential stealer. The malicious code collected SSH keys, cloud credentials, Kubernetes secrets and LLM API keys, encrypted them and transmitted them to an attacker-controlled domain. According to multiple security vendors, the attack is attributed to the same group that had compromised the Trivy scanner just days earlier.
LiteLLM is a Python library that serves as a unified interface to over 100 AI model providers. It is downloaded approximately 3.4 million times per day from PyPI, with the majority being automated CI/CD runs. Circulating victim counts in the hundreds of thousands are unsubstantiated and should be treated with caution.
An LiteLLM supply chain attack report with all verified IOCs, detection commands and a four-phase incident response playbook is available for download.
The attack path led through the Trivy CI/CD integration that had been compromised days earlier, which was covered in detail in a previous post. LiteLLM’s build pipeline used Trivy as a security scanner and installed it without version pinning. The compromised Trivy version exfiltrated a PyPI publish token from the GitHub Actions runner environment. Using this token, the threat actor TeamPCP uploaded two malicious versions directly to PyPI, bypassing the regular GitHub release process. Two-factor authentication was active on the maintainer accounts but was circumvented through the stolen API token. LiteLLM’s CEO confirmed this sequence publicly.
How the malicious code in the compromised versions works
Version 1.82.7, published on March 24 at 10:39 UTC, contained twelve lines of obfuscated Base64 code in the file proxy_server.py, executed upon importing the LiteLLM proxy module. Thirteen minutes later, version 1.82.8 followed with an additional, significantly more aggressive vector: a .pth file in the wheel root that Python automatically processes at every interpreter startup. This meant that not just importing the library, but any Python process in the affected environment triggered the malicious code — including pip, pytest or an IDE’s language server. A bug in this implementation caused uncontrolled process multiplication leading to RAM exhaustion, which is what led a developer at FutureSearch to discover the compromise.
The payload operated in three stages: First, it systematically collected credentials from the host, including SSH keys, AWS, GCP and Azure credentials, Kubernetes configurations, database passwords, Git credentials, shell histories and cryptocurrency wallets. It then encrypted the collected data with AES-256-CBC and RSA-4096 and transmitted it to the C2 domain models.litellm[.]cloud, which had been registered the day before. In a third stage, the malicious code installed a persistent backdoor at ~/.config/sysmon/sysmon.py with an accompanying systemd service and attempted to deploy privileged pods on every node in Kubernetes environments.
Who may be affected by the LiteLLM supply chain attack
PyPI quarantined the package at approximately 13:38 UTC, with final deletion of the compromised versions taking place in the afternoon. The conservative exposure window therefore extends from 10:39 to approximately 15:00 UTC. According to the official statement, users of the LiteLLM Docker image, the cloud variant or installations directly from the GitHub repository were not affected. However, any environment that performed an unpinned pip installation of LiteLLM during this window is potentially affected. This explicitly includes transitive installations: the initial discoverer at FutureSearch had never consciously installed LiteLLM — it was pulled in as a dependency by a Cursor MCP plugin.
All documented IOCs and persistence mechanisms to date relate to Linux systems. Whether and how the malicious code affects Windows or macOS is not documented at the time of publication, although the .pth mechanism itself is cross-platform.
What organisations should do now
To check whether systems are affected, run pip show litellm on all machines, CI/CD runners and Docker images, and search for the file litellm_init.pth in site-packages directories. If versions 1.82.7 or 1.82.8 are found, all credentials accessible on the affected system must be treated as compromised and rotated. This applies equally to SSH keys, cloud provider credentials, Kubernetes secrets, LLM API keys, database passwords and CI/CD tokens.
This incident is part of an ongoing campaign that, according to Endor Labs, Snyk and Wiz, has now traversed five ecosystems. The operational takeaway therefore extends beyond this individual case: pin dependencies, replace publish tokens with trusted publishing, introduce egress monitoring for development environments and stop treating CI/CD runners as trusted infrastructure — instead, treat them for what they are: potentially exposed systems.
