Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

github.com

Post reply on HN
Print view View original

131–140 of 569 posts

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

#131

Post by jFriedensreich »

amelius wrote: post #113
jFriedensreich wrote: post #86

We just can't trust dependencies and dev setups. I wanted to say "anymore" but we never could. Dev containers were never good enough, too clumsy and too little isolation. We need to start working in full sandboxes with defence in depth that have real guardrails and UIs like vm isolation + container primitives and allow lists, egress filters, seccomp, gvisor and more but with much better usability. Its the same requir…

We need programming languages where every imported module is in its own sandbox by default.

We have one where thats possible: workerd (apache 2.0) no new language needed just a new runtime

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

#133

Post by persedes »

hmokiguess wrote: post #121

What’s the best way to identify a compromised machine? Check uv, conda, pip, venv, etc across the filesystem? Any handy script around? EDIT: here's what I did, would appreciate some sanity checking from someone who's more familiar with Python than I am, it's not my language of choice. find / -name "litellm_init.pth" -type f 2>/dev/null find / -path ' /litellm-1.82. .dist-info/METADATA' -exec grep -l 'Version: 1.82.[7…

there's probably a more precise way, but if you're on uv:

  rg litellm  --iglob='*.lock'

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

#134

Post by f311a »

Their previous release would be easily caught by static analysis. PTH is a novel technique.

Run all your new dependencies through static analysis and don't install the latest versions.

I implemented static analysis for Python that detects close to 90% of such injections.

https://github.com/rushter/hexora

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

#135

Post by wswin »

jFriedensreich wrote: post #130
wswin wrote: post #120

Earlier quoted context omitted.

Containers prevent this kind of info stealing greatly, only explicitly provided creds would be leaked.

Containers can mean many things, if you mean plain docker default configured containers then no, they are a packaging mechanism not safe environment by themselves.

They don't have access to the host filesystem nor environment variables and this attack wouldn't work.

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

#136

Post by Bengalilol »

binsquare wrote: post #109
jFriedensreich wrote: post #86

We just can't trust dependencies and dev setups. I wanted to say "anymore" but we never could. Dev containers were never good enough, too clumsy and too little isolation. We need to start working in full sandboxes with defence in depth that have real guardrails and UIs like vm isolation + container primitives and allow lists, egress filters, seccomp, gvisor and more but with much better usability. Its the same requir…

So... I'm working on an open source technology to make a literal virtual machine shippable i.e. freezing everything inside it, isolated due to vm/hypervisor for sandboxing, with support for containers too since it's a real linux vm. The problems you mentioned resonated a lot with me and why I'm building it, any interest in working to solve that together?: https://github.com/smol-machines/smolvm

Probably on the side of your project, but did you try SmolBSD? https://smolbsd.org> It's a meta-OS for microVMs that boots in 10–15 ms.

It can be dedicated to a single service (or a full OS), runs a real BSD kernel, and provides strong isolation.

Overall, it fits into the "VM is the new container" vision.

Disclaimer: I'm following iMil through his twitch streams (the developer of smolBSD and a contributor to NetBSD) and I truly love what he his doing. I haven't actually used smolBSD in production myself since I don't have a need for it (but I participated in his live streams by installing and running his previews), and my answer might be somewhat off-topic.

More here https://hn.algolia.com/?q=smolbsd>

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

#137

Post by abhikul0 »

intothemild wrote: post #36

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?

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

#138

Post by santiagobasulto »

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.thoughts.ar/posts/2025/12/03/ai-is-all-about-soft...

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

#140

Post by eoskx »

santiagobasulto wrote: post #138

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…

Valid, but for all the crap that LangChain gets it at least has its own layer for upstream LLM provider calls, which means it isn't affected by this supply chain compromise (unless you're using the optional langchain-litellm package). DSPy uses LiteLLM as its primary way to call OpenAI, etc. and CrewAI imports it, too, but I believe it prefers the vendor libraries directly before it falls back to LiteLLM.
Post reply on HN