detente18
Joined 8 years ago
Karma
385
Submissions
75
Member since
May 19
Github Account: https://github.com/krrish-berri-2
View on Hacker NewsRecent submissions
Comment · 10 days ago
Hi threecheese,
Pinning is a good idea.
So far, we believe it came from the github oauth cli tokens which are embedded in claude code tool responses - https://docs.litellm.ai/blog/security-incident-oct-21-2026#g...
It's something we're still investigating. I'll update my thread on this post, as we learn more!
Comment · 10 days ago
Hi fny,
That's fair feedback. What I'm trying to express is the complexity of it.
For this to work:
1. The attacker had to get access to our internal gateway
2. Claude code had to embed the github oauth cli token in tool call responses (not directly, but as part of an embedded url call).
3. We had to enable request/response logging.
4. The attacker had to be aware of this token logging circumstance, then harvest multiple user account tokens (one of which had to belong to an org admin)
5. The attacker had to wait for / hope that we would expand the release trust boundary (as we did on Monday)
among other things. This wasn't a "whoops we had shitty governance around our auth tokens" kind of situation, it involved a number of non-trivial circumstances many of which were beyond the attacker's direct control, including Claude Code behavior of which we were not previously aware of, and a sophisticated attacker.
- Krrish
Comment · 10 days ago
From our investigation, the token compromised was included by claude code in the tool call.
This was captured in the request/response logs.
The attacker, having gotten access to the logs, then looked for this and used it.
So - yes a local github cli oauth token, but not the machine.
Comment · 10 days ago
Hi abletonlive,
I appreciate the feedback. We work hard to make every release safe and secure. The attack was novel, and I'd love your feedback on how we can improve our ci/cd further.
https://docs.litellm.ai/blog/security-incident-oct-21-2026#h...
Comment · 10 days ago
Hi atmosx - i would recommend upgrading.
We work hard on improving the stability and security of LiteLLM on each release.
Please let me ([email protected]) know if you have any issues upgrading!
Comment · 10 days ago
Hi everyone, this has been contained. The attack was novel, and I'd love feedback on how we can improve from this.
Here's what we know so far: https://docs.litellm.ai/blog/security-incident-oct-21-2026#h...
- Krrish
Comment · 4 months ago
1. I think rust is the better long term solution over go. Especially for a gateway. You can see other proxy's (e.g. cloudflare's pingora - https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t...) doing the same thing.
Rust/Python hybrids are also quite well established, so it allows us to work off of a stable base - while ensuring we can deliver - low memory utilization - low request latency overhead
which is the primary goal here (be fast, lightweight and cheap to deploy).
2. LiteLLM has the most mature, and broadest range of unified api's x providers. This means you do not need to give developers raw LLM API keys, ever.
We see devs using/building agents that consume a lot of different API's - responses api, realtime, chat completions, messages - and no matter what they use we want them to be able to switch across providers without if/else statements in their code.
I can't comment on others, but that's our goal and what we work on doing everyday. So I would trust that we do it well.
Beyond that, we're also growing to become the single point of access for all AI resources. This makes it a lot easier when building agents, because you can give an agent 1 key, and it will have access to LLM's + MCP's (and in the future other resources like skills, api credentials, sandbox api's, etc.).
Comment · 5 months ago
this is pretty interesting. nice work!
Comment · 7 months ago
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 ([email protected]), or join the discussion on github (https://lnkd.in/g9TuuQ2H).
Comment · 7 months ago
I deleted it, to be safe.
Comment · 7 months ago
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.).
Comment · 7 months ago
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 - [email protected]
Comment · 7 months ago
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 blocks all downloads.
We are investigating the issue, and seeing how we can harden things. I'm sorry for this.
- Krrish