120 points abhisek 2 hours ago 53 comments
rvz 1 hour ago | parent
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
gcr 1 hour ago | parent
stbenjam 1 hour ago | parent
santiago-pl 1 hour ago | parent
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/
ghrl 1 hour ago | parent
I myself have written a small llm proxy in Go, doing nothing but injecting the real API key to outgoing requests while itself validating virtual keys it generates, and it works great.
santiago-pl 1 hour ago | parent
TZubiri 46 minutes ago | parent
jiwidi 1 hour ago | parent
0xbadc0de5 1 hour ago | parent
stbenjam 1 hour ago | parent
rcleveng 1 hour ago | parent
Risk is ensuring enough security researchers are finding these and quarantining these before that default cooldown lapses.
robinhoodexe 1 hour ago | parent
I’m unsure how to automate this properly, maybe an LLM is the best starting point.
mbrumlow 48 minutes ago | parent
fmbb 44 minutes ago | parent
dlkasajiewo 36 minutes ago | parent
mattstir 36 minutes ago | parent
tikkabhuna 34 minutes ago | parent
Ultimately, you need someone to verify releases and that probably means paying for it. I know Sonatype paid solutions utilise their own internal research to allow/block new releases.
trollbridge 31 minutes ago | parent
giancarlostoro 1 hour ago | parent
petesergeant 1 hour ago | parent
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...
sullivanmatt 1 hour ago | parent
Also if you don't like organizations fixing vulns without releasing the open source first, you're going to be upset when you learn how every major vuln and associated patches are distributed long before the fixes hit the repos. A timely example of this is PHP, literally today.
petesergeant 50 minutes ago | parent
Sorry, there was a paid-for PHP release that fixed it I could have gotten a week ago, and that they publicly announced existed, and it was just people who don't pay for PHP who had to wait...?
sullivanmatt 30 minutes ago | parent
You can argue about whether the "publicly announced existed" part since they don't advertise for any single package, but that's the ecosystem you buy into.
petesergeant 17 minutes ago | parent
The way you've written this is substantially misleading. RedHat receives notice of the vulnerabilities so they can prepare packages to be available the moment the embargo lifts, which I guess technically could hit the public packages a tiny bit earlier, but they are not releasing fixes of embargoed vulnerabilities to their commercial clients before the embargo lifts.
This is substantially different from the policy I've quoted that I am objecting to.
callamdelaney 1 hour ago | parent
tech_solver 1 hour ago | parent
infecto 1 hour ago | parent
cyanydeez 55 minutes ago | parent
Agents and malware will eradicate all goodwill left.
Good by internet.
abhisek 48 minutes ago | parent
TZubiri 47 minutes ago | parent
Tell em Tom Zubiri sent ya (I don't get a commission, just good karma)
edoceo 5 minutes ago | parent
I use it, I don't cooldown, proper version pinning for me.
baddash 55 minutes ago | parent
TZubiri 50 minutes ago | parent
I'm not saying everyong should migrate after there's a vuln, but I'm definitely saying that. Unless it's something huge and foundational like a programming language (PHP gets a second chance), just migrate within the next couple of weeks.
I didn't even have it installed the first time, so the ideal programmers, (read, your competition), actually suffered 0 vulns from this dep, if you suffered 1, that's already pretty bad, being burnt twice should be a wake up call. If you get hit 3 times by the same dependency, it's a lost case.
john_strinlai 42 minutes ago | parent
second? i haven't kept count, but we have to be somewhere in the hundreds of chances now
wongarsu 41 minutes ago | parent
If it matters, I am mostly interested in the aspect of having a proxy that unifies multiple ollama and openai-compatible endpoints with model-based routing and failover. Optionally with api-keys, reporting, budgets, etc. I do not particularly care about the MCP gateway, Agent-To-Agent thingy, and whatever else LiteLLM bolted on over time
tkz1312 39 minutes ago | parent
spike021 25 minutes ago | parent
tkz1312 22 minutes ago | parent
connorbrinton 16 minutes ago | parent
dannyboland 9 minutes ago | parent
Now that AI makes it cheaper to build such tools in-house, the case for adopting a maximalist framework and trusting that entire supply chain is a lot weaker.
syntaxing 53 minutes ago | parent
abhisek 49 minutes ago | parent
hmokiguess 32 minutes ago | parent
> 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.
1-6 23 minutes ago | parent
SomaticPirate 20 minutes ago | parent
madamelic 15 minutes ago | parent
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.
1vuio0pswjnm7 6 minutes ago | parent
1792590232 | Litellm 1.107.0 Compromised | https://github.com/BerriAI/litellm/issues/47826 | https://news.ycombinator.com/item?id=50180845 | 0 comments