Live data from Hacker News

Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

github.com

281–290 of 569 posts

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

#281

Earlier quoted context omitted.

How did PYPI_PUBLISH lead to a full GH account takeover?

Their Personal Access Token must’ve been pwned too, not sure through what mechanism though

They have written about it on github to my question:

Trivvy hacked (https://www.aquasec.com/blog/trivy-supply-chain-attack-what-...) -> all circleci credentials leaked -> included pypi publish token + github pat -> | WE DISCOVER ISSUE | -> pypi token deleted, github pat deleted + account removed from org access, trivvy pinned to last known safe version (v0.69.3)

What we're doing now:

    Block all releases, until we have completed our scans
    Working with Google's mandiant.security team to understand scope of impact
    Reviewing / rotating any leaked credentials
https://github.com/BerriAI/litellm/issues/24518#issuecomment...

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

#283

Earlier quoted context omitted.

It was the PYPI_PUBLISH token which was in our github project as an env var, that got sent to trivvy. We have deleted all our pypi publishing tokens. Our accounts had 2fa, so it's a bad token here. We're reviewing our accounts, to see how we can make it more secure (trusted publishing via jwt tokens, move to a different pypi account, etc.).

Perhaps it's too obvious but ... just running the publish process locally, instead of from CI, would help. Especially if you publish from a dedicated user on a Mac where the system keychain is pretty secure.

This problem is solved by not having a token. Github and PyPI both support OIDC based workflows. Grant only the publish job access to OIDC endpoint, then the Trivy job has nothing it can steal.

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

#284

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…

You're making great software and I'm sorry this happened to you. Don't get discouraged, keep bringing the open source disruption!

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

#285
post #129

Earlier quoted context omitted.

This is the security shortcuts of the past 50 years coming back to bite us. Software has historically been a world where we all just trust each other. I think that’s coming to an end very soon. We need sandboxing for sure, but it’s much bigger than that. Entire security models need to be rethought.

I've been thinking the same thing. And it's somewhat parallel to what happened to meditation vs. drugs. In the old world the dangerous insights required so many years of discipline that you could sort of trust that the person getting the insight would be ok. But then any idiot can get the insight by just eating some shrooms and oops, that's a problem. Mostly self-harm problem in that case. But the dynamic is somewhat…

What in the world are “the dangerous insights”?

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

#286
post #177

Earlier quoted context omitted.

> We just can't trust dependencies and dev setups. In one of my vibe coded personal projects (Python and Rust project) I'm actually getting rid of most dependencies and vibe coding replacements that do just what I need. I think that we'll see far fewer dependencies in future projects. Also, I typically only update dependencies when either an exploit is known in the current version or I need a feature present in a lat…

> In one of my vibe coded personal projects (Python and Rust project) I'm actually getting rid of most dependencies and vibe coding replacements that do just what I need. I think that we'll see far fewer dependencies in future projects. No free lunch. LLMs are capable of writing exploitable code and you don’t get notifications (in the eg Dependabot sense, though it has its own problems) without audits.

My vibe coded personal projects don't have the source code available for attackers to target specifically.

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

#287
post #263

Earlier quoted context omitted.

SOC2 is just "the process we say we have, is what we do in practice". The process can be almost anything. Some auditors will push on stuff as "required", but they're often wrong. But all it means in the end is you can read up on how a company works and have some level of trust that they're not lying (too much). It makes absolutely zero guarantees about security practices, unless the documented process make these guar…

Yeah, that was my understanding as well, so I fail to see how a proper SOC2 would have prevented this. I mean ideally a proper SOC2 would mean there are processes in place to reduce the likelihood of this happening, and then also processes to recover from if it did ended up happening. But the end result could've been essentially the same.

It wouldn't have. lol.

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

#288
my takeaway from this is that it should now be MANDATORY to have an LLM do a scan on the entire codebase prior to release or artifact creation. do NOT use third party plugins for this. it's so easy to create your own github action to digest the whole codebase and inspect third party code. it costs tokens yes but it's also cached and should be negligible spend for the security it brings.

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

#290
post #129

Earlier quoted context omitted.

This is the security shortcuts of the past 50 years coming back to bite us. Software has historically been a world where we all just trust each other. I think that’s coming to an end very soon. We need sandboxing for sure, but it’s much bigger than that. Entire security models need to be rethought.

I've been thinking the same thing. And it's somewhat parallel to what happened to meditation vs. drugs. In the old world the dangerous insights required so many years of discipline that you could sort of trust that the person getting the insight would be ok. But then any idiot can get the insight by just eating some shrooms and oops, that's a problem. Mostly self-harm problem in that case. But the dynamic is somewhat…

Supply-chain attacks long pre-date effective AI agentic coding, FWIW.
Post reply on HN