Earlier this week, LiteLLM – a highly popular open-source Python library – was compromised to spread credential-stealing malware.
Essentially, if you’ve installed LiteLLM 1.82.7 or 1.82.8, you’re in trouble and should act immediately – assuming the worst hasn’t already happened.
“Earlier today I got taken out by malware on my local machine. After identifying the malicious payload, I reported it directly to the PyPI security team – who credited our report and quarantined the package – as well as to the LiteLLM maintainers,” research scientist Callum McMahon said in a 24 March blog post.
“It started with my machine stuttering hard, something that really shouldn’t be happening on a 48GB Mac. [htop] taking tens of seconds to load, CPU pegged at 100 per cent, all signs I’ll be working on my local env for a while… After failing to software reset my Mac, I took a final picture for evidence and hard reset.”
According to McMahon’s analysis, the blast radius could be massive. The library had been downloaded at least 47,000 times in just one 46-minute period, with “88 per cent of dependent packages unprotected”.
Cory Michal, CISO at application security firm AppOmni, considers the compromise to be a “major incident”.
“The malicious LiteLLM release compromised thousands of developers with a credential harvester/stealer and a persistent backdoor intended to help the attacker maintain access and move further inside affected environments,” Michal told Cyber Daily.
“More importantly, this is not an isolated LiteLLM breach – it appears to be downstream fallout from the earlier Trivy compromise, where abuse of a trusted vulnerability scanner in many CI/CD pipelines enabled credential theft that was then allegedly used to poison LiteLLM’s PyPI release chain, turning one upstream supply-chain failure into a broader cascading compromise.”
Michal believes that compared to similar attacks involving AI tools, this is a far more serious incident, as it extends from not just one compromised model or app, but all the way into the development pipeline itself.
“It was not just an abuse of model behaviour, prompt injection, or an application bug. It’s a software supply-chain compromise that led to malicious package publication, credential theft, and persistence on affected hosts,” Michal said.
“What makes it especially notable is that the LiteLLM compromise appears to have been downstream fallout from the earlier Trivy breach, meaning attackers may have used one trusted CI/CD compromise to poison another widely used AI-layer dependency, which is exactly the kind of cascading, transitive risk security teams worry about most.
“The big picture issue is that the software supply chain is still built on too much implicit trust and not enough immutability or verification: Organisations routinely allow third-party actions, packages, and release artifacts into build pipelines because they come from trusted vendors or popular projects, but this incident shows how fragile that model is when an upstream component is compromised.”
Michal recommends several steps to take immediately:
- Identify and remove compromised versions.
- Isolate impacted hosts.
- Inspect Kubernetes clusters for rogue privileged pods.
- Review network logs for malicious traffic.
- Remove persistence mechanisms.
- Rotate any credentials, tokens, keys, or secrets that were present on those systems.
“Teams should also audit whether those environments were exposed because of the earlier Trivy breach, since current reporting indicates the LiteLLM compromise was downstream fallout from that initial CI/CD trust failure,” Michal said.
David Hollingworth
David Hollingworth has been writing about technology for over 20 years, and has worked for a range of print and online titles in his career. He is enjoying getting to grips with cyber security, especially when it lets him talk about Lego.