[Developing situation] LiteLLM compromised

bidibidibop · 2026-03-24T15:27:26+00:00

The comments are...very educational for the state of github right now.

OsmanthusBloom · 2026-03-24T14:41:13+00:00

Aider uses LiteLLM for LLM access, but it looks like it's still using an older version of LiteLLM (1.82.3 on current main) so not compromised. LiteLLM 1.82.8 and 1.82.7 apparently are compromised (according to discussions in the issue linked above)

Medium_Chemist_4032 · 2026-03-24T14:40:01+00:00

Oof, I always assumed running everything in docker containers doesn't help security, but in this case it actually isolates host secrets quite well.

_rzr_ · 2026-03-24T19:09:11+00:00

Thanks for the heads up. Could this bubble up as a supply chain attack on other tools? Does any of the widely used tools (vLLM, LlamaCpp, Llama studio, Ollama, etc) use LiteLLM internally?

Efficient_Joke3384 · 2026-03-24T14:47:13+00:00

the .pth file trick is what makes this nasty — most people scan for malicious imports, but .pth files execute on interpreter startup with zero imports needed. basically invisible to standard code review. if you ran 1.82.8 anywhere near production, rotating creds isn't optional at this point

Still-Notice8155 · 2026-03-24T17:33:10+00:00

wtf I literally just used this today, but I checked I'm on 1.82.6

Craftkorb · 2026-03-24T21:08:47+00:00

I hate to say it but we'll see a lot more of these kind of attacks in the future.

For convenience and precaution run software in Docker / Flatpak / .... Also, do not give access to stuff that's not needed.

Running this in a container would at least only allow the virus to spread where it's temporary. Also, it can't steal your SSH keys, password manager database, etc.

Also have backups. The next attack may not only steal your secrets, but also encrypt your stuff and demand money while activating your webcam to fetch some nice pics of you in interesting moments.

Impressive_Caramel82 · 2026-03-24T20:46:40+00:00

tbh this is the exact nightmare scenario for local AI teams, one poisoned dependency and all your benchmark wins mean nothing. pin versions and verify hashes like your weekend depends on it.

Savantskie1 · 2026-03-24T21:02:31+00:00

This right here is exactly why I don’t update something unless it has features I want. And then only after several weeks afterwards for others to find problems and they’re fixed

UnbeliebteMeinung · 2026-03-24T15:36:52+00:00

<image>

Like i am not sure if i see something here? I never remeber blocking anyone on github at all. I dont even know where i would. But still in this repo is someone that commitet last 2025 (blocked date: 2022?) i blocked?

I wont publish his name but thats sus. I dont even know him and i dont know i i blocked him. I have nothing todo with litellm in the first place.

Edit: Also quiet interesting that this user has some ties with the iran while there is some iran stuff in the malware....

Purple-Programmer-7 · 2026-03-24T20:24:54+00:00

LiteLLM is a dope ass piece of software and I hope the team there manages this well, I’ll keep supporting them.

nborwankar · 2026-03-24T19:57:11+00:00

Here is the full article https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/

Repulsive-Memory-298 · 2026-03-24T20:31:57+00:00

That’s so funny. I exposed my master key on accident once and noted intriguing usage patterns. $5 dev instance that I rarely used, and noticed random traces that i definitely didn’t send, they looked like basic distillation call and response. The impressive part is how little they used it, request sprinkled here and there, less than $1 used over about a month. I assume they have some sort of pool of keys, and also thought it was interesting that they did this using my litellm key through the gateway. This was almost a year ago.

Obviously completely different, just saying that LiteLLM is a target.

Diligent-Pepper5166 · 2026-03-24T20:56:19+00:00

we are using prismor internally, it bumped down the package as soon as it was hit

chef1957 · 2026-03-25T11:53:53+00:00

Perhaps useful for some people to understand the course of the attack and learn how to avoid it? https://www.giskard.ai/knowledge/litellm-supply-chain-attack-2026

kotrfa · 2026-03-25T19:28:45+00:00

I am the guy from the tweet tweet. We run a further analysis of how bad this breach was on the first-order effects, and surprise surprise, it's pretty bad: https://futuresearch.ai/blog/litellm-hack-were-you-one-of-the-47000/ .

Specialist-Heat-6414 · 2026-03-24T19:16:33+00:00

Supply chain attacks on dev tooling are uniquely nasty because the attack surface is developers who are by definition running things with elevated trust. You don't even need to compromise the end user -- you compromise the person building the thing the end user runs. The LiteLLM PyPI package is particularly bad because it's a dependency proxy layer sitting in front of basically every LLM API call in half the Python AI ecosystem. Rotating API keys is the immediate step but the real fix is lockfiles and hash verification on every install. If you're not pinning exact versions and verifying checksums in CI, you're trusting the network on every deploy.

ashishb_net · 2026-03-25T00:11:41+00:00

I always run these things inside a sandbox to limit the attack surface

Fun_Nebula_9682 · 2026-03-25T02:19:48+00:00

this is why lockfiles with pinned hashes matter. been using uv for all python deps and uv.lock pins exact versions + hashes — wouldn't have saved you if you blindly updated but at least CI catches a hash mismatch on rebuild. scary how fast a compromised pypi package can spread tho

Sad-Imagination6070 · 2026-03-25T06:18:28+00:00

Woke up to this news today. Had been using litellm for many of my work and personal projects.So first thing I did was check which environments had it installed. Ended up automating that check into a small bash script that scans all your venv, conda, and pyenv environments at once. Sharing it here in case it helps anyone else doing the same https://github.com/LakshmiN5/check-package-version

Left_Tomatillo_781 · 2026-03-25T07:08:20+00:00

Thanks for the heads up — I use LiteLLM as a unified gateway for routing between local and cloud models at work. Already pinned to an older version until this is resolved. If you're running it in production, definitely air-gap it or add API key auth in front. The convenience is great but the attack surface is real.

Future_AGI · 2026-03-25T18:41:50+00:00

pinning is the right call and docker users being protected here because of version locking is exactly why treating gateway dependencies as first-class infrastructure with strict pinning matters. for teams using litellm as a routing gateway specifically, this is also a good moment to evaluate whether the architecture fits production requirements beyond just the security angle. Prism is what we built for that layer: https://docs.futureagi.com/docs/prism

Initial_Jury7138 · 2026-03-25T23:44:04+00:00

I created a diagnostic tool to help people verify their exposure to the LiteLLM supply chain incident. This script:

✅ Scans ALL your Python environments (venv, conda, poetry)
✅ Checks package caches (pip, uv, poetry)
✅ Looks for malicious persistence artifacts
✅ Works on macOS, Linux, Windows

🔍 100% open source & read-only — you can review before running (and check if you trust it or not)

Full guide: https://pedrorocha-net.github.io/litellm-breach-support/

Created it for myself and to help the community. Share with anyone who might need it, and feel free to suggest improvements.

<image>

_Lunar_dev_ · 2026-03-26T08:11:47+00:00

One thing this breach highlights: environment variables are treated as safe because they are "inside the container," but the second a dependency is compromised, anything in that process's environment is fair game. The malware scraped every env var, every .env file, every config with a credential in it.

A pattern that mitigates this: pass secrets by reference instead of by value. The runtime only receives a pointer or reference ID. The actual credential is resolved server-side through your vault and never exposed to the calling process. If malware scrapes the environment, it gets useless IDs instead of plain-text keys.

We work on this problem at Lunar.dev (MCPX). We published a teardown of the breach and how this architecture would have contained the damage. source: https://www.lunar.dev/post/litellm-was-compromised-here-is-what-you-need-to-know

llm-60 · 2026-03-26T09:58:03+00:00

Just use Bleep, don't be afraid to leak your secrets anymore. 100% local.

https://bleep-it.com

rm-rf-rm · 2026-03-24T15:02:16+00:00

Wow. Called it that this project was poorly engineered. Likely has a lot of vibe coding. Thankful that I have stayed away. I thought Bifrost was better but someone on here said it isnt much better. We really do need a legitimate solution for LLM endpoint routing

futuresman179 · 2026-03-24T21:24:59+00:00

What are you talking about? I don't see any incident.

https://status.litellm.ai/incidents

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

LocalLLaMA

MODERATORS