Poisoned LiteLLM Packages on PyPI May Have Leaked Secrets From 2,100 Organisations

Key points

• Two malicious versions of LiteLLM, a popular open-source tool that routes requests to AI models, sat on PyPI for roughly 40 minutes in March 2024 before being pulled.
• The tampered packages ran hidden code that scraped cloud keys, SSH keys, Kubernetes tokens, database passwords and other secrets from any machine that installed them.
• Threat intelligence firm CloudSEK says it obtained the attackers' loot: about 434,000 files taken from victims during that short window.
• CloudSEK's analysis of the dataset maps possible exposure to more than 2,100 organisations worldwide.
• The intrusion has overlapping tradecraft with an earlier supply-chain hit on Trivy, the open-source vulnerability scanner, suggesting the same operators.

A short window. A big blast radius.

For about 40 minutes in March, two booby-trapped releases of LiteLLM, a widely used Python library that lets developers talk to many AI models through one interface, were live on PyPI, the main repository where Python developers get their code. Anyone who ran a routine install during that window pulled in code designed to rifle through their machine and send anything valuable back to the attackers.

The stolen material was not small. CloudSEK, the threat intelligence firm that later obtained the attackers' collection, counts roughly 434,000 files harvested from victim systems. Its analysts say the fingerprints inside that dataset point to more than 2,100 organisations that may have exposure, according to reporting by The Hacker News.

What did the malicious code actually steal?

Secrets. The kind that unlock everything else.

The injected code hunted for cloud provider access keys (the passwords that let software log into Amazon, Google or Microsoft cloud accounts), SSH keys (used to log into servers remotely), Kubernetes tokens (which control fleets of containers running production apps), database credentials and generic API keys stored in configuration files. In a modern engineering shop these files sit in predictable places, which is exactly what the thieves counted on.

Once a key like that is out, the damage is not confined to the laptop that ran the install. An attacker with a live cloud key can spin up servers, read customer data, or quietly plant a backdoor for later.

Who is behind it?

CloudSEK links this operation to the earlier poisoning of Trivy, an open-source scanner many companies use to check their own containers for vulnerabilities. The overlap is in tradecraft and infrastructure rather than a named group, so attribution here sits at medium confidence at best. No public vendor cluster name (think Kimsuky, Mustang Panda, Lazarus) has been attached.

The motive looks financial and opportunistic, not espionage. Grab credentials, monetise access, move on.

The known timeline

What should teams that use LiteLLM do now?

Assume exposure if you installed LiteLLM during that March window, and rotate anything the code could have seen: cloud access keys, SSH keys, Kubernetes service account tokens, database passwords, and any API keys sitting in environment files on the affected build machine.

Check cloud audit logs for the days after install for logins from unfamiliar locations or new access keys being created. Pin dependency versions and require code review on any bump to a package that touches production. Do not rely on "it was only up for 40 minutes" as comfort. Automated build pipelines pull fresh packages constantly, and 40 minutes is plenty.

Ordinary users of AI products built on LiteLLM do not need to take direct action. The risk lands on the companies that shipped code using the poisoned versions, and any downstream customers whose data lived in those cloud accounts.