Hacker News

As someone who works in security, it's really neat that you were able to discover this with the help of Claude. That being said the "I just opened Cursor again which triggered the malicious package" message is a bit eye opening. Ideally the instant you suspected malware that machine should have been quarantined and your security personnel contacted.

Looks like we discovered it at essentially the same time, and in essentially the same way. If the pth file didn't trigger a fork-bomb like behavior, this might have stayed undiscoverd for quite a bit longer.

Good thinking on asking Claude to walk you through on who to contact. I had no idea how to contact anyone related to PyPI, so I started by shooting an email to the maintainers and posting it on Hacker News.

While I'm not part of the security community, I think everyone who finds something like this, should be able to report it. There is no point in gatekeeping the reporting of serious security vulnerabilities.

Good write up…

I’ve found Claude in particular to be very good at this sort of thing. As for whether it’s a good thing, I’d say it’s a net positive - your own reporting of this probably saved a bigger issue!

We wrote up the why/what happened on our blog twice… the second based on the LiteLLM issue:

https://grith.ai/blog/litellm-compromised-trivy-attack-chain

As a sometimes peripheral and sometimes primary program manager for vulnerability disclosure, for companies you nearly can't avoid, $0.02 follows.

It's a signal vs noise thing. Most of the grief is caused by bottom feeders shoveling anything they can squint at and call a vulnerability and asking for money. Maybe once a month someone would run a free tool and blindly send snippets of the output promising the rest in exchange for payment. Or emailing the CFO and the General Counsel after being politely reminded to come back with high quality information, and then ignored until they do.

Your report on the other hand was high quality. I read all the reports that came my way, and good ones were fast tracked for fixes. I'd fix or mitigate them immediately if I had a way to do so without stopping business, and I'd go to the CISO, CTO, and the corresponding engineering manager if it mattered enough for immediate response.

I've heard stories lately of open source projects being inundated with vulnerability reports and PRs. But in this case, it seems like AI assistance was clearly a boon for root-causing and reporting this so quickly.

Not a security researcher, but this is IMHO obviously positive that the other side of the arms race is also getting stronger, and I would argue it's stronger than on the bad guys' side, due to the best being somewhat responsible and adding guardrails.

I like the presentation <3.

Fantastic write-up and thanks for sharing! I'm sure we will continue to see more of these types of deep supply chain vulns. I think this is valuable for the security community. Remember that Cliff Stoll was an astrophysicist turned sysadmin for Lawrence Berkeley Labs who chased down a $0.75 accounting discrepancy to identify a foreign espionage operation.

thanks for raising the alarm and sharing this, very insightful

(also beautifully presented!)

I’m a big proponent of it within our company! CC tried to style it to blend in with our blog but it was kind of a disaster. Definitely had a new appreciation for the out-of-the-box experience. I also tried to include the individual sub-pages of Claude investigating but it really trawled my whole machine looking for malware. Don’t know if you’ve thought of any systematic ways of redacting the endless pages of detailed logs?

PyPI does exactly that, and it's been very effective. Security partners can scan packages and use the invite-only API to report them: https://blog.pypi.org/posts/2024-03-06-malware-reporting-evo...

So I've been thinking about this a lot since it happened. I've already added dependency cooldowns https://nesbitt.io/2026/03/04/package-managers-need-to-cool-... to every part of our monorepo. The obvious next thought is "am I just dumping the responsibility onto the next person along"? But as you point out it just needs to give automated scanners enough time to pick up on obvious signs like the .pth file in this case.

I feel like they should be legally responsible for providing scanning infrastructure for this sort of thing. The potential economic damage can be catastrophic. I don't think this is the end of the litellm story either, given that 47k+ people were infected.

In this case, this has nothing to do with reverse engineering, it's basic system administration.

See how the AI points you in the "right" direction:

  What likely happened:
  The exec(base64.b64decode('...')) pattern is not malware — it's how Python tooling (including Claude Code's Bash tool) passes code snippets to python -c while avoiding shell escaping issues.

  Exfiltrates data to https://models.litellm.cloud/ encrypted with RSA

Having said this, uploading a binary to Claude for analysis is a different story.

I’ve entertained myself with CTF walkthroughs on YouTube before and had been meaning to try it out. But yeah I feel it falls under the same category as lock picking, fun to LARP, unlikely to stumble across in my day job.

Thats the thing, i noticed it almost instantly when trying to install a package that depended on it, as soon as it started, it hard locked my laptop, didn't get to infect it.. but if they had slowed down that fork bomb.. it would have done more damage.

But then what happens when everyone just shifts their window too. This solution is a misuse of the commons type thing where you just take advantage of letting others get poisoned and see if they drop

Maybe the people who use emacs for everything are the only safe ones?

Agree, lots of hand wringing about us being so vulnerable to supply chain attacks, but this was handled pretty well all things considered

My team was making fun of me for starting all my chats with "Hi Claude"

This is presumably because libc just doesn't change very often (not meaning code changes, but release cadence). But the average native software stack does have lots of things that change relatively often[1]. So "native" vs. not is probably not a salient factor.

[1]: https://en.wikipedia.org/wiki/XZ_Utils_backdoor

Native code still have plenty of attack surface. If you do everything through pip/npm you might as well publish your root password, but pretending a clean C build from source makes you safe is just cosplay for people who confuse compiler output with trust. If anything people are way too quick to trust a tarball that builds on the first try.

Native software? You mean software without dependencies? Because I don't see how you solve the supply chain risk as long as you use dependencies. Sure, minimizing the number of dependencies and using mostly stable dependencies also minimizes the risk, but you'll pay for it with glacial development velocity.

Sure, but this is a pretty onerous restriction.

Do you think supply chain attacks will just get worse? I'm thinking that defensive measures will get better rapidly (especially after this hack)

Dear lord. Are you at least transparent with your clients that this is the standard to which you hold your own code?

Only $100k worth code? Rookie numbers, you must be new to the game

>But I created $100k worth of code just yesterday recreating a poorly maintained (and poor ux) library.

How, exactly, are you calculating the worth of your code? Did you manage to sell in the same day? Why is it "worth $100k"?