alt Hacker NewsCompromised LiteLLM 1.107.0 on PyPI Installs a Credential Stealer and Backdoor
Comments
How could this happen to a project with 55k commits in three years?
All the sandbox-exec and all the Lulu rules are not going to protect against something like this.
At one point permission pop-up fatigue sets in we start giving any permission as if it's normal. We also become desensitised to isntalling tools: brew, npm, it becomes second nature.
"Oh, those 367 tools installed by package X? Yeah yeah, must be normal, that's how all these work now".
"Brew shows 59 packages outdated?". "Must upgrade". "Yeah, done. Perfect".
And the advent of agents and harnesses. It's not a matter of whether, it's when! OSes need to do something about it. Help users have complete separate "program space" at ease with better, easier, and lighter VMs if nothing else. I know, I know - Unix and Linux solved all this even before Alexander III of Macedon started wearing his nappies. Of course.
Official Incident Post: https://docs.litellm.ai/blog/security-incident-oct-21-2026
I am not following how someone snuck the files into the release.
All I read was that it creates a directory from the build file but seemingly no description how new files or added dependencies slipped by. Was `cook.pth` a dependency that got automatically downloaded from PyPI on install and then the build system put it into dependencies?
--
Leaving this for others:
> BerriAI’s private release pipeline built these wheels from an attacker-modified git source. The attacker could have used a compromised maintainer or bot credential, a private branch or mirror, or the reference the pipeline builds from. A stolen PyPI token used from the attacker’s own machines fits the evidence less well.
Makes sense. It was that a maintainer or the private pipeline was attacked and the malicious dependency was injected there by squatting on the maintainer's local copy rather than the dependency being hijacked for everyone. Very clever.
IMHO defaults for uv, npm, etc should all have a cooldown for 24 - 48 hours by default, you should have to go out of your way to install something newer.
https://github.com/BerriAI/litellm/issues/47826#issuecomment...
> OSS Users > For the time being, please pin your version to 1.106.2 or any explicit version published prior to now.
> Enterprise Customers > There currently exists a private LiteLLM registry for enterprise customers, in which we are distributing an embargoed release that remediates a vulnerability whose disclosure date is scheduled for October 27. Our private registry is not affected. If you are an enterprise customer pulling from our private registry you are not affected.
Last time they had this, I just vibe coded a version of lite llm and it actually works better
its litellm again. I wonder about maintainer trustworthiness
Seriously again for litellm? I really with that things like Google ADK didn't add this to my deps.
A bad day for opensource, but I guess this is how we get stronger patch by patch.
I wish all the best to LiteLLM team with handling it again. I can imagine how challenging are situations like this one.
However, if anyone is looking for 20x faster and less "targeted" LiteLLM alternative - I'm work on one in Go. That's why GoModel it's called. https://github.com/ENTERPILOT/GoModel/
Again this is the second time this year
Any package hosts that scan and include cooldowns by default that operate on a consumption model? The ones I have seen all charge a lot.
I figured LLMs nowadays would be good enough to catch issues like this. Is it because it’s too costly to do it?
This is the 2nd time. I'm glad I moved away from this platform.
Why on earth do these people make it impossible to select the title of their article?
1792590200 | LiteLLM Hijacked: Malicious 1.107.0 Wheels Steal Credentials | https://research.jfrog.com/post/litellm-hijacked-again/ | https://news.ycombinator.com/item?id=50180838 | 0 comments
1792590232 | Litellm 1.107.0 Compromised | https://github.com/BerriAI/litellm/issues/47826 | https://news.ycombinator.com/item?id=50180845 | 0 comments
Again! Yikes.
So in just 1 week:
1. Google Cloud Outage [0]
2. eMudhra CA private key Leak [1]
3. PingCap TiDB 10.6 TB data Leak [2]
4. PHP2Shell uncovers critical CVEs (with AI) [3]
...and now we have Round 2 of a LiteLLM compromise after the first one in [4].
[0] https://news.ycombinator.com/item?id=50163961
[1] https://news.ycombinator.com/item?id=50166579
[2] https://news.ycombinator.com/item?id=50173716
Twice? uiuiui
> There currently exists a private LiteLLM registry for enterprise customers, in which we are distributing an embargoed release that remediates a vulnerability whose disclosure date is scheduled for October 27.
https://github.com/BerriAI/litellm/issues/47826
oh boy. Announcing that there's a private enterprise repo you should be paying for if you don't want a credential stealer in your build is quite the optic, and then announcing there's an undisclosed second vulnerability that's being distributed, just not to the poors...
Second f**king time. Just torching their reputation at this point
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
Just going to remind you all that https://canarytokens.org/ exists.