This one is really bad. It was only live on PyPI for about an hour as far as I can tell before it was quarantined there, but it's an unpinned dependency of a bunch of downstream projects (like DSPy) and has more than 3 million daily downloads so that's still enough time to steal a whole lot of credentials.
I found good details about this in this issue opened against LiteLLM itself.
Like most people, I still run development environments directly on my Mac. I would have been hit by this one really badly if I'd installed that package while the vulnerability was live. Maybe this will be the thing that convinces me to figure out a good local sandboxing strategy!
I currently have a separate user account on my workstation solely for agentic stuff, but it's feeling wise to start doing it even for tradcoding, yeesh
I would have been hit by this one really badly if I'd installed that package while the vulnerability was live. Maybe this will be the thing that convinces me to figure out a good local sandboxing strategy!
Nice clear write-up with clear indicators of compromise. It was nice to not have to read through 3 paragraphs of fluff about their expertise and process.
So any Python package that gets installed on any project for any reason can come with a ".pth" file that is executed automatically whenever you run any Python? Isn't this crazy?
Almost as bad as npm postinstall scripts.
Is there any sane package manager out there in any language that only downloads source code instead of executing stuff arbitrarily?
simonw | 22 hours ago
This one is really bad. It was only live on PyPI for about an hour as far as I can tell before it was quarantined there, but it's an unpinned dependency of a bunch of downstream projects (like DSPy) and has more than 3 million daily downloads so that's still enough time to steal a whole lot of credentials.
I found good details about this in this issue opened against LiteLLM itself.
Like most people, I still run development environments directly on my Mac. I would have been hit by this one really badly if I'd installed that package while the vulnerability was live. Maybe this will be the thing that convinces me to figure out a good local sandboxing strategy!
nonagoninf | 11 hours ago
The permanent item on my to-do list to try Qubes has bumped up again.
aae | 22 hours ago
Or short-living all credentials... that's what's been on my mind amidst this disaster
ashishb | 18 hours ago
I wrote a sandbox to limit the attack surface of such malicious binaries last year. Give it a try.
dvshkn | 15 hours ago
I currently have a separate user account on my workstation solely for agentic stuff, but it's feeling wise to start doing it even for tradcoding, yeesh
gnyeki | 2 hours ago
It looks like uv's
exclude-newerconfig option would have also prevented compromise as a stopgap measure.simonw | an hour ago
Yeah, those dependency cooldown mechanisms are looking very attractive right now. It turns out npm/pnpm/deno/etc have them too: https://simonwillison.net/2026/Mar/24/package-managers-need-to-cool-down/
dvogel | a day ago
Nice clear write-up with clear indicators of compromise. It was nice to not have to read through 3 paragraphs of fluff about their expertise and process.
akavel | a day ago
What seems to be a reconstructed timeline of the attack:
https://ramimac.me/trivy-teampcp/
Personally, I find it both a fascinating and scary read.
Sanity | 9 hours ago
only discovered because a bug created a fork bomb – how many went undiscovered? :-S
fiatjaf | 5 hours ago
So any Python package that gets installed on any project for any reason can come with a ".pth" file that is executed automatically whenever you run any Python? Isn't this crazy?
Almost as bad as npm postinstall scripts.
Is there any sane package manager out there in any language that only downloads source code instead of executing stuff arbitrarily?
jiangplus | 5 hours ago
I wish there is something like LavaMoat everywhere
https://github.com/LavaMoat/LavaMoat