LiteLLM 1.107.0 on PyPI Shipped a Credential Stealer and Backdoor
- The LiteLLM 1.107.0 wheels on PyPI installed a credential stealer and a remote code execution backdoor as three files in site-packages, and both run whenever any Python process starts, even one that never imports litellm.
- The stealer collects SSH keys, cloud credentials, CI/CD secrets, AI tool tokens, browser passwords, and LLM provider keys from a LiteLLM proxy database, encrypts them, and sends them to www.litellm[.]dev.
- A one-line change adding data = "cook" to the sdist's pyproject.toml injected the implant, and the version field was set back to 1.107.0 so a dependency diff against rc2 looked normal.
- SafeDep assesses with moderate to high confidence that BerriAI's private release pipeline built the wheels from an attacker-modified git source, since no public GitHub Actions run published the release and the GitHub release appeared about 10 minutes after the PyPI upload.
Hacker News opinions
Seriously, again? I wish Google ADK hadn't pulled this in as a dep. At this rate every popular free package is going to get poisoned.
This isn't acceptable. Once is forgivable, twice is malpractice.
I'm working on GoModel, a LiteLLM alternative in Go that runs about 20x faster. Not saying it fixes anything, but the language choice helps.
A 24 to 48 hour cooldown on uv and npm by default would catch most of these. The catch is that it also delays real security patches, so we had to exclude those by hand.
Median supply chain attacks sit undetected for months to years, so a 48 hour cooldown is mostly snake oil.
The enterprise private registry thing looked bad, but a LiteLLM employee in the thread says the enterprise build path wasn't affected and the fix goes public after a disclosure window.
If you still had LiteLLM installed after the first hit, the second one is on you. I never installed it and skipped both.