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

531–540 of 569 posts

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

#531

Post by Fibonar »

snailmailman wrote: post #520
snailmailman wrote: post #317

Earlier quoted context omitted.

The same thing occurred on the trivy repo a few days ago. A GitHub discussion about the hack was closed and 700+ spam comments were posted. I scrolled through and clicked a few profiles. While many might be spam accounts or low-activity accounts, some appeared to be actual GitHub users with a history of contributions. I’m curious how so many accounts got compromised. Are those past hacks, or is this credential steeli…

Update: It looks like the accounts have all been deleted by github, including their repos. They are 404 pages now. Their repos + recent malicious commits are all just 404 pages now. I'm curious what the policy is there if the accounts were compromised. Can the original users "restore" their accounts somehow? For now it appears the accounts are gone. Maybe they were entirely bot accounts but a few looked like compromi…

Yep my coworker hnykda, first reply confirming the report, got his account deleted for a while earlier. Definitely not the best way of handling this...

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

#532

Post by Fibonar »

calebjang wrote: post #525

This is exactly what worries me about autonomous agents. A compromised package is bad. An agent that autonomously runs pip install with that package is a different problem. The attack surface moves with the agent.

Dev who submitted the PyPI report here. I hear what you're saying, but in this case it was all human error that got me. It was a mix of getting too comfortable with uvx installing all dependencies on startup, and Cursor running my uvx-built plugins automatically in the background. Meaning I didn't even type the install command myself, yet no agents involved.

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

#533

Post by Fibonar »

agentictrustkit wrote: post #413

I think this gets a lot worse when we look at it from an agentic perspective. Like when a dev person hits a compromising package, there's usually a "hold on, that's weird" moment before a catastrophe. An agent doesn't have that instinct. Oh boy supply chain integrity will be an agent governenace problem, not just a devops one. If you send out an agent that can autonomously pull packages, do code, or access creds, the…

Initial person to report the malware to PyPI here. My cynical take is that it doesn't really matter how tightly scoped the agent privileges are if the human is still developing code outside of containers, with .env files lying around for the taking. I agree about agents not yet having the instincts to check suspicious behaviour. It took a bit of prodding for my CC to dig deeper and not accept the first innocent explanation it stumbled on.

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

#534

Post by xenophonf »

jacamera wrote: post #484
whattheheckheck wrote: post #420

Earlier quoted context omitted.

The industry needs to step up and plant a flag for professionalization certifications for proper software engineering. Real hard exams etc

I can't even imagine what these exams would look like. The entire profession seems to boil down to making the appropriate tradeoffs for your specific application in your specific domain using your specific tech stack. There's almost nothing that you always should or shouldn't do.

All engineering professions are like that. NCEES has been licensing Professional Engineers for over a hundred years. The only thing stopping CS/SE is an unwillingness to submit to anything resembling oversight.

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

#535

Post by xenophonf »

ctmnt wrote: post #505
ctmnt wrote: post #483

Earlier quoted context omitted.

They absolutely do. In this case litellm 1.82.8 had been out for at least a week (can’t recall the exact date offhand). The compromised version was a replacement.

Ah, my mistake! Thanks for the correction. But I believe you can replace versions on both, nonetheless. It’s a multi step process, unpublish then publish again. But the net effect is the same.

PyPI enforces immutable releases.

https://pypi.org/help/#file-name-reuse

> PyPI does not allow for a filename to be reused, even once a project has been deleted and recreated...

> This ensures that a given distribution for a given release for a given project will always resolve to the same file, and cannot be surreptitiously changed one day by the projects maintainer or a malicious party (it can only be removed).

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

#536

Post by cedws »

varenc wrote: post #387
cedws wrote: 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.

What is the rational for the attacker spamming the relevant issue with bot replies? does this benefit them? Maybe it makes discussion impossible to confuse maintainers and delay the time to a fix?

Yes, trying to slow down response.

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

#537

Post by staticassertion »

mike_hearn wrote: post #511
staticassertion wrote: post #490

Earlier quoted context omitted.

Privesc is trivial on every desktop OS if you run as a regular user. I can write to your rc files so it's game over. App Store apps are the exception, which is great, but presumably we're not talking about that? If we are, then yeah, app stores solve these problems by making things actually sandboxed.

Any app can be sandboxed on macOS and by default newly created apps are; that's why I say if you create a new app in Xcode then anything run by that app is sandboxed out of the box. App Store enforces it but beyond that isn't involved.

I feel like we're just talking about different things? I've just said that I'm aware of apps being sandboxed, that does not mean that some random program you run from your terminal is sandboxed.

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

#538

Post by vlovich123 »

BoppreH wrote: post #504
vlovich123 wrote: post #500

Earlier quoted context omitted.

You have a trusted compiler you write in assembly or even machine code. You then compile a source code you trust using that compiler. That is then used for the bit for bit analysis against a different binary of the compiler you produced to catch the hidden vulnerability.

It's assumed that in this scenario you don't have access to a trusted compiler; if you do, then there's no problem. And the thesis linked above seems to go beyond simply "use a trusted compiler to compile the next compiler". It involves deterministic compilation and comparing outputs, for example.

Correct. The deterministic comparison is against compiler A compiling itself. Version 1 is compiler A compiling itself with a normal build of compiler A. Version 2 is compiler A compiled with a trusted toolchain. How do you get that trusted first tool chain is a challenge but, for example, you can start with a tiny tiny C compiler (they can be quite small) that’s used to compile a larger c compiler that can compile c compilers and then finally build clang. Then you have a trusted version of clang that can be used to verify the clang binary. From there you just use clang and periodically recheck no vulnerability has been reintroduced.

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

#539

Post by detente18 »

detente18 wrote: post #209
detente18 wrote: post #99

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…

Update: - Impacted versions (v1.82.7, v1.82.8) have been deleted from PyPI - All maintainer accounts have been changed - All keys for github, docker, circle ci, pip have been deleted We are still scanning our project to see if there's any more gaps. If you're a security expert and want to help, email me - krrish@berri.ai

Update 2 (03/25/2026):

- We will be holding a townhall on Friday to review the incident and share next steps (https://lnkd.in/gsbTdCe7)

- We can confirm a bad version of Trivy security scanner ran in our CI/CD pipeline, which would have led to the supply chain attack

- We have paused new releases until we've completed securing our codebase and release pipeline to ensure safe releases for users

- We've added additional github/gitlab ci scripts for checking if you're impacted: https://lnkd.in/gGicMkby

We hope to share a full RCA in the coming days. Until then, if there's anything we can do to help your team - please let me know. You can email me (krrish@berri.ai), or join the discussion on github (https://lnkd.in/g9TuuQ2H).

Post reply on HN