Popular LiteLLM PyPI Package Backdoored To Steal Credentials, Auth Tokens (bleepingcomputer.com)
(Friday March 27, 2026 @06:00PM (BeauHD)
from the PSA dept.)
- Reference: 0181119694
- News link: https://it.slashdot.org/story/26/03/27/1527202/popular-litellm-pypi-package-backdoored-to-steal-credentials-auth-tokens
- Source link: https://www.bleepingcomputer.com/news/security/popular-litellm-pypi-package-compromised-in-teampcp-supply-chain-attack/
[1]joshuark shares a report from BleepingComputer:
> The TeamPCP hacking group continues its supply-chain rampage, now [2]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 [3]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
[1] https://slashdot.org/~joshuark
[2] https://www.bleepingcomputer.com/news/security/popular-litellm-pypi-package-compromised-in-teampcp-supply-chain-attack/
[3] https://www.endorlabs.com/learn/teampcp-isnt-done
> The TeamPCP hacking group continues its supply-chain rampage, now [2]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 [3]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
[1] https://slashdot.org/~joshuark
[2] https://www.bleepingcomputer.com/news/security/popular-litellm-pypi-package-compromised-in-teampcp-supply-chain-attack/
[3] https://www.endorlabs.com/learn/teampcp-isnt-done
Correction (Score:4, Insightful)
by iabervon ( 1971 )
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.
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)
The general strategy for an attacker is to avoid detection. Releasing a completely new version that no developer recognizes goes counter to that.
Re: (Score:2)
Nevermind, I misread your comment.