Compromised LiteLLM 1.107.0 on PyPI Installs a Credential Stealer and Backdoor
文章洞見
原文內容目前無法安全取得，因此未產生文章摘要。
討論洞見
尚無可用的討論摘要。
代表性留言
The compromise appears somewhere in the build and deploy system.> No public commit in BerriAI/litellm contains data = "cook" or a cook/ folder.> SafeDep assesses, with moderate to high confidence, that BerriAI’s private release pipeline built these wheels from an attacker-modified git source.
Aurornis · HN #50185185（在新分頁開啟）
Every harness thinking right now… "if we want do something like this we won't even have to compromise anything."
crossroadsguy · HN #50184835（在新分頁開啟）
All the sandbox-exec and all the Lulu rules are not going to protect against something like this.At one point permission pop-up fatigue sets in we start giving any permission as if it's normal. We also become desensitised to isntalling tools: brew, npm, it becomes second nature."Oh, those 367 tools installed by package X? Yeah yeah, must be normal, that's how all these work now"."Brew shows 59 packages outdated?". "Must upgrade". "Yeah, done. Perfect".And the advent of agents and harnesses. It's not a matter of whether, it's when! OSes need to do something about it. Help users have complete separate "program space" at ease with better, easier, and lighter VMs if nothing else. I know, I know - Unix and Linux solved all this even before Alexander III of Macedon started wearing his nappies. Of course.
crossroadsguy · HN #50184801（在新分頁開啟）
> All the sandbox-exec and all the Lulu rules are not going to protect against something like this.No, you can block this with sandboxing tools. For my LLM agents, I use a tool called Nono, whose macOS implementation is built on the same foundation as sandbox-exec. One of the key features it supports (and it's not the only tool that does this) is proxying and the injection of credentials via the proxy. For example, when I run Codex at work, Codex does not have access to my Azure AI Foundry API credentials. It sends out requests via dummy credentials, and the proxy injects the real ones outside the sandbox.The other thing that proxy does is let you restrict network access in various ways. So you can run something like LiteLLM so that it doesn't have access to the internet at large; it can only talk to Azure AI Foundry or AWS Bedrock or whoever your inference provider is. You sandbox LiteLLM separately from your agents, and you give it access to much less. The software firewall stuff isn't perfect but it is a significant defense against things like this.There are also lots of other restrictions that are easy to do which mitigate this. Nono blocks access to the root of $HOME, then selectively allows access to paths within it, and also explicitly blocks access to common paths to secrets. So it's pretty easy to make sure that access to important things are blocked: SSH credentials, GnuPG socket (and local Unix sockets in general), local OS keyrings, etc.The way I use tools like this is exclusively by writing policy, testing it, and revising where the policy is inadequate. I never get approval fatigue because I don't do approvals.You're right that attacks like this are hard to defend against, and that we're used to tool sprawl, and also that LLMs can do things like install tools we don't expect them to themselves! But there are ways to anticipate and mitigate attacks like this. Sandboxing tools (including contained and VMs) that support credential injection are genuinely useful for this.
isityettime · HN #50187187（在新分頁開啟）
No no it's really important that I have 5-factor authentication on every website and it requires me to go through the whole login process again every time I break eye contact.
fdsjgfklsfd · HN #50186158（在新分頁開啟）
Just going to remind you all that https://canarytokens.org/ exists.
linsomniac · HN #50184883（在新分頁開啟）
Canary token is great to tell you've been hacked.There are ways to try to prevent this from happening in a first place. I wrote kow (keys-on-the-wire) to fix this. Apps only see placeholder tokens. The proxy injects real key from the vault into outbound requests for allowed hosts.Author here. Apache-2.0. [1] https://keysonthewire.com [2] https://github.com/inflightsec/keys-on-the-wire
radku
自稱作者 · HN #50191776（在新分頁開啟）This is awesome, why did I just learn about this! Gonna add these all over my homelab
myzek · HN #50193002（在新分頁開啟）
This is the second significant exploit against LiteLLM in what, a year or two ? Just last night I came across notes and a script from an older claude session to help audit all project dependencies and verify nothing used litellm.Okay, checked, it was March of this year: https://futuresearch.ai/blog/litellm-pypi-supply-chain-attac.... What even is time anymore in the llm age?
rsanheim · HN #50187074（在新分頁開啟）
And buried under the lede is that one of the compromised people was one of the organization owners. So it seems like the culture of insecurity comes from the top, which is unfortunate especially bc they keep acting like "this could've happened to anyone guys"
halJordan · HN #50189212（在新分頁開啟）
there's another one this summer that didn't get as much attention (or any at all) which allowed exfiltrating master provider keys with any authenticated user/virtual keyhttps://nvd.nist.gov/vuln/detail/cve-2026-84377
sebdufbeau · HN #50189701（在新分頁開啟）
How could this happen to a project with 55k commits in three years?
pkulak · HN #50184311（在新分頁開啟）
"Attackers compromised 3 unique developer github credentials" is a little scary; this seems systemic - if three developers had their keys stolen, it implies the real problem is elsewhere.They revoked all but one developers, which is probably the right approach, but I'd pin LiteLLM to "something before this version" and keep it there until further notice!
threecheese · HN #50186105（在新分頁開啟）
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!
detente18 · HN #50191180（在新分頁開啟）
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
detente18 · HN #50189921（在新分頁開啟）
It's not a novel attack: it's novel negligence.The best improvement would be to blame yourselves instead of Claude.
fny · HN #50190847（在新分頁開啟）
> specific situations in which Claude Code will embed a user's GitHub CLI OAuth token into a response body, and in situations where response bodies are logged, these tokens may appear in LiteLLM logs.That's pretty hand wavy. What did y'all have CC doing that it had your GitHub CLI OAuth token in its context at all?Stuff like this is why my coding agent is a coding agent not shell agent that basically own the machine. Mine has no tool for shell use narrow tools specific things like ripgrep, finding files, and deleting files that limit the paths to explicit workspace directory.I take care of commits, push/pull, building wheels, and publishing wheels myself. It really doesn't take the much time and the coding agent frees up a lot of my time.
joshheitzman · HN #50190244（在新分頁開啟）
I am not following how someone snuck the files into the release.All I read was that it creates a directory from the build file but seemingly no description how new files or added dependencies slipped by. Was `cook.pth` a dependency that got automatically downloaded from PyPI on install and then the build system put it into dependencies?--Leaving this for others:> BerriAI’s private release pipeline built these wheels from an attacker-modified git source. The attacker could have used a compromised maintainer or bot credential, a private branch or mirror, or the reference the pipeline builds from. A stolen PyPI token used from the attacker’s own machines fits the evidence less well.Makes sense. It was that a maintainer or the private pipeline was attacked and the malicious dependency was injected there by squatting on the maintainer's local copy rather than the dependency being hijacked for everyone. Very clever.
madamelic · HN #50183673（在新分頁開啟）
> Was `cook.pth` a dependency that got automatically downloaded from PyPI on install and then the build system put it into dependencies?This isn't the name of an entire package, but just a single file included in the package. .pth files are part of Python's import system. At startup, the standard library `site` runs automatically, and configures the (initial) places that Python will look for code to satisfy `import` statements. By design (because some people occasionally find it very useful), arbitrary Python code can be run from these[0]. The system searches the entire site-packages folder for these files.The compromised build packages up a .pth file in such a way that installers will treat it as a "data file"; but because Python programmers are accustomed to looking for data files at paths relative to the current source file, installers put .pth files in places that will easily be picked up by the `site` scan.So the point is simply that, once LiteLLM is installed, malware injected directly into the final package (not a dependency) runs at startup in the compromised environment even if you don't use the LiteLLM code explicitly.Nothing "creates a directory from the build file". The attacker-modified source includes the entire "cook" payload directory and also modifies the build file so that the build system would include its contents. No dependencies are involved (unless you're thinking of LiteLLM as being a dependency for something else).The Python ecosystem has been working on mitigations for this. Starting in 3.15 the .pth file system is being reworked[1], but a deprecation period is necessary. Also, the PyPI repository has an opt-in system called "Trusted Publishing"[2] which is supposed to allow verifying that a wheel was built from the appropriate source directly using GitHub's CI mechanism. (Opt-in because of the long tail of developers who don't use this or any other CI system and shouldn't be expected to learn them for a small hobby project.) However, since the attacker did use the CI system from a separate GitHub repository, and compromised multiple maintainer accounts, I imagine it was possible to defeat that protection as well.If you don't need the `site` mechanism for your project (of course, this needs to be tested per project), it can be disabled by passing the -S flag to Python[3]. This has always been available, but awareness seems to be low.Historically, Python packaging has overall had a pretty lax security posture, and new attempts to improve that are often delayed by the consensus process and by backward compatibility concerns.[0]: It's possible to put arbitrary code directly in the file, but rather unwieldy. Interestingly, this payload is neatly organized: the .pth file simply runs an import statement and appears to keep hundreds of lines of code in two actual Python files: one that works directly, and one that sets up a sub-hook called `sitecustomize` (another explicit provision of the `site` configuration system).[1]: https://docs.python.org/3/whatsnew/3.15.html#whatsnew315-sta...[2]: https://docs.pypi.org/trusted-publishers/[3]: https://docs.python.org/3/using/cmdline.html#cmdoption-S
zahlman · HN #50201342（在新分頁開啟）
If that's right then attestations wouldn't have saved anyone here either. They prove which workflow published the wheel, not what source that workflow checked out. A private pipeline building from the same-looking repo still gives you a perfectly valid attestation.What would catch it is someone rebuilding from the public tag and comparing the result, which almost nobody does for the python wheels. I have been treating attestations as the answer for my own project's releases, so this is a good reminder of where they stop.
aakashpawar · HN #50183906（在新分頁開啟）
Official Incident Post: https://docs.litellm.ai/blog/security-incident-oct-21-2026
yujonglee · HN #50185595（在新分頁開啟）
IMHO defaults for uv, npm, etc should all have a cooldown for 24 - 48 hours by default, you should have to go out of your way to install something newer.
stbenjam · HN #50182491（在新分頁開啟）
We have 7d cooldown on packages on an internal pypi proxy but that blocks security updates also, which we now have to manually exclude from the cooldown.I’m unsure how to automate this properly, maybe an LLM is the best starting point.
robinhoodexe · HN #50182706（在新分頁開啟）
I use safechain for this, because there is always gonna be another package manager configured wrong. https://github.com/AikidoSec/safe-chain
sunbum · HN #50185583（在新分頁開啟）
Google's ADK (agent development kit) uses LiteLLM extensively: https://adk.dev/agents/models/litellm/Their docs list LiteLLM's vulnerability from March... https://i.imgur.com/TPVrVyW.png
valgaze · HN #50193260（在新分頁開啟）
Seriously again for litellm? I really with that things like Google ADK didn't add this to my deps.
rcleveng · HN #50182168（在新分頁開啟）
all popular, free, ungated software will be poisoned; like kesler syndrome but for the world of open source software.
cyanydeez · HN #50183069（在新分頁開啟）
its litellm again. I wonder about maintainer trustworthiness
tech_solver · HN #50182836（在新分頁開啟）
litellm in the news again
baddash · HN #50183017（在新分頁開啟）
What's interesting here is that this will only affect those who did not migrate off LiteLLM after it was attacked the first time.I'm not saying everyong should migrate after there's a vuln, but I'm definitely saying that. Unless it's something huge and foundational like a programming language (PHP gets a second chance), just migrate within the next couple of weeks.I didn't even have it installed the first time, so the ideal programmers, (read, your competition), actually suffered 0 vulns from this dep, if you suffered 1, that's already pretty bad, being burnt twice should be a wake up call. If you get hit 3 times by the same dependency, it's a lost case.
TZubiri · HN #50183106（在新分頁開啟）
Last time they had this, I just vibe coded a version of lite llm and it actually works better
saasisdead · HN #50184598（在新分頁開啟）
Yeah, thinking that after the last supply chain attack, people would be smarter than ship things with LiteLLM.
starfallg · HN #50184630（在新分頁開啟）
Isn't that at least the second time that LiteLLM got compromised?
nairboon · HN #50185833（在新分頁開啟）
Déjà vu for both of us, huh?
mihaaly · HN #50186562（在新分頁開啟）
Again this is the second time this year
avereveard · HN #50184298（在新分頁開啟）
https://github.com/BerriAI/litellm/issues/47826#issuecomment...> OSS Users > For the time being, please pin your version to 1.106.2 or any explicit version published prior to now.> Enterprise Customers > There currently exists a private LiteLLM registry for enterprise customers, in which we are distributing an embargoed release that remediates a vulnerability whose disclosure date is scheduled for October 27. Our private registry is not affected. If you are an enterprise customer pulling from our private registry you are not affected.
hmokiguess · HN #50183423（在新分頁開啟）
So they sell advance access to information that will allow me to hack other people's LiteLLM instances?Seems a little unethical
wongarsu · HN #50184473（在新分頁開啟）
Earlier it was eMudhra and now BerriAI's internal failure? AI usage is both a boon and a bane. Shortsightedness due to continuous AI usage?
tesnorindian · HN #50194183（在新分頁開啟）
I wish all the best to LiteLLM team with handling it again. I can imagine how challenging are situations like this one.However, if anyone is looking for 20x faster and less "targeted" LiteLLM alternative - I'm work on one in Go. That's why GoModel it's called. https://github.com/ENTERPILOT/GoModel/
santiago-pl · HN #50182272（在新分頁開啟）
Sounds like a reasonable choice of a language.I myself have written a small llm proxy in Go, doing nothing but injecting the real API key to outgoing requests while itself validating virtual keys it generates, and it works great.
ghrl · HN #50182479（在新分頁開啟）
If you don't use any LLM router, it's infinity times faster, and infitesimally as targetted.
TZubiri · HN #50183186（在新分頁開啟）
In this thread: people who would blame the inventors of the computer for the impact of computer viruses.
Sherveen · HN #50188914（在新分頁開啟）
Crazy day - but seems like this was contained fairly quickly: https://docs.litellm.ai/blog/security-incident-oct-21-2026
abhikap · HN #50189190（在新分頁開啟）
What worries me is that this seems to be the second time this happened and there's not even a notification on litellm.ai about it.
wolvoleo · HN #50192084（在新分頁開啟）
https://github.com/gumieri/nenyaIf someone just need an AI Proxy with no deps.
garou · HN #50190729（在新分頁開啟）
That just shifts the risk
mc8098 · HN #50192308（在新分頁開啟）
Why on earth do these people make it impossible to select the title of their article?
callamdelaney · HN #50182582（在新分頁開啟）
it's just the poor styling of the selection highlight colour.
nkjoep · HN #50182733（在新分頁開啟）
https://news.ycombinator.com/item?id=50189802
yujonglee · HN #50189878（在新分頁開啟）
This is the 2nd time. I'm glad I moved away from this platform.
1-6 · HN #50183552（在新分頁開啟）
Any package hosts that scan and include cooldowns by default that operate on a consumption model? The ones I have seen all charge a lot.
infecto · HN #50182846（在新分頁開啟）
Not sure about a service, but PMG enforces dependency cooldown and sandbox on package install. https://github.com/safedep/pmg
abhisek
投稿者 · HN #50183154（在新分頁開啟）Bytesafe (https://bytesafe.dev). Pure Dependency Firewall, not a package host, with usage based pricing.
wallrat · HN #50186992（在新分頁開啟）
I figured LLMs nowadays would be good enough to catch issues like this. Is it because it’s too costly to do it?
syntaxing · HN #50183062（在新分頁開啟）
Yes if you use LLM to analyse everything. Not really if you analyse diffs, with heuristics to select candidates for LLM/agent based analysis. But at the cost of missing out novel attacks.
abhisek
投稿者 · HN #50183128（在新分頁開啟）Oof.LiteLLM has one of the nicest programmer UX to use but this is not good at all.
stuaxo · HN #50189306（在新分頁開啟）
Seems like pip doesn't have a way to exclude packages although it was requested at least once: https://github.com/pypa/pip/issues/10797Just checked if litellm crept in with any packages I installed recently. Fortunately it didn't, but I'm working on an OSS AI agent harness so its certainly a concern and I'd like just flatout block litellm so I don't have to worry about picking it up as transitive dependency. Guess I'll have to vibe a script and remember to run it. Sigh.
joshheitzman · HN #50190123（在新分頁開啟）
If you can use uv, try the --exclude flag, e.g.: uv pip install -r requirements.txt --exclude excludes.txt excludes.txt is basically like an inverse requirements.txt. Your requirements.txt could have this... pandas scikit-learn matplotlib ...while excludes.txt has this... numpy ... and uv would resolve the dependencies in requirements.txt, excluding numpy from the dependency graph entirely and ignoring any dependencies that would have been introduced by numpy itself.EDIT: You can also configure this for uv directly in a pyproject.toml file: [tool.uv] exclude-dependencies = ["numpy"]
wilkystyle · HN #50190387（在新分頁開啟）
1792590200 | LiteLLM Hijacked: Malicious 1.107.0 Wheels Steal Credentials | https://research.jfrog.com/post/litellm-hijacked-again/ | https://news.ycombinator.com/item?id=50180838 | 0 comments1792590232 | Litellm 1.107.0 Compromised | https://github.com/BerriAI/litellm/issues/47826 | https://news.ycombinator.com/item?id=50180845 | 0 comments
1vuio0pswjnm7 · HN #50183831（在新分頁開啟）
Obligatory "package managers are evil:"https://www.gingerbill.org/article/2025/09/08/package-manage...
jkercher · HN #50189235（在新分頁開啟）
A bad day for opensource, but I guess this is how we get stronger patch by patch.
merelydev · HN #50184816（在新分頁開啟）
I setup 8 day age gates on everything back in May. This is inobtrusive and pretty safe.
hendersoon · HN #50189867（在新分頁開啟）
> There currently exists a private LiteLLM registry for enterprise customers, in which we are distributing an embargoed release that remediates a vulnerability whose disclosure date is scheduled for October 27.https://github.com/BerriAI/litellm/issues/47826oh boy. Announcing that there's a private enterprise repo you should be paying for if you don't want a credential stealer in your build is quite the optic, and then announcing there's an undisclosed second vulnerability that's being distributed, just not to the poors...
petesergeant · HN #50182543（在新分頁開啟）
That's not what's being said, at all. They are simply telling their enterprise customers that there is a different build pathway for the enterprise builds and that pathway wasn't impacted by this issue.Also if you don't like organizations fixing vulns without releasing the open source first, you're going to be upset when you learn how every major vuln and associated patches are distributed long before the fixes hit the repos. A timely example of this is PHP, literally today.
sullivanmatt · HN #50182849（在新分頁開啟）
Note: I work at LiteLLMThere exists a critical vulnerability which affects only Enterprise LiteLLM deployments, and does not affect OSS deployments.We have provided our customers with patched releases distributed via a private registry and are allowing them some time to update their deployments before we release the fix in our public registry and disclose the vulnerability details. Releasing the fix publicly in an open source product would be a de-facto vulnerability disclosure.
chias
自稱內部人士 · HN #50186080（在新分頁開啟）So in just 1 week:1. Google Cloud Outage [0]2. eMudhra CA private key Leak [1]3. PingCap TiDB 10.6 TB data Leak [2]4. PHP2Shell uncovers critical CVEs (with AI) [3]...and now we have Round 2 of a LiteLLM compromise after the first one in [4].[0] https://news.ycombinator.com/item?id=50163961[1] https://news.ycombinator.com/item?id=50166579[2] https://news.ycombinator.com/item?id=50173716[3] https://news.ycombinator.com/item?id=50180836[4] https://news.ycombinator.com/item?id=47501426
rvz · HN #50182126（在新分頁開啟）
don't forget today's NodeJS security update addressing its own RCE bugs!
gcr · HN #50182869（在新分頁開啟）
is the google outage related to a security incident?
rolls-reus · HN #50184265（在新分頁開啟）
Second f**king time. Just torching their reputation at this point
SomaticPirate · HN #50183610（在新分頁開啟）
Well it seems like it’s over for litellm. You’d have to be negligent to be using them at this point. If you’re managing this at your company good luck explaining why you should continue to use litellm after this
abletonlive · HN #50185796（在新分頁開啟）
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...
detente18 · HN #50189956（在新分頁開啟）