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

I updated my global configs to set min release age to 7 days:

  ~/.config/uv/uv.toml
  exclude-newer = "7 days"
  
  ~/.npmrc
  min-release-age=7 # days
  
  ~/Library/Preferences/pnpm/rc
  minimum-release-age=10080 # minutes
  
  ~/.bunfig.toml
  [install]
  minimumReleaseAge = 604800 # seconds

I made this tool for macos systems that helps detect when a package accesses something it shouldn't. it's a tiny go binary (less than 2k LOC) with no dependencies that will mount a webdav filesystem (no root) or NFS (root required) with fake secrets and send you a notification when anything accesses it. Very stupid simple. I've always really liked the canary/honeypot approach and this at least may give some folks a chance to detect (similar to like LittleSnitch) when something strange is going on!

Next time the attack may not have an obvious performance issue!

https://ramimac.me/trivy-teampcp/#phase-09

I would expect better spam detection system from GitHub. This is hardly acceptable.

Even still though, we can't really trust any open-source software any more that has third party dependencies, because the chains can be so complex and long it's impossible to vet everything.

It's just too easy to spam out open-source software now, which also means it's too easy to create thousands of infected repos with sophisticated and clever supply chain attacks planted deeply inside them. Ones that can be surfaced at any time, too. LLMs have compounded this risk 100x.

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

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.

Since they all seem positive, it doesn't seem like an attack but I thought the general etiquette for github issues was to use the emoji reactions to show support so the comment thread only contains substantive comments.

Do the labs label code versions with an associated CVE to label them as compromised (telling the model what NOT to do)? Do they do adversarial RL environments to teach what's good/bad? I'm very curious since it's inevitable some pwned code ends up as training data no matter what.

> ### 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...

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

Configure the CI to make a release with the artefacts attached. Then have an entirely private repo that can't be triggered automatically as the publisher. The publisher repo fetches the artefacts and does the pypi/npm/whatever release.

or pyproject.toml (not possible to filter based on absence of a uv.lock, but at a glance it's missing from many of these): https://github.com/search?q=path%3A*%2Fpyproject.toml+%22%5C...

or setup.py: https://github.com/search?q=path%3A*%2Fsetup.py+%22%5C%22lit...

https://inspector.pypi.io/project/litellm/1.82.8/packages/fd...

It would be interesting if Python, NPM, Rubygems, etc all just decided to initiate an ecosystem-wide credential reset. On one hand, it would be highly disruptive. On the other hand, it would probably stop the damage from spreading.

We are looking at similar attack vectors (pth injection), signatures etc. in other PyPI packages that we know of.

https://github.com/crewAIInc/crewAI/commit/8d1edd5d65c462c3d...

The package was directly compromised, not “by supply chain attack”.

If you use the compromised package, your supply chain is compromised.

it does a lot of CPU intensive work

    spawn background python
    decode embedded stage
    run inner collector
    if data collected:
        write attacker public key
        generate random AES key
        encrypt stolen data with AES
        encrypt AES key with attacker RSA pubkey
        tar both encrypted files
        POST archive to remote host

They also seem to be spilling into HN [1].

Runaway AI agents? A meme I'm to old to understand?

[1] https://news.ycombinator.com/item?id=47508315

This stupidity is squarely on GitHub CI. Trivy is also bad here but the blast radius should have been more limited.

What is the source of compromise?

Does anyone have a list of other compromised projects?

[1]: https://pypi.org/project/litellm/#history

I guess I am lucky as I have watchtower automatically update all my containers to the latest image every morning if there are new versions.

I also just added it to my homelab this sunday, I guess that's good timing haha.

Also the repo is so active that it's very hard to understand the state of issues and PRs, and the 'day 0' support for GPT-5.4-nano took over a week! Still, tough situation for the maintainers who got hacked.

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, then the blast radius of compromises widens. That's why I think there's an argument for least-privilege by default--agents should have scoped, auditable authority over what they can install and execute, and approval for anything outside the boundaries.

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.[78]' {} \; 2>/dev/null

Basically, have all releases require multi-factor auth from more than one person before they go live.

A single person being compromised either technically, or by being hit on the head with a wrench, should not be able to release something malicious that effects so many people.

https://github.com/krrishdholakia/blockchain/commit/556f2db3...

  - # blockchain
  - Implements a skeleton framework of how to mine using blockchain, including the consensus algorithms.
  + teampcp owns BerriAI

There is also the need for data sanitation, because the attacker could distribute compromised files through user’s data which will later be run and compromise the host.

https://github.com/Nayjest/lm-proxy

``` pip install lm-proxy ```

Guys, sorry, as the author of a competing opensource product, I couldn’t resist

What about reducing the number of dependencies ? Integrating core functionalities in builtin language libraries ? Avoiding frequent package updates ? Avoiding immature/experimental packages from developers of unknown reliability ?

Those issues are grave. I see no future when those get rarer, and I am afraid they may wipe the open-source movement credibility.

This would also disable site import so not viable generically for everyone without testing.

if you have tips i am sure they are welcome. snark remarks are useless. dont be a sourpuss. if you know better, help the remediation effort.

[1]: https://pypi.org/project/litellm/

Migration guide: https://llmgateway.io/migration/litellm

This was taught in the 90s. Sad to see that lesson fading away.

That's why I'm building https://github.com/kstenerud/yoloai

First Trivy (which got compromised twice), now LiteLLM.

I'm sensing a pattern here, hmm.

The Python ecosystem provides too many nooks and crannies for malware to hide in.

I hope that everyone's course of action will be uninstalling this package permanently, and avoiding the installation of packages similar to this.

In order to reduce supply chain risk not only does a vendor (even if gratis and OS) need to be evaluated, but the advantage it provides.

Exposing yourself to supply chain risk for an HTTP server dependency is natural. But exposing yourself for is-odd, or whatever this is, is not worth it.

Remember that you are programmers and you can just program, you don't need a framework, you are already using the API of an LLM provider, don't put a hat on a hat, don't get killed for nothing.

And even if you weren't using this specific dependency, check your deps, you might have shit like this in your requirements.txt and was merely saved by chance.

An additional note is that the dev will probably post a post-mortem, what was learned, how it was fixed, maybe downplay the thing. Ignore that, the only reasonable step after this is closing a repo, but there's no incentive to do that.

It's pretty disappointing that safetensors has existed for multiple years now but people are still distributing pth files. Yes it requires more code to handle the loading and saving of models, but you'd think it would be worth it to avoid situations like this.

Hundreds of downvoted comments like "Worked like a charm, much appreciated.", "Thanks, that helped!", and "Great explanation, thanks for sharing."

   # add any dependency file patterns
   osv-scanner -r .

An actual infosec audit would have rigorously enforced basic security best practices in preventing this supply chain attack.

[0] https://news.ycombinator.com/item?id=47502754

https://www.youtube.com/watch?v=aoag03mSuXQ