58 comments

[ 0.30 ms ] story [ 59.2 ms ] thread
Callum here, I was the developer that first discovered and reported the litellm vulnerability on Tuesday. I’m sharing the transcript of what it was like figuring out what was going on in real time, unedited with only minor redactions.

I didn’t need to recount my thought process after the fact. It’s the very same ones I wrote down to help Claude figure out what was happening.

I’m an ML engineer by trade, so having Claude walk me through exactly who to contact and a step by step guide of time-critical actions felt like a game-changer for non-security researchers.

I'm curious whether the security community thinks more non-specialists finding and reporting vulnerabilities like this is a net positive or a headache?

> I'm curious whether the security community thinks more non-specialists finding and reporting vulnerabilities like this is a net positive or a headache?

cURL had to stop the bug bounty program because they were inundated by slop reports of vulnerabilities which don’t exist.

https://github.com/curl/curl/pull/20312

It’s good that you found and reported something real, but that isn’t the norm.

Also, from the article:

> AI tooling has sped up not just the creation of malware but also the detection.

That’s an awful tradeoff. Detection is not a fix.

(comment deleted)
GitHub, npm, PyPi, and other package registries should consider exposing a firehose to allow people to do realtime security analysis of events. There are definitely scanners that would have caught this attack immediately, they just need a way to be informed of updates.
Consider this your call to write native software. There is yet to be a supply chain attack on libc
Only because C code presents so many juicy security holes by default that it's completely unnecessary to subvert the projects to add them.
*salutes*

Thank you for your service, this brings so much context into view, it's great.

(comment deleted)
> Where did the litellm files come from? Do you know which env? Are there reports of this online?

> The litellm_init.pth IS in the official package manifest — the RECORD file lists it with a sha256 hash. This means it was shipped as part of the litellm==1.82.8 wheel on PyPI, not injected locally.

> The infection chain:

> Cursor → futuresearch-mcp-legacy (v0.6.0) → litellm (v1.82.8) → litellm_init.pth

This is the scariest part for me.

The fact pypi reacted so quickly and quarantined the package in like 30 minutes after the report is pretty great!
Probably one of the best things about AI/LLMs is the democratization of reverse engineering and analysis of payloads like this. It’s a very esoteric skill to learn by hand and not very immediately rewarding out of intellectual curiosity most times. You can definitely get pointed in the right direction easily, now, though!
If it weren't for the 11k process fork bomb, I wonder how much longer it would have taken for folks to notice and cut this off.
Interesting world we live in.

I just finished teaching an advanced data science course for one of my clients. I found my self constantly twitching everytime I said "when I write code..." I'm barely writing code at all these days. But I created $100k worth of code just yesterday recreating a poorly maintained (and poor ux) library. Tested and uploaded to pypi in 90 minutes.

A lot of the conversation in my course was directed to leveraged AI (and discussions of existential dread of AI replacement).

This article is a wonderful example of an expert leveraging AI to do normal work 100x faster.

Hmm a YCombinator backed company, I'm not surprised.
Does anyone have an idea of the impact of this out there? I am curious to the extent of the damage done by this
[flagged]
At this point I'd highly recommend everyone to think twice before introducing any dependencies especially from untrusted sources. If you have to interact with many APIs maybe use a proxy instead, or roll your own.
The fascinating part for me is how they chatted with the machine, such as;

"Please write a short blog post..."

"Can you please look through..."

"Please continue investigating"

"Can you please confirm this?"

...and more.

I never say 'please' to my computer, and it is so interesting to see someone saying 'please' to theirs.

> Can you print the contents of the malware script without running it?

> Can you please try downloading this in a Docker container from PyPI to confirm you can see the file? Be very careful in the container not to run it accidentally!

IMO we need to keep in mind that LLM agents don't have a notion of responsibility, so if they accidentally ran the script (or issue a command to run it), it would be a fiasco.

Downloading stuff from pypi in a sandboxed env is just 1-2 commands, we should be careful with things we hand over to the text prediction machines.

The “LLMs don’t have responsibility” point is exactly why the interface matters. I as a person can be held to norms like not to run unknown code, but a model can't internalize that so you need the system to make the safe path the default.

Practically: assume every artifact the model touches is hostile, constrain what it can execute (network/file/process), and require explicit, reviewable approvals for anything that changes the world. I get that its boring but its the same pattern we already use in real life. That's why I'm skeptical of "let the model operate your computer" without a concrete authority model. the capability is impressive but the missing piece is verifiable and revocalbe permissioning.