Supply chain attack hit Python package LiteLLM. Malicious versions stole keys and spread through Kubernetes environment

Kompromitované verze byly publikovány na PyPI

Security companies Endor Labs, JFrog and Wiz reported that the LiteLLM package on PyPI was published on 24 March 2026 in two malicious versions — 1.82.7 and 1.82.8. Both versions were subsequently removed or blocked. According to Endor Labs, the last known clean version is 1.82.6.

LiteLLM is a popular open-source library used to work with multiple large language model providers through a unified API. Its wide adoption is what makes this incident a significant supply-chain problem.

Co malware dělal

According to the published analyses, it was a multi-stage attack. The malicious code collected sensitive data from the system, including SSH keys, cloud credentials, Kubernetes tokens, .env files, Docker configurations, and other secrets available in the environment.

The collected data was then exfiltrated to attacker-controlled infrastructure. Researchers specifically mention the domains models.litellm[.]cloud and checkmarx[.]zone/raw in connection with the attack.

In Kubernetes environments the malware also used the service account token, enumerated cluster nodes, and attempted to deploy privileged pods onto them. Those pods were intended to enable further propagation and to install persistence at the host level.

Verze 1.82.8 byla ještě nebezpečnější

While version 1.82.7 contained malicious code in the file litellm/proxy/proxy_server.py and executed the payload when a specific module was imported, version 1.82.8 also added the file litellm_init.pth.

That is what made it a significantly more dangerous variant. .pth files in a Python environment can be processed automatically at interpreter startup, so the malicious code could run during Python execution even without explicitly importing LiteLLM.

Původ kompromitace

According to the LiteLLM maintainer, the PyPI publishing access was compromised and the malicious versions were not released via the standard official GitHub CI/CD pipeline. Researchers at Wiz also stated that a PyPI advisory links the incident to an API token exposed during a previous Trivy compromise.

It is therefore most accurate to say that the attack on LiteLLM was part of the broader follow-on TeamPCP campaign, which leverages previously obtained access and progressively spreads across other tools and registries.

Proč je incident důležitý

According to Wiz, LiteLLM is present in approximately 36% of cloud environments, which significantly increases the potential impact of the incident. If the package was deployed in CI/CD, in containers, or in production Kubernetes environments, an attacker could have gained access to other systems, secrets, and infrastructure.

The incident thus clearly demonstrates how quickly a supply-chain compromise can propagate from one tool to other parts of the modern cloud-native and AI stack.

Co by měli správci udělat

Organizations should immediately check whether versions 1.82.7 or 1.82.8 were installed or run anywhere. If so, such environments must be isolated, investigated for signs of compromise, suspicious pods in Kubernetes should be inspected, and outbound communication to the mentioned domains should be analyzed.

At the same time, all credentials available in the affected environment should be considered potentially compromised and rotated.

Shrnutí

LiteLLM is another victim of the TeamPCP campaign, which spread across multiple parts of the open-source ecosystem over the course of a few days. It's not just one malicious package, but an example of a chained supply-chain attack where the compromise of one tool opens the way to others.

For teams using LiteLLM in AI, cloud, or Kubernetes environments, this is an incident with very practical impact: you need to quickly verify versions, inspect infrastructure, and assume that some credentials may have been exfiltrated.