What was the LiteLLM Supply Chain Attack?

Introduction

The modern software development ecosystem is built on a foundation of shared trust. In March 2026, that trust was exploited by one of the most widely used Python libraries in the artificial intelligence space. LiteLLM, a package that provides developers with a unified interface to dozens of large language model providers, is downloaded millions of times each day and embedded as a dependency across a vast range of AI-powered tools and frameworks.

Its large-scale application made it an ideal target. Instead of tricking individual developers into downloading malware, a threat actor hijacked the package’s publishing pipeline and let ordinary development workflows do the rest. When malicious versions of LiteLLM appeared on the Python Package Index on March 24, 2026, tens of thousands of developers and automated systems pulled them down within hours.

The attack is one of the most consequential open-source security incidents of the year and a defining example of how the speed and scale of modern software dependency management can evolve into a global threat.

Attack Summary

According to Steven Thoemmes of Snyk, versions 1.82.7 and 1.82.8 of LiteLLM were published by a threat actor known as TeamPCP after they obtained the maintainer’s PyPi credentials through a prior compromise of Trivy. These packages were uploaded directly to PyPI with no corresponding tag or commit to the project’s official GitHub repository.

This was a clear sign that they had bypassed the normal release workflow entirely. Each package contained a hidden Python path configuration file that Python loads automatically on every interpreter startup, meaning the payload executed the moment the package was present in an environment. The malware operated in three sequential stages.

These phases included a collection phase, which collected valuable data, an encryption and exfiltration phase, which encrypted the harvested data, and a persistence and lateral movement phase, which attempted to deploy a privileged backdoor container across every node in the cluster and install a persistent local service that would survive system restarts.

According to Steven of Snyk, the malware also “reads all secrets across every namespace”. More than 40,000 downloads of the compromised versions were recorded before PyPI administrators were able to quarantine them. The sophistication of the payload made it capable of turning a single developer’s laptop into a foothold for a much broader organizational compromise.

How the Attack Occurred and How It Was Discovered

The initial access that made this attack possible was obtained not by exploiting LiteLLM directly, but by leveraging a vulnerability in Trivy, an open-source security scanner that had been integrated into the project’s publishing pipeline. The threat actor was able to obtain the credentials necessary to push packages to PyPI on behalf of the LiteLLM project, without those packages ever passing through the repository’s standard review or approval process.

According to Security Labs’ research team, on March 24th, LiteLLM was compromised following an attack on Checkmarx, OpenVSX, and Trivy. Discovery came entirely by accident: a researcher at an AI company launched a local development server that automatically pulled in the latest version of LiteLLM as a background dependency, inadvertently installing the compromised package just minutes after it was published.

A flaw in the malware’s own implementation caused the payload to spawn Python processes in an exponential loop, crashing the machine and making the infection impossible to ignore. After tracing the disruption to the newly installed package, the researcher reported it to PyPI’s security team, which quarantined the affected versions within approximately forty minutes.

Evidence also emerged that the LiteLLM maintainer’s own GitHub account had been compromised, with a community alert issue closed and buried under bot activity, suggesting the threat actor had achieved broad access to the project’s infrastructure before the malicious releases were ever uploaded.

Who Was Affected

The population of potentially exposed developers was exceptionally broad, encompassing anyone who installed or upgraded LiteLLM on March 24, 2026, without pinning to a specific verified version. LiteLLM is so commonly included as a modular dependency in AI frameworks, agentic coding tools, and model evaluation libraries that many developers received the compromised versions without ever explicitly requesting the package themselves.

Organizations running AI-powered tooling in environments where cloud credentials, internal API keys, or Kubernetes access tokens were present faced the most serious risk, since the malware was designed to harvest exactly those categories of secret.

The Kubernetes lateral movement component increased the vulnerability for any enterprise environment, as a single infected developer machine with cluster access could have seeded a persistent backdoor across production or staging infrastructure. Affected developers were spread across the global AI engineering community, spanning individual researchers, startup engineering teams, and large organizations that had adopted LiteLLM as part of their model serving.

Identify and Remove the Compromised Package

Any developer who installed or updated LiteLLM during the window of exposure should first verify the installed version and, if 1.82.7 or 1.82.8 is present, remove it immediately and purge all local package manager caches to prevent the malicious wheel from being reinstalled.

Virtual environments, container images, and CI/CD pipeline configurations should all be audited for references to the affected versions, as automated systems may have cached and continue to deploy the compromised release. Teams should review all systems that may potentially have been exposed.

The malware’s lateral movement capability means that even a brief window of exposure or execution on a machine with cluster credentials may have been sufficient to propagate the backdoor to infrastructure that has no direct connection to LiteLLM. PyPI’s official incident report team recommends utilizing “Dependency Cooldowns”.

The PyPI team adds that it “isn’t a silver bullet”, encouraging users to do a full system audit, including all potentially affected systems. According to the Security Labs team, this is a “multi-stage campaign”.

Conclusion

The LiteLLM supply chain attack illustrates how the open-source ecosystem’s reuse of software can become its most dangerous liability. When the security of publishing infrastructure is not treated with the same rigor as the code itself.

A vulnerability in a trusted security scanner provided the entry point for an attack that reached tens of thousands of developer machines within hours, harvesting credentials that could have unlocked cloud infrastructure, source code repositories, and internal systems across dozens of organizations.

No security control caught the attack, but instead caused by a bug in the malware that made it impossible to ignore. Without that, the credential harvest could have continued silently for days or weeks.

For the AI development community, which depends on rapidly evolving open-source tooling, this incident is a direct warning that trust dependency cannot be assumed; trust dependency must be actively maintained. As AI-powered development continues to expand its footprint across the software industry, securing the packages that underpin it is a foundational responsibility. It’s a good idea to have someone, like a vCISO, who can maintain the security behind these AI-powered programs.