Live data from Hacker News

Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

github.com

441–450 of 569 posts

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#441

Earlier quoted context omitted.

Welcome to the new era, where programming is neither a skill nor a trade, but a task to be automated away by anyone with a paid subscription.

alot of software isnt that important so its fine, but some actually is important. especially with a branding name slapped on it that people will trust

[deleted]

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#442
post #306

I've been waiting for something like this to happen. It's just too easy to pull off. I've been hard-pinning all of my versions of dependencies and using older versions in any new projects I set up for a little while, because they've generally at least been around long enough to vet. But even that has its own set of risks (for example, what if I accidently pin a vulnerable version). Either that, or I fork everything,…

Pinning doesn’t help you. They can replace the package and you’ll get the new one. You have to vendor the dependencies.

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#443
post #200

Earlier quoted context omitted.

I believe the issue is if an exploit is somehow injected into AI training data such that the AI unwittingly produces it and the human who requested the code doesn't even know.

That’s a separate issue and specifically not what OP was describing. Also highly unlikely in practice unless you use a random LLM - the major LLM providers already have to deal with such things and they have decent techniques to deal with this problem afaik.

If you think the the major LLM providers have a way to filter malicious (or even bad or wrong) code from training data, I have a bridge to sell you.

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#444

LiteLLM maintainer here, this is still an evolving situation, but here's what we know so far: 1. Looks like this originated from the trivvy used in our ci/cd - https://github.com/search?q=repo%3ABerriAI%2Flitellm%20trivy... https://ramimac.me/trivy-teampcp/#phase-09 2. If you're on the proxy docker, you were not impacted. We pin our versions in the requirements.txt 3. The package is in quarantine on pypi - this block…

Similar to delve, this guy has almost no work experience. You have to wonder if YC and the cult of extremely young founders is causing instability issues in society at large?

It’s a flex now. But there are still many people doing it for the love of the game.

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#445

Earlier quoted context omitted.

So if I'm developing something I want to use and the community finds it useful but I take no contributions and no feature requests I should have to find another person to deal with? How do I even know who to trust, and what prevents two people from conspiring together with a long con? Sounds great on the surface but I'm not sure you've thought it through.

It wouldn't prevent a project that has a goal of being purposely malicious, just from pushing out releases that aren't actually releases. As far as who to trust, I could imagine the maintainers of different high-level projects helping each other out in this way. Though, if you really must allow a single user to publish releases to the masses using existing shared social infrastructure. Then you could mitigate this ty…

Why not make it _optional_ but implement on github,etc so any publisher could enable this, no matter how small. But also make it possibel to disable either by support request and small wait or by secondary confirmation or via LONG (months) wait.

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#446

LiteLLM maintainer here, this is still an evolving situation, but here's what we know so far: 1. Looks like this originated from the trivvy used in our ci/cd - https://github.com/search?q=repo%3ABerriAI%2Flitellm%20trivy... https://ramimac.me/trivy-teampcp/#phase-09 2. If you're on the proxy docker, you were not impacted. We pin our versions in the requirements.txt 3. The package is in quarantine on pypi - this block…

the chain here is wild. trivy gets compromised, that gives access to your ci, ci has the pypi publish token, now 97 million monthly downloads are poisoned. was the pypi token scoped to publishing only or did it have broader access? because the github account takeover suggests something wider leaked than just the publish credential

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#447
post #107

This looks like the same TeamPCP that compromised Trivy. Notice how the issue is full of bot replies. It was the same in Trivy’s case. This threat actor seems to be very quickly capitalising on stolen credentials, wouldn’t be surprised if they’re leveraging LLMs to do the bulk of the work.

whats new isnt the shortcuts, its the cascading. one compromised trivy instance led to kics led to litellm led to dspy and crewai and mlflow and hundreds of mcp servers downstream. the attacker didnt need to find five separate vulnerabilities, they found one and rode the dependency graph. thats a fundamentally different threat model than what most security tooling is built around

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#448

I blogged about this last year[0]... > ### Software Supply Chain is a Pain in the A* > On top of that, the room for vulnerabilities and supply chain attacks has increased dramatically AI Is not about fancy models, is about plain old Software Engineering. I strongly advised our team of "not-so-senior" devs to not use LiteLLM or LangChain or anything like that and just stick to `requests.post('...')". [0] https://sb.th…

the requests.post advice is right but its also kind of depressing that the state of the art recommendation for using llm apis safely in 2026 is to just write the http call yourself. we went from dont reinvent the wheel to actually maybe reinvent it because the wheel might steal your ssh keys. the abstraction layer that was supposed to save you time just cost an unknown number of people every credential on their machine

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#449

I just installed Harbor, and it instantly pegged my cpu.. i was lucky to see my processes before the system hard locked. Basically it forkbombed `grep -r rpcuser\rpcpassword` processes trying to find cryptowallets or something. I saw that they spawned from harness, and killed it. Got lucky, no backdoor installed here from what i could make out of the binary

Same experience with browser-use, it installs litellm as a dependency. Rebooted mac as nothing was responding; luckily only github and huggingface tokens were saved in .git-credentials and have invalidated them. This was inside a conda env, should I reinstall my os for any potential backdoors?

Well, I reinstalled and finally upgraded to Tahoe.

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#450
post #443

Earlier quoted context omitted.

That’s a separate issue and specifically not what OP was describing. Also highly unlikely in practice unless you use a random LLM - the major LLM providers already have to deal with such things and they have decent techniques to deal with this problem afaik.

If you think the the major LLM providers have a way to filter malicious (or even bad or wrong) code from training data, I have a bridge to sell you.

No not to filter it out of training but to make it difficult to have poisoned data have an outsized impact vs its relative appearance. So yes, you can poison a random thing only you have ever mentioned. It’s more difficult to poison the LLM to inject subtle vulnerabilities you influence in code user’s ask it to generate. Unless you somehow flood training data with such vulnerabilities but that’s also more detectable.

TLDR: what I said is only foolish if you take the absolute dumbest possible interpretation of it.

Post reply on HN