Popular LiteLLM PyPI Package Backdoored To Steal Credentials, Auth Tokens (bleepingcomputer.com) 9
joshuark shares a report from BleepingComputer: The TeamPCP hacking group continues its supply-chain rampage, now compromising the massively popular "LiteLLM" Python package on PyPI and claiming to have stolen data from hundreds of thousands of devices during the attack. LiteLLM is an open-source Python library that serves as a gateway to multiple large language model (LLM) providers via a single API. The package is very popular, with over 3.4 million downloads a day and over 95 million in the past month. According to research by Endor Labs, threat actors compromised the project and published malicious versions of LiteLLM 1.82.7 and 1.82.8 to PyPI today that deploy an infostealer that harvests a wide range of sensitive data.
[...] Both malicious LiteLLM versions have been removed from PyPI, with version 1.82.6 now the latest clean release. [...] If compromise is suspected, all credentials on affected systems should be treated as exposed and rotated immediately. [...] Organizations that use LiteLLM are strongly advised to immediately:
- Check for installations of versions 1.82.7 or 1.82.8
- Immediately rotate all secrets, tokens, and credentials used on or found within code on impacted devices.
- Search for persistence artifacts such as '~/.config/sysmon/sysmon.py' and related systemd services
- Inspect systems for suspicious files like '/tmp/pglog' and '/tmp/.pg_state'
- Review Kubernetes clusters for unauthorized pods in the 'kube-system' namespace
- Monitor outbound traffic to known attacker domains
[...] Both malicious LiteLLM versions have been removed from PyPI, with version 1.82.6 now the latest clean release. [...] If compromise is suspected, all credentials on affected systems should be treated as exposed and rotated immediately. [...] Organizations that use LiteLLM are strongly advised to immediately:
- Check for installations of versions 1.82.7 or 1.82.8
- Immediately rotate all secrets, tokens, and credentials used on or found within code on impacted devices.
- Search for persistence artifacts such as '~/.config/sysmon/sysmon.py' and related systemd services
- Inspect systems for suspicious files like '/tmp/pglog' and '/tmp/.pg_state'
- Review Kubernetes clusters for unauthorized pods in the 'kube-system' namespace
- Monitor outbound traffic to known attacker domains
Increment the version ya nubs. (Score:3, Insightful)
Otherwise systems won't automatically treat the clean release as newer and replace the contaminated ones.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
The attacker did release updated versions but your other comment suggests you already realized that but I'll explain for anyone else.
They removed the hacked versions and rolled the project version back to the good version. I'm saying they should increment the version number of the clean version to be higher than the hacked versions so the systems which had already installed the compromised packages will recognize the clean version as newer and having priority over the hacked one. In some cases automatic upd
Correction (Score:4, Insightful)
The LitleLLM packages were comprimosed on Tuesday. The packages compromised today were telnyx 4.87.1 and 4.87.2. It's the same root cause: credentials exposed to a compromised version of Trivy earlier were used to make an unauthorized release of a compromised version of a different package.
Language (Score:2)
What difference does the language make? What other language makes this scenario impossible? Answer: None.
Re: (Score:2)
The question is how long the supply chains are. Python is moderate, nodejs is horrible. With languages like C++ you usually have like 1-5 libraries with no dependencies themselves and you need to download and install them yourself, possibly doing manual upgrades instead of always updating to the latest version. That is a much more stable model than "recursively fetch my 20 dependencies and get 500 packages I've never heard of"