44 ms·

Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

• maxothex 6mo ago
  [dead]
• johnhenry 6mo ago
  I've been developing an alternative to LiteLLM. Javascript. No dependencies. https://github.com/johnhenry/ai.matey/ https://github.com/johnhenry/ai.matey/
• dev_tools_lab 6mo ago
  Good reminder to pin dependency versions and verify checksums. SHA256 verification should be standard for any tool that makes network calls.
• foota 6mo ago
  Somewhat unrelated, but if I have downloaded node modules in the last couple days, how should I best figure out if I've been hacked?
• arrty88 6mo ago
  Oooof another one. I think i will lock my deps to versions at least 3 months old.
• ilusion 6mo ago
  Does this mean opencode (and other such agent harnesses that auto update) might also be compromised?
• sudorm 6mo ago
  are there any timestamps available when the malicious versions were published on pypi? I can't find anything but that now the last "good" version was published on march 22.
  • sudorm 6mo ago
    according to articles the first malicious version was published at roughly 8:30 UTC and the pypi repo taken down at ~11:25 UTC.
• Acacian 6mo ago
  [dead]
• yonarbel 6mo ago
  [dead]
• jcarrano 6mo ago
  Thinking how a secure setup for uploading packages from a CI would look like: the package must be signed by the devs, and for that they must build it independently on their machines (this requires a reproducible build).
• astrostl 6mo ago
  FWIW I vibe coded https://github.com/astrostl/surplies https://github.com/astrostl/surplies to detect evidence of the Axios and LiteLLM malware, using StepSecurity's writeups as a data source.
• bustah 6mo ago
  [flagged]
• osaka2077 6mo ago
  [dead]
• deleted 6mo ago
  [deleted]
• dot_treo 6mo ago
  [dead]
• matrixgard 6mo ago
  [dead]
• bfeynman 6mo ago
  pretty horrifying. I only use it as lightweight wrapper and will most likely move away from it entirely. Not worth the risk
  • dot_treo 6mo ago
    Even just having an import statement for it is enough to trigger the malware in 1.82.8.
• iwhalen 6mo ago
  What is happening in this issue thread? Why are there 100+ satisfied slop comments?
  • kevml 6mo ago
    Potentially compromised?
  • cirego 6mo ago
    First thing I noticed too.
  • nubg 6mo ago
    Are they trying to slide stuff down? but it just bumps stuff up?
  • bakugo 6mo ago
    Attackers trying to stifle discussion, they did the same for trivy: https://github.com/aquasecurity/trivy/discussions/10420 https://github.com/aquasecurity/trivy/discussions/10420
    • Imustaskforhelp 6mo ago
      I have created an comment to hopefully steer the discussion towards hackernews if the threat actor is stifling genuine comments in github by spamming that thread with 100's of accounts https://github.com/BerriAI/litellm/issues/24512#issuecomment-4118284547 https://github.com/BerriAI/litellm/issues/24512#issuecomment...
• kevml 6mo ago
  More details here: https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/ https://futuresearch.ai/blog/litellm-pypi-supply-chain-attac...
  • deleted 6mo ago
    [deleted]
  • ddp26 6mo ago
    Yeah, this was my team at FutureSearch that had the lucky experience of being first to hit this, before the malware was disclosed. One thing not in that writeup is that very little action was needed for my engineer to get pwnd. uvx automatically pulled latest litellm (version unpinned) and built the environment. Then Cursor started up the local MCP server automatically on load.
• cpburns2009 6mo ago
  You can see it for yourself here: https://inspector.pypi.io/project/litellm/1.82.8/packages/fd/78/2167536f8859e655b28adf09ee7f4cd876745a933ba2be26853557775412/litellm-1.82.8-py3-none-any.whl/litellm_init.pth https://inspector.pypi.io/project/litellm/1.82.8/packages/fd...
  • deleted 6mo ago
    [deleted]
  • jbkkd 6mo ago
    Two URLs found in the exploit: https://checkmarx.zone/raw https://checkmarx.zone/raw https://models.litellm.cloud/ https://models.litellm.cloud/
    • tinix 6mo ago
      these links trigger prefetch in chrome (doesn't respect nofollow rel). I got popped by our security team, they were convinced I had this malware because my machine attempted to connect to the checkmarx domain. clearly a false positive but I still had to roll credentials and wipe my machine.
• bratao 6mo ago
  Look like the Founder and CTO account has been compromised. https://github.com/krrishdholakia https://github.com/krrishdholakia
  • franktankbank 6mo ago
    [flagged]
  • jadamson 6mo ago
    Most his recent commits are small edits claiming responsibility on behalf of "teampcp", which was the group behind the recent Trivy compromise: https://news.ycombinator.com/item?id=47475888 https://news.ycombinator.com/item?id=47475888
    • soco 6mo ago
      I was just wondering why the Trivy compromise hit only npm packages, thinking that bigger stuff should appear sooner or later. Here we go...
      • deleted 6mo ago
        [deleted]
  • deleted 6mo ago
    [deleted]
• deep_noz 6mo ago
  good i was too lazy to bump versions
  • jadamson 6mo ago
    In case you missed it, according to the OP, the previous point release (1.82.7) is also compromised.
    • dot_treo 6mo ago
      Yeah, that release has the base64 blob, but it didn't contain the pth file that auto triggers the malware on import.
      • jadamson 6mo ago
        The latest version with the the pth file doesn't require an import to trigger the exploit (just having the package installed is enough thanks to [1]). The previous version triggers on `import litellm.proxy` Again, all according to the issue OP. [1] https://docs.python.org/3/library/site.html https://docs.python.org/3/library/site.html
• hiciu 6mo ago
  Besides main issue here, and the owners account being possibly compromised as well, there's like 170+ low quality spam comments in there. I would expect better spam detection system from GitHub. This is hardly acceptable.
  • orf 6mo ago
    i'm guessing it's accounts they have compromised with the stealer.
    • ebonnafoux 6mo ago
      They repeat only six sentences during 100+ comments: Worked like a charm, much appreciated. This was the answer I was looking for. Thanks, that helped! Thanks for the tip! Great explanation, thanks for sharing. This was the answer I was looking for.
      • dec0dedab0de 6mo ago
        Over the last ~15 years I have been shocked by the amount of spam on social networks that could have been caught with a Bayesian filter. Or in this case, a fairly simple regex.
        • Imustaskforhelp 6mo ago
          Well, large companies/corporations don't care about Spam because they actually benefit from spam in a way as it boosts their engagement ratio It just doesn't have to be spammed enough that advertisers leave the platform and I think that they sort of succeed in doing so. Think about it, if Facebook shows you AI slop ragebait or any rage-inducing comment from multiple bots designed to farm attention/for malicious purposes in general, and you fall for it and show engagement to it on which it can show you ads, do you think it has incentive to take a stance against such form of spam
          • dec0dedab0de 6mo ago
• nickspacek 6mo ago
  teampcp taking credit? https://github.com/krrishdholakia/blockchain/commit/556f2db38e98bff4495ced183ea6253c5a68bfe0 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
• rgambee 6mo ago
  Seems that the GitHub account of one of the maintainers has been fully compromised. They closed the GitHub issue for this problem. And all their personal repos have been edited to say "teampcp owns BerriAI". Here's one example: https://github.com/krrishdholakia/blackjack_python/commit/8ffc7989a2eabb85fc59729faa119be4bac2aded https://github.com/krrishdholakia/blackjack_python/commit/8f...
• rgambee 6mo ago
  Looking forward to a Veritasium video about this in the future, like the one they recently did about the xz backdoor.
  • stavros 6mo ago
    That was massively more interesting, this is just a straight-up hack.
  • johanyc 6mo ago
    I don't expect one. This kind of attack is pretty common nowadays. The xz attack was special for how long the guy worked for it and how severe it could have been
• peytongreen_dev 6mo ago
  [flagged]
• TZubiri 6mo ago
  Thank you for posting this, interesting. 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.
  • xinayder 6mo ago
    > 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. Programming for different LLM APIs is a hassle, this library made it easy by making one single API you call, and in the backstage it handled all the different API calls you need for different LLM providers.
    • otabdeveloper4 6mo ago
      There's only two different LLM APIs in practice (Anthropic and everyone else), and the differences are cosmetic. This is like a couple hours of work even without vibe coding tools.
      • dragonwriter 6mo ago
        > There's only two different LLM APIs in practice (Anthropic and everyone else), and the differences are cosmetic. There's more than that (even if most other systems also provide a OpenAI compatible API which may or may not expose either all features of the platform or all features of the OpenAI API), and the differences are not cosmetic, but since LiteLLM itself just presents an OpenAI-compatible API, it can't be providing acccess to other vendor features that don't map cleanly to that API, and I don't think its likely to be using the native API for each and being more complete in its OpenAI-compatible implementation of even the features that map naturally than the first-party OpenAI-compatibility APIs.)
• sschueller 6mo ago
  Does anyone know a good alternate project that works similarly (share multipple LLMs across a set of users)? LiteLLM has been getting worse and trying to get me to upgrade to a paid version. I also had issues with creating tokens for other users etc.
  • tacoooooooo 6mo ago
    pydantic-ai
  • river_otter 6mo ago
    github.com/mozilla-ai/any-llm :)
  • sschueller 6mo ago
    I just found https://github.com/jasmedia/InferXgate https://github.com/jasmedia/InferXgate which looks interesting although quite new and not supporting so many providers.
  • redrove 6mo ago
    Bifrost is the only real alternative I'm aware of https://github.com/maximhq/bifrost https://github.com/maximhq/bifrost
    • sschueller 6mo ago
      Virtual Keys is an Enterprise feature. I am not going to pay for something like this in order to provide my family access to all my models. I can do without cost control (although it would be nice) but I need for users to be able to generate a key and us this key to access all the models I provide.
      • NeutralCrane 6mo ago
        I don’t believe it is an enterprise feature. I did some testing on Bifrost just last month on a free open source instance and was able to set up virtual keys.
      • 6mo ago
• postalcoder 6mo ago
  This is a brutal one. A ton of people use litellm as their gateway.
  • Imustaskforhelp 6mo ago
    Do you feel as if people will update litellm without looking at this discussion/maybe having it be automatic which would then lead to loss of crypto wallets/ especially AI Api keys? Now I am not worried about the Ai Api keys having much damage but I am thinking of one step further and I am not sure how many of these corporations follow privacy policy and so perhaps someone more experienced can tell me but wouldn't these applications keep logs for legal purposes and those logs can contain sensitive information, both of businesses but also, private individuals perhaps too?
    • daveguy 6mo ago
      Maybe then people will start to realize crypto isn't even worth the stored bits. Irrevocable transfers... What could go wrong?
  • eoskx 6mo ago
    Not just as a gateway in a lot cases, but CrewAI and DSPy use it directly. DSPy uses it as its only way to call upstream LLM providers and CrewAI falls back to it if the OpenAI, Anthropic, etc. SDKs aren't available.
• mikert89 6mo ago
  Wow this is in a lot of software
  • eoskx 6mo ago
    Yep, DSPy and CrewAI have direct dependencies on it. DSPy uses it as its primary library for calling upstream LLM providers and CrewAI falls back to it I believe if the OpenAI, Anthropic, etc. SDKs aren't available.
• Imustaskforhelp 6mo ago
  Our modern economy/software industry truly runs on egg-shells nowadays that engineers accounts are getting hacked to create a supply-chain attack all at the same time that threat actors are getting more advanced partially due to helps of LLM's. First Trivy (which got compromised twice), now LiteLLM.
• 6thbit 6mo ago
  title is bit misleading. The package was directly compromised, not “by supply chain attack”. If you use the compromised package, your supply chain is compromised.
  • dlor 6mo ago
    It's both. They got compromised by another supply chain attack on Trivy initially.
• intothemild 6mo ago
  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
  • hmokiguess 6mo ago
    What is Harness?
    • intothemild 6mo ago
      Sorry i mean Harbor.. was running terminal bench
  • abhikul0 6mo ago
    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?
    • abhikul0 6mo ago
      Well, I reinstalled and finally upgraded to Tahoe.
  • swyx 6mo ago
    > i was lucky to see my processes before the system hard locked. how do you do that? have Activity Monitor up at all times?
    • intothemild 6mo ago
      btop
    • krackers 6mo ago
• chillfox 6mo ago
  Now I feel lucky that I switched to just using OpenRouter a year ago because LiteLLM was incredible flaky and kept causing outages.
• gkfasdfasdf 6mo ago
  Someone needs to go to prison for this.
• 6thbit 6mo ago
  Worth exploring safeguard for some: The automatic import can be suppressed using Python interpreter’s -S option. This would also disable site import so not viable generically for everyone without testing.
  • cpburns2009 6mo ago
    The 1.82.7 exploit was executed on import. The 1.82.8 exploit used a pth file which is run at start up (module discovery basically).
  • zahlman 6mo ago
    It's not really "automatic import", as described. The exploit is directly contained in the .pth file; Python allows arbitrary code to run from there, with some restrictions that are meant to enforce a bit of sanity for well-meaning users and which don't meaningfully mitigate the security risk. As described in https://docs.python.org/3/library/site.html https://docs.python.org/3/library/site.html : > Lines starting with import (followed by space or tab) are executed.... The primary intended purpose of executable lines is to make the corresponding module(s) importable (load 3rd-party import hooks, adjust PATH etc). So what malware can do is put something in a .pth file like import sys;exec("evil stringified payload") and all restrictions are trivially bypassed. It used to not even require whitespace after `import`, so you could even instead do something like import_=exec("evil stringified payload") In the described attack, the imports are actually used; the standard library `subprocess` is leveraged to exec the payload in a separate Python process. Which, since it uses the same Python environment, is also a fork bomb (well, not in the traditional sense; it doesn't grow exponentially, but will still cause a problem). .pth files have worked this way since 2.1 (comparing https://docs.python.org/2.1/lib/module-site.html https://docs.python.org/2.1/lib/module-site.html to https://docs.python.org/2.0/lib/module-site.html https://docs.python.org/2.0/lib/module-site.html). As far as I can tell there was no PEP for that change.
• ramimac 6mo ago
  This is tied to the TeamPCP activity over the last few weeks. I've been responding, and keeping an up to date timeline. I hope it might help folks catch up and contextualize this incident: https://ramimac.me/trivy-teampcp/#phase-09 https://ramimac.me/trivy-teampcp/#phase-09
  • miraculixx 6mo ago
    This is interesting. How do you keep this up to date so quickly?
    • ramimac 6mo ago
      Blood, sweat, and tears. The investment compounds! I have enough context to quickly vet incoming information, then it's trivial to update a static site with a new blurb
  • itintheory 6mo ago
    Thanks for putting this together. I've been seeing the name TeamPCP pop up all over, but hadn't seen everything in one place.
  • ctmnt 6mo ago
    This is fantastic, thank you. Your reporting has been great. But also, damn, the playlist.
• 0fflineuser 6mo ago
  I was running it (as a proxy) in my homelab with docker compose using the litellm/litellm:latest image https://hub.docker.com/layers/litellm/litellm/latest/images/sha256-8c126416da606bad27c5d48cc2f8e526ca69fe5711009bf3c132d53eb3c536b9 https://hub.docker.com/layers/litellm/litellm/latest/images/... , I don't think this was compromised as it is from 6 months ago and I checked it is the version 1.77. 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.
• fratellobigio 6mo ago
  It's been quarantined on PyPI
• ddactic 6mo ago
  [dead]
• oncelearner 6mo ago
  That's a bad supply-chain attack, many folks use litellm as main gateway
  • rdevilla 6mo ago
    laughs smugly in vimscript
• cpburns2009 6mo ago
  LiteLLM is now in quarantine on PyPI [1]. Looks like burning a recovery token was worth it. [1]: https://pypi.org/project/litellm/ https://pypi.org/project/litellm/
• rdevilla 6mo ago
  It will only take one agent-led compromise to get some Claude-authored underhanded C into llvm or linux or something and then we will all finally need to reflect on trusting trust at last and forevermore.
  • MuteXR 6mo ago
    You know that people can already write backdoored code, right?
    • ipython 6mo ago
      But now you have compromise _at scale_. Before poor plebs like us had to artisinally craft every back door. Now we have a technology to automate that mundane exploitation process! Win!
      • MuteXR 6mo ago
        You still have a human who actually ends up reviewing the code, though. Now if the review was AI powered... (glances at openclaw)
    • dec0dedab0de 6mo ago
      Yeah, and they can write code with vulnerabilities by accident. But this is a new class of problem, where a known trusted contributor can accidentally allow a vulnerability that was added on purpose by the tooling.
  • Imustaskforhelp 6mo ago
    If that would happen, The worry I would have is of all the sensitive Government servers from all over the world which might be then exploited and the amount of damage which can be caused silently by such a threat actor or something like AWS/GCP/these massive hyperscalers which are also used by the governments around the globe at times. The possibilities within a good threat could be catastrophic if we assume so, and if we assume nation-states to be interested in sponsoring hacking attacks (which many nations already do) to attack enemy nations/gain leverage. We are looking at damage within Trillions at that point. But I would assume that Linux might be safe for now, it might be the most looked at code and its definitely something safe. LLVM might be a bit more interesting as it might go a little unnoticed but hopefully people who are working at LLVM are well funded/have enough funding to take a look at everything carefully to not have such a slip up.
• nickvec 6mo ago
  Looks like all of the LiteLLM CEO’s public repos have been updated with the description “teampcp owns BerriAI” https://github.com/krrishdholakia https://github.com/krrishdholakia
• otabdeveloper4 6mo ago
  LiteLLM is the second worst software project known to man. (First is LangChain. Third is OpenClaw.) I'm sensing a pattern here, hmm.
  • nickvec 6mo ago
    Not familiar with LangChain besides at a surface level - what makes it the worst software project known to man?
    • eoskx 6mo ago
      LangChain at least has its own layer for upstream LLM provider calls, which means it isn't affected by this supply chain compromise. 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.
    • otabdeveloper4 6mo ago
      You have to see it to believe it. Feel the vibes.
  • ting0 6mo ago
    LLMs recommend LiteLLM, so its popularity will only continue.
• hahaddmmm12x 6mo ago
  [flagged]
  • dang 6mo ago
    Automated comments aren't allowed here. Please stop. https://news.ycombinator.com/newsguidelines.html#generated https://news.ycombinator.com/newsguidelines.html#generated
    • sta1n 6mo ago
      [dead]
• shay_ker 6mo ago
  A general question - how do frontier AI companies handle scenarios like this in their training data? If they train their models naively, then training data injection seems very possible and could make models silently pwn people. 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.
  • Imustaskforhelp 6mo ago
    I am pretty sure that such measures aren't taken by AI companies, though I may be wrong.
    • alansaber 6mo ago
      The API/online model inference definitely runs through some kind of edge safeguarding models which could do this.
  • tomaskafka 6mo ago
    Everyone’s (well, except Anthropic, they seem to have preserved a bit of taste) approach is the more data the better, so the databases of stolen content (erm, models) are memorizing crap.
  • datadrivenangel 6mo ago
    This was a compromise of the library owners github acccounts apparently, so this is not a related scenario to dangerous code in the training data. I assume most labs don't do anything to deal with this, and just hope that it gets trained out because better code should be better rewarded in theory?
  • Havoc 6mo ago
    By betting that it dilutes away and not worrying about it too much. Bit like dropping radioactive barrels into the deep ocean.
• kstenerud 6mo ago
  We need real sandboxing. Out-of-process sandboxing, not in-process. The attacks are only going to get worse. That's why I'm building https://github.com/kstenerud/yoloai https://github.com/kstenerud/yoloai
• xinayder 6mo ago
  When something like this happens, do security researchers instantly contact the hosting companies to suspend or block the domains used by the attackers?
  • redrove 6mo ago
    First line of defense is the git host and artifact host scrape the malware clean (in this case GitHub and Pypi). Domains might get added to a list for things like 1.1.1.2 but as you can imagine that has much smaller coverage, not everyone uses something like this in their DNS infra.
    • itintheory 6mo ago
      This threat actor is also using Internet Computer Protocol (ICP) "Canisters" to deliver payloads. I'm not too familiar with the project, but I'm not sure blocking domains in DNS would help there.
• mitul005 6mo ago
  [flagged]
• dec0dedab0de 6mo ago
  github, pypi, npm, homebrew, cpan, etc etc. should adopt a multi-multi-factor authentication approach for releases. Maybe have it kick in as a requirement after X amount of monthly downloads. 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.
  • worksonmine 6mo ago
    And how would that work for single maintainer projects?
    • dec0dedab0de 6mo ago
      They would have to find someone else if they grew too big. Though, the secondary doesn't necessarily have to be a maintainer or even a contributor on the project. It just needs to be someone else to do a sanity check, to make sure it is an actual release. Heck, I would even say that as the project grows in popularity, the amount of people required to approve a release should go up.
      • worksonmine 6mo ago
        So if I'm developing something I want to use and the community finds it useful but I take no contributions and no feature requests I should have to find another person to deal with? How do I even know who to trust, and what prevents two people from conspiring together with a long con? Sounds great on the surface but I'm not sure you've thought it through.
        • dec0dedab0de 6mo ago
          It wouldn't prevent a project that has a goal of being purposely malicious, just from pushing out releases that aren't actually releases. As far as who to trust, I could imagine the maintainers of different high-level projects helping each other out in this way. Though, if you really must allow a single user to publish releases to the masses using existing shared social infrastructure. Then you could mitigate this type of attack by adding in a time delay, with the ability for users to flag. So instead of immediately going live, add in a release date, maybe even force them to mention the release date on an external system as well. The downside with that approach is that it would limit the ability to push out fixes as well. But I think I am OK with saying if you're a solo developer, you need to bring someone else on board or host your builds yourself.
• 0123456789ABCDE 6mo ago
  airflow, dagster, dspy, unsloth.ai, polar
• eoskx 6mo ago
  This is bad, especially from a downstream dependency perspective. DSPy and CrewAI also import LiteLLM, so you could not be using LiteLLM as a gateway, but still importing it via those libraries for agents, etc.
  • nickvec 6mo ago
    Wow, the postmortem for this is going to be brutal. I wonder just how many people/orgs have been affected.
    • eoskx 6mo ago
      Yep, I think the worst impact is going to be from libraries that were using LiteLLM as just an upstream LLM provider library vs for a model gateway. Hopefully, CrewAI and DSPy can get on top of it soon.
  • benatkin 6mo ago
    I'm surprised to see nanobot uses LiteLLM: https://github.com/HKUDS/nanobot https://github.com/HKUDS/nanobot LiteLLM wouldn't be my top choice, because it installs a lot of extra stuff. https://news.ycombinator.com/item?id=43646438 https://news.ycombinator.com/item?id=43646438 But it's quite popular.
    • flux3125 6mo ago
      I completely removed nanobot after I found that. Luckily, I only used it a few times and inside a docker container. litellm 1.82.6 was the latest version I could find installed, not sure if it was affected.
• xunairah 6mo ago
  Version 1.82.7 is also compromised. It doesn't have the pth file, but the payload is still in proxy/proxy_server.py.
• tom_alexander 6mo ago
  Only tangentially related: Is there some joke/meme I'm not aware of? The github comment thread is flooded with identical comments like "Thanks, that helped!", "Thanks for the tip!", and "This was the answer I was looking for." 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.
  • nickvec 6mo ago
    Ton of compromised accounts spamming the GH thread to prevent any substantive conversation from being had.
    • tom_alexander 6mo ago
      Oh wow. That's a lot of compromised accounts. Guess I was wrong about it not being an attack.
  • incognito124 6mo ago
    In the thread: > It also seems that attacker is trying to stifle the discussion by spamming this with hundreds of comments. I recommend talking on hackernews if that might be the case.
  • jbkkd 6mo ago
    Those are all bots commenting, and now exposing themselves as such.
  • Imustaskforhelp 6mo ago
    Bots to flood the discussion to prevent any actual conversation.
  • vultour 6mo ago
    These have been popping up on all the TeamPCP compromises lately
• jFriedensreich 6mo ago
  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 requirements we have for agent runtimes, lets use this momentum to make our dev environments safer! In such an environment the container would crash, we see the violations, delete it and dont' have to worry about it. We should treat this as an everyday possibility not as an isolated security incident.
  • kalib_tweli 6mo ago
    Would value your opinion on my project to isolate creds from the container: https://github.com/calebfaruki/tightbeam https://github.com/calebfaruki/tightbeam https://github.com/calebfaruki/airlock https://github.com/calebfaruki/airlock This is literally the thing I'm trying to protect against.
    • jFriedensreich 6mo ago
      I would split the agent loop totally from the main project of tightbeam, no one wants yet another new agent harness we need to focus on the operational problems. Airlock seems interesting in theory but its really hard to believe this could capture every single behaviour of the native local binaries, we need the native tools with native behaviour otherwise might as well use something like MCP. I would bet more on a git protocol proxy and native solutions for each of these.
      • kalib_tweli 6mo ago
        Good points across the board. I ran into a lot of problems auditing the security of my approach and it was just too easy to circumvent. First lesson was that the architecture had to be secure in structure, not configuration. Otherwise, a novice will run claude code on the host machine and just bork the entire setup. So now I've replaced tightbeam runtime with a small runtime on the workspace container. Tightbeam and Airlock have been moved to separate pods. So you don't need network egress on the workspace pod at all. Secondly, I'm isolating credentials on Tightbeam and Airlock with k8s jobs. Rather than airlock full CLI commands, you just create "airlock tools" with k8s secrets. Airlock controller never sees the secret. The tool could be like "git-create-branch" and "gh-create-pr". Tightbeam is pretty much symmetrical. LLM credentials are tied to jobs. I'm tying them together into a unified architecture now. Please do let me know if you have additional thoughts!
• mohsen1 6mo ago
  If it was not spinning so many Python processes and not overwhelming the system with those (friends found out this is consuming too much CPU from the fan noise!) it would have been much more successful. So similar to xz attack 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
  • deleted 6mo ago
    [deleted]
  • franktankbank 6mo ago
    I can't tell which part of that is expensive unless many multiples of python are spawned at the same time. Are any of the payloads particularly large?
• rsmtjohn 6mo ago
  [flagged]
• detente18 6mo 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&type=code https://github.com/search?q=repo%3ABerriAI%2Flitellm%20trivy... https://ramimac.me/trivy-teampcp/#phase-09 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
  • redrove 6mo ago
    >1. Looks like this originated from the trivvy used in our ci/cd Were you not aware of this in the short time frame that it happened in? How come credentials were not rotated to mitigate the trivy compromise?
    • wheelerwj 6mo ago
      The latest trivy attack was announced just yesterday. If you go out to dinner or take a night off its totally plausible to have not seen it.
      • franktankbank 6mo ago
        [flagged]
        • embedding-shape 6mo ago
          Probably more "serious human" than "serious over-capitalist" or "seriously overworked". Good for them.
      • anishgupta 6mo ago
        afaik the trivy attack was first in the news on March 19th for the github actions and for docker images it was on March 23rd
• Blackthorn 6mo ago
  Edit: ignore this silliness, as it sidesteps the real problem. Leaving it here because we shouldn't remove our own stupidity. 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.
  • cpburns2009 6mo ago
    safetensors is just as vulnerable to this sort of exploit using a pth file since it's a Python package.
    • Blackthorn 6mo ago
      Yeah, fair enough, the problem here is that the credentials were stolen, the fact that the exploit was packaged into a .pth is just an implementation detail.
• cedws 6mo ago
  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.
  • varenc 6mo ago
    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?
    • cedws 6mo ago
      Yes, trying to slow down response.
  • driftnode 6mo ago
    whats new isnt the shortcuts, its the cascading. one compromised trivy instance led to kics led to litellm led to dspy and crewai and mlflow and hundreds of mcp servers downstream. the attacker didnt need to find five separate vulnerabilities, they found one and rode the dependency graph. thats a fundamentally different threat model than what most security tooling is built around
• danielvaughn 6mo ago
  I work with security researchers, so we've been on this since about an hour ago. One pain I've really come to feel is the complexity of Python environments. They've always been a pain, but in an incident like this, where you need to find whether an exact version of a package has ever been installed on your machine. All I can say is good luck. The Python ecosystem provides too many nooks and crannies for malware to hide in.
• te_chris 6mo ago
  I reviewed the LiteLLM source a while back. Without wanting to be mean, it was a mess. Steered well clear.
  • rnjs 6mo ago
    Terrible code quality and terrible docs
• zhisme 6mo ago
  Am I the only one having feeling that with LLM-era we have now bigger amount of malicious software lets say parsers/fetchers of credentials/ssh/private keys? And it is easier to produce them and then include in some 3rd party open-source software? Or it is just our attention gets focused on such things?
• hmokiguess 6mo ago
  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.[78]' {} \; 2>/dev/null
  • persedes 6mo ago
    there's probably a more precise way, but if you're on uv: rg litellm --iglob='*.lock'
  • lukewarm707 6mo ago
    these days, i just use a private llm. it's very quick and when i see the logs, it does a better job than me for this type of task. no i don't let it connect to web...
• wswin 6mo ago
  I will wait with updating anything until this whole trivy case gets cleaned up.
• f311a 6mo ago
  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 https://github.com/rushter/hexora
  • samsk 6mo ago
    Interesting tool, will definitely try - just curious, is there a tool (hexora checker) that ensures that hexora itself and its dependencies are not compromised ? And of course if there is one, I'll need another one for the hexora checker....
    • f311a 6mo ago
      There is no such tool, but you can use other static analyzers. Datadog also has one, but it's not AST-based.
    • hmokiguess 6mo ago
      https://xkcd.com/2044/ https://xkcd.com/2044/
  • ting0 6mo ago
    And easily bypassed by an attacker who knows about your static analysis tool who can iterate on their exploit until it no longer gets flagged.
    • fernandotakai 6mo ago
      the main things are: 1. pin dependencies with sha signatures 2. mirror your dependencies 3. only update when truly necessary 4. at first, run everything in a sandbox.
• santiagobasulto 6mo ago
  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-software-engineering/ https://sb.thoughts.ar/posts/2025/12/03/ai-is-all-about-soft...
  • eoskx 6mo ago
    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.
  • driftnode 6mo ago
    the requests.post advice is right but its also kind of depressing that the state of the art recommendation for using llm apis safely in 2026 is to just write the http call yourself. we went from dont reinvent the wheel to actually maybe reinvent it because the wheel might steal your ssh keys. the abstraction layer that was supposed to save you time just cost an unknown number of people every credential on their machine
• tom-blk 6mo ago
  Stuff like is happening too much recently. Seems like the more fast paced areas of development would benefit from a paradigm shift
  • sirl1on 6mo ago
    Move Slow and Fix Things.
• thibault000 6mo ago
  [dead]
• segalord 6mo ago
  LiteLLM has like a 1000 dependencies this is expected https://github.com/BerriAI/litellm/blob/main/requirements.txt https://github.com/BerriAI/litellm/blob/main/requirements.tx...
  • zahlman 6mo ago
    Oof. What exactly is supposed to be "lite" about this?
• mark_l_watson 6mo ago
  A question from a non-python-security-expert: is committing uv.lock files for specific versions, and only infrequently updating versions a reasonable practice?
  • Imustaskforhelp 6mo ago
    (I am not a security expert either) But, one of the arguments that I saw online from this was that when a security researcher finds a bug and reports it to the OSS project/Company they then fix the code silently and include it within the new version and after some time, they make the information public So if you run infrequently updated versions, then you run a risk of allowing hackers access as well. (An good example I can think of is OpenCode which had an issue which could allow RCE and the security researcher team asked Opencode secretly but no response came so after sometime of no response, they released the knowledge in public and Opencode quickly made a patch to fix that issue but if you were running the older code, you would've been vulnerable to RCE)
    • mark_l_watson 6mo ago
      Good points. Perhaps there is a way to configure uv to only use a new version if it is 24 hours old?
      • arwt 6mo ago
        You can. See: https://docs.astral.sh/uv/reference/cli/#uv-run--exclude-newer https://docs.astral.sh/uv/reference/cli/#uv-run--exclude-new... How you use it depends on your workflow. An entry like this in your pyproject.toml could suffice: [tool.uv] exclude-newer = "5 days"
        • mark_l_watson 6mo ago
          thank you!
• abhisek 6mo ago
  We just analysed the payload. Technical details here: https://safedep.io/malicious-litellm-1-82-8-analysis/ https://safedep.io/malicious-litellm-1-82-8-analysis/ We are looking at similar attack vectors (pth injection), signatures etc. in other PyPI packages that we know of.
• homanp 6mo ago
  How were they compromised? Phishing?
• jamiemallers 6mo ago
  [dead]
• hmokiguess 6mo ago
  what's up with everyone in the issue thread thanking it, is this an irony trend or is that a flex on account takeover from teampcp? this feels wild
• Shank 6mo ago
  I wonder at what point ecosystems just force a credential rotation. Trivy and now LiteLLM have probably cleaned out a sizable number of credentials, and now it's up to each person and/or team to rotate. TeamPCP is sitting on a treasure trove of credentials and based on this, they're probably carefully mapping out what they can exploit and building payloads for each one. 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.
  • post-it 6mo ago
    It'll only be disruptive to people who are improperly managing their credentials. Cattle not pets applies to credentials too.
• eoskx 6mo ago
  Also, not surprising that LiteLLM's SOC2 auditor was Delve. The story writes itself.
  • saganus 6mo ago
    Would a proper SOC2 audit have prevented this? I've been through SOC2 certifications in a few jobs and I'm not sure it makes you bullet proof, although maybe there's something I'm missing?
    • shados 6mo ago
      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 guarantees.
      • saganus 6mo ago
        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.
        • kyyol 6mo ago
          It wouldn't have. lol.
    • stevekemp 6mo ago
      Just so long as it was a proper SOC2 audit, and not a copy-pasted job: https://news.ycombinator.com/item?id=47481729 https://news.ycombinator.com/item?id=47481729
• saidnooneever 6mo ago
  just wanna state this can litterally happen to anyone within this messy package ecosystem. maintainer seems to be doing his best 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.
• syllogism 6mo ago
  Maintainers need to keep a wall between the package publishing and public repos. Currently what people are doing is configuring the public repo as a Trusted Publisher directly. This means you can trigger the package publication from the repo itself, and the public repo is a huge surface area. 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.
  • saidnooneever 6mo ago
    this kind of compromise is why a lot of orgs have internal mirrors of repos or package sources so they can stay behind few versions to avoid latest and compromise. seen it with internal pip repos, apt repos etc. some will even audit each package in there (kind crap job but it works fairly well as mitigation)
    • syllogism 6mo ago
      Just keeping a lockfile and updating it weekly works fine for that too yeah
  • anderskaseorg 6mo ago
    The point of trusted publishing is supposed to be that the public can verifiably audit the exact source from which the published artifacts were generated. Breaking that chain via a private repo is a step backwards. https://docs.npmjs.com/generating-provenance-statements https://docs.npmjs.com/generating-provenance-statements https://packaging.python.org/en/latest/specifications/index-hosted-attestations/ https://packaging.python.org/en/latest/specifications/index-...
    • password4321 6mo ago
      Pardon my limited understanding but my read of the suggestion was simply to perform the same exact operation that the public would do to verifiably audit the exact source when generating the official published artifacts, the point was just that there was no automation to do so directly from the public repo.
• cpburns2009 6mo ago
  Looks like litellm is no longer in quarantine on PyPI, and the compromized versions (1.82.7 and 1.82.8) have been removed [1]. [1]: https://pypi.org/project/litellm/#history https://pypi.org/project/litellm/#history
• deleted 6mo ago
  [deleted]
• deleted 6mo ago
  [deleted]
• deleted 6mo ago
  [deleted]
• claudiug 6mo ago
  LiteLLM's SOC2 auditor was Delve :))
• pugchat 6mo ago
  [dead]
• Aeroi 6mo ago
  whats up with the hundreds of bot replys on github to this?
  • zahlman 6mo ago
    It seems to be a deliberate attempt to interfere with people discussing mitigations etc.
• faxanalysis 6mo ago
  This is secure bug impacting PyPi v1.82.7, v1.82.8. The idea of bracketing r-w-x mod package permissions for group id credential where litellm was installed.
• macNchz 6mo ago
  Was curious—good number of projects out there with an un-pinned LiteLLM dependencies in their requirements.txt (628 matches): https://github.com/search?q=path%3A*%2Frequirements.txt%20%2F%5Elitellm%24%2F&type=code https://github.com/search?q=path%3A*%2Frequirements.txt%20%2... 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%22litellm%5C%22%22&type=code 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%22litellm%5C%22%22&type=code https://github.com/search?q=path%3A*%2Fsetup.py+%22%5C%22lit...
• noobermin 6mo ago
  I have to say, the long line of comments from obvious bots thanking the opener of the issue is a bit too on the nose.
  • zahlman 6mo ago
    It doesn't need to be subtle if the goal is just to drown out actual discussion.
• iamnotai666 6mo ago
  [dead]
• canberkh 6mo ago
  helpful
• lightedman 6mo ago
  Write it yourself, fuzz/test it yourself, and build it yourself, or be forever subject to this exact issue. This was taught in the 90s. Sad to see that lesson fading away.
• bustah 6mo ago
  [flagged]
• rvz 6mo ago
  What do we have here? Unaudited software completely compromised with a fake SOC 2 and ISO 27001 certification. 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://news.ycombinator.com/item?id=47502754
• westoque 6mo ago
  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.
  • bink 6mo ago
    Ironically, Trivy was the first known compromised package and its purpose is to scan container images to make sure they don't contain vulnerabilities. Kinda like the LLM in your scenario.
  • deleted 6mo ago
    [deleted]
  • jimmySixDOF 6mo ago
    Not sure that Trivy was doing that itself but zizmor is probably better than starting with an LLM : https://github.com/zizmorcore/zizmor https://github.com/zizmorcore/zizmor
• cowpig 6mo ago
  Tried running the compromised package inside Greywall, because theoretically it should mitigate everything but in practice it just forkbombs itself?
• sy0115 6mo ago
  [dead]
• aborsy 6mo ago
  What is the best way to sandbox LLMs and packages in general, while being able to work on data from outside sandbox (get data in and out easily)? 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.
  • cowpig 6mo ago
    Just wrote up a quick article on how greywall[0] prevents this attack: https://greyhaven.co/insights/how-greywall-prevents-every-stage-of-the-pypi-supply-chain-attack https://greyhaven.co/insights/how-greywall-prevents-every-st... [0] https://greywall.io/ https://greywall.io/
  • ashishb 6mo ago
    I wrote this[1] for myself last year. It only gives access to the current directory (and a few others - see README). So, it drastically reduces the attack surface of running third-party Python/Go/Rust/Haskell/JS code on your machine. 1 - https://github.com/ashishb/amazing-sandbox https://github.com/ashishb/amazing-sandbox
• smakosh 6mo ago
  Checkout LLM Gateway: https://llmgateway.io https://llmgateway.io Migration guide: https://llmgateway.io/migration/litellm https://llmgateway.io/migration/litellm
• ting0 6mo ago
  I've been waiting for something like this to happen. It's just too easy to pull off. I've been hard-pinning all of my versions of dependencies and using older versions in any new projects I set up for a little while, because they've generally at least been around long enough to vet. But even that has its own set of risks (for example, what if I accidently pin a vulnerable version). Either that, or I fork everything, including all the deps, run LLMs over the codebase to vet everything. 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.
  • MarsIronPI 6mo ago
    > 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. This is why software written in Rust scares me. Almost all Rust programs have such deep dependency trees that you really can't vet them all. The Rust and Node ecosystems are the worst for this, but Python isn't much better. IMO it's language-specific package managers that end up causing this problem because they make it too easy to bring in dependencies. In languages like C or C++ that traditionally have used system package managers the cost of adding a dependency is high enough that you really avoid dependencies unless they're truly necessary.
    • consp 6mo ago
      > Almost all Rust programs have such deep dependency trees that you really can't vet them all. JS/TS > Screems aloud! never do "npm import [package containing entire world as dependency]" Rust > Just import everything since rust fixes everything. When you design your package management and doctrine like de facto javascript your have failed like javascript.
  • AbanoubRodolf 6mo ago
• devnotes77 6mo ago
  [dead]
• somehnguy 6mo ago
  Perhaps I'm missing something obvious - but what's up with the comments on the reported issue? Hundreds of downvoted comments like "Worked like a charm, much appreciated.", "Thanks, that helped!", and "Great explanation, thanks for sharing."
  • kamikazechaser 6mo ago
    Compromised accounts. The malware targeted ~/.git-credentials.
• santiago-pl 6mo ago
  It looks like Trivy was compromised at least five days ago. https://www.wiz.io/blog/trivy-compromised-teampcp-supply-chain-attack https://www.wiz.io/blog/trivy-compromised-teampcp-supply-cha...
• qcautomation 6mo ago
  [dead]
• ajoy 6mo ago
  Reminded me of a similar story at openSSH, wonderfully documented in a "Veritasium" episode, which was just fascinating to watch/listen. https://www.youtube.com/watch?v=aoag03mSuXQ https://www.youtube.com/watch?v=aoag03mSuXQ
  • zahlman 6mo ago
    The xz compromise was not "at openSSH", and worked very differently.
• Ayc0 6mo ago
  Exactly what I needed, thanks.
• Nayjest 6mo ago
  Use secure and minimalistic lm-proxy instead: https://github.com/Nayjest/lm-proxy https://github.com/Nayjest/lm-proxy ``` pip install lm-proxy ``` Guys, sorry, as the author of a competing opensource product, I couldn’t resist
• dweinstein 6mo ago
  https://github.com/dweinstein/canary https://github.com/dweinstein/canary 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!
  • huevosabio 6mo ago
    This is clever, and also interesting in that it could help stop the steal as it happens (though of course not perfect).
    • dweinstein 6mo ago
      thanks for your feedback! that's a really good point and could be an interesting thing to play with as an extension. Since we potentially know which process is doing the "read" we could ask the user if it's ok to kill it. obviously the big issue is that we don't know how much has already been shipped off the system at that point but at least we have some alert to make some tough decisions.
  • someguyornotidk 6mo ago
    Thank you for sharing this! I always wanted to mess with building virtual filesystems but was unwilling to venture outside the standard library (i.e. libfuse) for reasons wonderfully illustrated in this thread and elsewhere. Somehow the idea of implementing a networked fs protocol and leaving system integration to the system never crossed my mind. I'm glad more people are taking this stance. Large centralized standard libraries and minimal audited dependencies is really the only way to achieve some semblance of security. There is simply no other viable approach. Edit: What's the license for this project?
    • dweinstein 6mo ago
• tonymet 6mo ago
  I recommend scanning all of your projects with osv-scanner in non-blocking mode # add any dependency file patterns osv-scanner -r . as your projects mature, add osv-scanner as a blocking step to fail your installs before the code gets installed / executed.
• datadrivenangel 6mo ago
  This among with some other issues makes me consider ejecting and building my own LLM shim. The different model providers are bespoke enough even within litellm that it sometimes seems like a lot of hassle for not much benefit. 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.
• ps06756 6mo ago
  Can someone help enlighten why would someone use LiteLLM over say AWS Bedrock ? Or build a lightweight router and directly connect to the model provider?
• mathis-l 6mo ago
  CrewAI (uses litellm) pinned it to 1.82.6 (last good version) 5 hours ago but the commit message does not say anything about a potential compromise. This seems weird. Is it a coincidence? Shouldn’t users be warned about a potential compromise? https://github.com/crewAIInc/crewAI/commit/8d1edd5d65c462c3daecbd890336a4e3a3d15874 https://github.com/crewAIInc/crewAI/commit/8d1edd5d65c462c3d...
  • mathis-l 6mo ago
    Dspy handling it openly https://github.com/stanfordnlp/dspy/issues/9500 https://github.com/stanfordnlp/dspy/issues/9500
• r2vcap 6mo ago
  Does the Python ecosystem have anything like pnpm’s minimumReleaseAge setting? Maybe I’m being overly paranoid, but it feels like every internet-facing ecosystem should have something like this.
  • collinmanderson 6mo ago
    uv has "exclude-newer" https://news.ycombinator.com/item?id=47513932 https://news.ycombinator.com/item?id=47513932
• aplomb1026 6mo ago
  [dead]
• skillflow_ai 6mo ago
  [dead]
• gaborbernat 6mo ago
  Recommend reading related blog post https://bernat.tech/posts/securing-python-supply-chain https://bernat.tech/posts/securing-python-supply-chain
• ryguz 6mo ago
  [dead]
• saharhash 6mo ago
  Easy tool to check if you/other repos were expoed https://litellm-compromised.com https://litellm-compromised.com
• getverdict 6mo ago
  Supply chain compromises in AI tooling are becoming structural, not exceptional. We've seen similar patterns in the last 6 months — Zapier's npm account (425 packages, Shai Hulud malware) and Dify's React2Shell incident both followed the same vector: a trusted package maintainer account as the entry point. The blast radius keeps growing as these tools get embedded deeper into production pipelines.
• rafaamaral 6mo ago
  [dead]
• openclaw01 6mo ago
  [dead]
• agentictrustkit 6mo ago
  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, 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.
  • Fibonar 6mo ago
    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.
• Innoraai 6mo ago
  [dead]
• aistackkit 6mo ago
  [dead]
• dhon_ 6mo ago
  I have older versions of litellm installed on my system - it appears to be a dependency for aider-chat (at least on NixOS)
• Adam_cipher 6mo ago
  [flagged]
• vlovich123 6mo ago
  I maintain that GitHub does a piss poor job of hardening CI so that one step getting compromised doesn’t compromise all possible secrets. There’s absolutely no need for the GitHub publishing workflow to run some third party scanner and the third party scanner doesn’t need access to your pypi publishing tokens. This stupidity is squarely on GitHub CI. Trivy is also bad here but the blast radius should have been more limited.
• postalcoder 6mo ago
  FYI, npm/bun/pnpm/uv now all support setting a minimum release age for packages. 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
  • montag 6mo ago
    Well this was prescient... https://news.ycombinator.com/item?id=47582220 https://news.ycombinator.com/item?id=47582220
  • jerrygoyal 6mo ago
    I don't think syntax is correct for pnpm
    • postalcoder 6mo ago
      Works for me? $ pnpm add -D typescript@6.0.2 ERR_PNPM_NO_MATURE_MATCHING_VERSION No matching version found for typescript@6.0.2 published by Wed Mar 18 2026.. You could also set the config this way: pnpm config set minimumReleaseAge 10080 --global You may be thinking about the project-specific config, which uses YAML. https://pnpm.io/cli/config https://pnpm.io/cli/config
  • exyi 6mo ago
    Do you know if there is override this specifically when I want to install a security patch? UV just claims that package doesn't exist if I ask for new version
    • postalcoder 6mo ago
      Yes there is. You can use those configs as flags in the CLI to override the global config. eg: npm install <package> --min-release-age 0 pnpm add <package> --minimum-release-age 0 uv add <package> --exclude-newer "0 days" bun add <package> --minimum-release-age 0
• avian 6mo ago
  What's with the hundreds of comments like "This was the answer I was looking for." in that GitHub thread? 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 https://news.ycombinator.com/item?id=47508315
  • ramimac 6mo ago
    It's a spam flood by the attacker to complicate information sharing[1]. They did the same thing in the Trivy discussion, with many of the same accounts.[2] [1] https://ramimac.me/teampcp/#spam-flood-litellm https://ramimac.me/teampcp/#spam-flood-litellm [2] https://ramimac.me/teampcp/#discussion-flooded https://ramimac.me/teampcp/#discussion-flooded
• deleted 6mo ago
  [deleted]
• fede_dp 6mo ago
  [dead]
• latable 6mo ago
  So now we feel the need to add malware protection into the CI, like we put comodo on windows 7 and pray while surfing shady torrent websites ? It is pretty ironic that an extra tool used to protect against threats gets compromised and creates an even bigger threat. Some here talks about better isolation during development, CI, but the surface area is huge, and probably impractical. Even if the CI is well isolated, the produced package is compromised. 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.
• zx8080 6mo ago
  > the compromise originated from the Trivy dependency used in our CI/CD security scanning workflow. What is the source of compromise? Does anyone have a list of other compromised projects?
• clampd 6mo ago
  [dead]
• paxrel_ai 6mo ago
  [dead]
• Bullhorn9268 6mo ago
  I am from futuresearch and went through this with Callum (the OG). We did a small analysis here: https://futuresearch.ai/blog/litellm-hack-were-you-one-of-the-47000/ https://futuresearch.ai/blog/litellm-hack-were-you-one-of-th... of the packages and also build this mini tool to analyze the likelihood of you getting pwned through this: https://futuresearch.ai/tools/litellm-checker/ https://futuresearch.ai/tools/litellm-checker/
• riteshkew1001 6mo ago
  [flagged]
• builderhq_io 6mo ago
  [dead]
• pugchat 6mo ago
  [dead]
• n1tro_lab 6mo ago
  [flagged]
• calebjang 6mo ago
  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.
  • Fibonar 6mo ago
    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.
• anilguleroglu 6mo ago
  [dead]
• sta1n 6mo ago
  [dead]