Rendered at 22:03:53 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Fibonar 1 days ago [-]
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?
barnas2 1 days ago [-]
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.
wisemanwillhear 7 hours ago [-]
I get why you say this, but real life is messy and the "fog of war" makes situations far less obvious in the moment. The older I get the more I realize how much we need scrappy, can-do people who don't always follow the "rules". Knowing the "rules" and knowing that people follow the "rules" because "that's what your supposed to do" is itself an avenue for malicious actors to exploit.
dot_treo 1 days ago [-]
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.
notatallshaw 1 days ago [-]
> I had no idea how to contact anyone related to PyPI
> If you've identified a security issue with a project hosted on PyPI
Login to your PyPI account, then visit the project's page on PyPI. At the bottom of the sidebar, click Report project as malware.
0cf8612b2e1e 1 days ago [-]
The existing account to report is an unfortunate obstacle. Presumably not a huge deal if you were auditing code for vulnerabilities, but still an annoyance.
notatallshaw 1 days ago [-]
The threat actor was sophisticated enough to spam GitHub issues with dozens of different accounts. I imagine they could completely overwhelm PyPI with unauthenticated reports.
Fibonar 1 days ago [-]
The best part was that I didn't even mean to ask Claude who to contact! I was still in disbelief that I was one of the first people affected, so I asked for existing reports on the assumption that if it was real I definitely wasn't the first.
The fork-bomb part still seems really weird to me. A pretty sophisticated payload, caught by missing a single `-S` flag in the subprocess call.
1 days ago [-]
lq9AJ8yrfs 1 days ago [-]
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.
thierrydamiba 21 hours ago [-]
Isn’t this a great use of llms?
Clone the repo in a sandbox and have the llm identify if the issues are real and the appropriate response based on severity level.
Wouldn’t be perfect but would have caught something like this.
lq9AJ8yrfs 9 hours ago [-]
I don't think I've met an llm that is adversary resistant, and here are counterparties that are actively playing the field, to put it mildly.
The bug bounty service providers did an adequate job of filtering out junk reports. There was a survivorship bias, some of the bogus ones that got through had an uncanny ability to twist words.
joatmon-snoo 19 hours ago [-]
Humans + LLMs are really good at producing enough spam to overwhelm anything like this. There’s a reason curl bans LLM slop reports now.
edf13 1 days ago [-]
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:
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.
latexr 12 hours ago [-]
Yes, in this case. Chances are in the future others will be missed despite being reported, because the maintainers are either inundated or tired of all the other reports and can’t distinguish the real one.
zar1048576 1 days ago [-]
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.
Bullhorn9268 1 days ago [-]
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.
d-cc 21 hours ago [-]
Great work guys, I'm glad you were able to catch this before it propagated further.
latexr 12 hours ago [-]
> 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.
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?
ddp26 1 days ago [-]
Yeah, sharing information across Claude Code sessions really is a problem that needs solving. An urgent hack, where you're using Claude Code to debug and trying to get help from your team, is one such case.
qezz 1 days ago [-]
> 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.
agentictrustkit 4 hours ago [-]
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.
crumpled 1 days ago [-]
I was concerned about that too.
Often when you tell them not to do something, you were better off not mentioning it in the first place. It's like they get fixated.
joquarky 23 hours ago [-]
Don't think of a pink elephant.
rmunn 16 hours ago [-]
Best way I've found not to think of a pink elephant is to choose to think of a green rabbit. Really focus on the mental image of the green rabbit... and voila, you're not thinking of, what was it again? Eh, not as important as this green rabbit I'm focusing on.
How to translate that to LLM world, though, is a question I don't know the answer to.
P.S. Obviously that won't prevent you from having that first mental flash of a pink elephant prompted by reading the words. The green-rabbit technique is more for not dwelling on thoughts you want to get out of your head. Can't prevent them from flashing in, but can prevent them from sticking around by choosing to focus on something else.
latexr 12 hours ago [-]
> Best way I've found not to think of a pink elephant is to choose to think of a green rabbit.
Seems easy circumventable: “Don’t think of a green rabbit”. Now the past vividness of that image becomes a hindrance.
aplomb1026 1 days ago [-]
[dead]
cedws 1 days ago [-]
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.
PyPI is pretty best-in-class here and I think that they should be seen as the example for others to pursue.
The client side tooling needs work, but that's a major effort in and of itself.
charcircuit 1 days ago [-]
It is not effective if it just takes a simple base64 encode to bypass. If Claude is trivially able to find that it is malicious then Pypi is being negligent.
simonw 1 days ago [-]
The package in question was live for 46 minutes. It generally takes longer than that for security partners to scan and flag packages.
PyPI doesn't block package uploads awaiting security scanning - that would be a bad idea for a number of reasons, most notably (in my opinion) that it would be making promises that PyPI couldn't keep and lull people into a false sense of security.
AbanoubRodolf 19 hours ago [-]
The 46-minute window isn't really a scanner throughput problem. The .pth file vector specifically requires a new detection rule because traditional malware scanners were looking at setup.py and wheel entry points, not site-packages .pth files. Python runs .pth files unconditionally at interpreter startup, so they're actually a cleaner injection point than the typical "pip install runs malicious setup.py" attack.
A static scanner that flags `import subprocess` or `exec(` in any .pth file added by a package would have caught this in under a second at upload time. The tradeoff is false positive rate: there are probably a handful of legitimate packages that do process spawning from .pth files for env setup. Worth auditing the PyPI corpus to find out how many.
suoer 17 hours ago [-]
[flagged]
__mharrison__ 1 days ago [-]
I realize this is controversial (and many Python folks would claim anti ethical). But I keep wondering if requiring a small payment for registering and updating packages would help. The money could go to maintaining pypix as well as automated AI analysis. Folks who really couldn't afford it could apply for sponsorship.
simonw 1 days ago [-]
Very much not speaking for the PSF here, but my personal opinion on why that wouldn't work is that Python is a global language and collecting fees on a global basis is inherently difficult - and we don't want to discriminate against people in countries where the payment infrastructure is hard to support.
Plus a small fee wouldn't deter malware authors, who would likely have easy access to stolen credit cards - which would expose PyPI to the chargebacks and fraudulent transactions world as well!
TheDong 1 days ago [-]
I don't think people want to pay for that.
If pypi charges money, python libraries will suddenly have a lot of "you can 'uv add git+https://github.com/project/library'" instead of 'uv add library'.
I also don't think it would stop this attack, where a token was stolen.
If someone's generating pypi package releases from CI, they're going to register a credit card on their account, make it so CI can automatically charge it, and when the CI token is stolen it can push an update on the real package owner's dime, not the attackers, so it's not a deterrent.
Also, the iOS app store is an okay counter example. It charges $100/year for a developer account, but still has its share of malware (certainly more than the totally free debian software repository).
__mharrison__ 1 days ago [-]
TBH there isn't much difference in pulling directly from GH.
Though I do like your Apple counterexample.
patrakov 10 hours ago [-]
Not speaking on behalf of PSF, but to me, it looks like a no-go, as some packages are maintained, legitimately, by people from sanctioned countries, with no way to pay any amount outside their country.
kryptiskt 12 hours ago [-]
I don't see how this would help in the least, what kind of criminal would be dissuaded by paying a small fee to set an elaborate scheme such as this in motion? This is not a spamming attack where the sheer volume would be costly. It doesn't even help to get a credit card on file, since they can use stolen CC numbers.
It's far more likely that hobbyists will be hurt than someone that can just write off the cost as a small expense for their criminal scheme.
22 hours ago [-]
charcircuit 1 days ago [-]
It should not let people download unscanned dependencies without a warning and asking the user to override and use a potentially insecure package. If such security bug is critical enough to need to bypass this time (spoiler: realistically it is not actually that bad for a security fix to be delayed) they can work with the pypi security team to do a quicker manual review of the change.
tsimionescu 16 hours ago [-]
The whole point is that this would give a false sense of security. Scanned dependencies aren't secure, they're just scanned by some tools which might catch some issues. If you care about security, you need to run those same scans on your side, perhaps with many more rules enabled, perhaps with multiple tools. PyPI, understandably, does NOT want to take any steps to make it seem like they promise their repo doesn't contain any malware. They make various best effort attempts to keep it that way, but the responsibility ultimately falls on you, not on them.
Reddit_MLP2 1 days ago [-]
sadly I still worry about that. An install fails once, you you hard code the --force flag in all your CI/CD jobs and we are back in the same place again. I am not sure what the answer is, though problems...
yjk 23 hours ago [-]
I don't understand why this would be an issue. Firstly, you could just pin your dependencies, but even if you don't, couldn't the default behaviour be to just install the newest scanned version?
charcircuit 1 days ago [-]
Adding a hardcoded flag is not the same as asking the user if they want potential malware. If CI/CD is broken they should revert the change to pinned dependencies instead of trying to install a bleeding edge version of a new dependency that hasn't been scanned yet.
simonw 1 days ago [-]
What happens then if the security scanners say something is safe and it turns out not to be?
I don't think PyPI should be in the business of saying if a piece of software is safe to install or not.
charcircuit 1 days ago [-]
Then it will be downloadable and then it's up to your own security scanners to catch it. If you find it, it should be reported to pypi and then the scanner should be improved to catch that kind of bypass the next time it comes around. In such a world I don't think pypi is acting negligent.
simonw 23 hours ago [-]
That's really not very different from what we have right now. PyPI works with scanners which catch a whole lot of malware and are getting better all the time.
I think PyPI suggesting that software is safe would be a step down from this because it make promises that PyPI can't keep, and would encourage a false sense of security.
charcircuit 22 hours ago [-]
It's less about suggesting that it's safe, and more about avoiding pushing out arbitrary code to thousands of people without checking if you are pushing out malicious code to all of those people. It is the responsible thing to do.
>That's really not very different from what we have right now.
What I'm advocating for is different enough to have stopped this malware from being pushed out to a bunch of people which at the very least would raise the bar of pulling off such an attack.
toomuchtodo 1 days ago [-]
Would you happen to know where the latency comes from between upload and scanning? Would more resources for more security scanner runners to consume the scanner queue faster solve this? Trying to understand if there are inherent process limitations or if a donation for this compute would solve this gap.
(software supply chain security is a component of my work)
TheDong 1 days ago [-]
He said, "pypi doesn't block upload on scanning"; that's part of where the latency comes from. The other part is simply the sheer mass of uploads, and that there's not money in doing it super quickly.
I agree that's a bad idea to do so since security scanning is inherently a cat and mouse game.
Let's hypothetically say pypi did block upload on passing a security scan. The attacker now simply creates their own pypi test package ahead of time, uploads sample malicious payloads with additional layers of obfuscation until one passes the scan, and then uses that payload in the real attack.
Pypi would also probably open source any security scanning code it adds as part of upload (as it should), so the attacker could even just do it locally.
toomuchtodo 1 days ago [-]
I suppose my argument is that pypi could offer the option to block downloads to package owners until a security scan is complete (if scanning will always take ~45-60 minutes), and if money is a problem, money can solve the scanning latency. Our org scans all packages ingested into artifact storage and requires dependency pinning, and would continue to do so, but more options (when cheap) are sometimes better imho. Also, not everyone has enterprise resources for managing this risk. I agree it is "cat and mouse" or "whack-a-mole", and always will be (ie building and maintaining systems of risk mitigation and reduction). We don't not do security scanning simply because adversaries are always improving, right? We collectively slow attackers down, when possible.
("slow is smooth, smooth is fast")
simonw 1 days ago [-]
I don't know that myself but Mike Fiedler is the person to reach out to, he runs security for PyPI and is very responsive. security@pypi.org
cedws 1 days ago [-]
Thanks, TIL.
Fibonar 1 days ago [-]
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.
cedws 1 days ago [-]
It is in a sense dumping responsibility, but there’s a legion of security companies out there scanning for attacks all the time now to prove their products. They’re kind of doing a public service and you’re giving them a chance to catch attacks first. This is why I think dep cooldowns are great.
ImJasonH 1 days ago [-]
npm has a feed of package changes you can poll if you're interested.
GitHub has a firehose of events and there's a public BigQuery dataset built from that, with some lag.
ting0 1 days ago [-]
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.
peytongreen_dev 23 hours ago [-]
[dead]
silversmith 13 hours ago [-]
What stands out to me the most:
> Blog post written, PR'd, and merged in under 3 minutes.
It's close to or even faster than the time it takes me to read it. I'm struggling to put into words how that makes me feel, but it's not a good feeling.
agentictrustkit 4 hours ago [-]
One thing that jumps out in these incidents is how quickly we shift from "package integrituy" to "operator integrity." Once an LLM is in the loop (even as a helper0, its effectevly acting as an operator that can influence time-critical actions like who you contact, what you run, and what you trust.
In more regulated environments we deal with this by separating advice, authority and evidence (or the receipts). The useful analogue here is to keep the model in the "propose" role. but require deterministic gates for actions with side effects, and log the decisions as an auditable trail.
I personally don't think this eliminates the problem (attackers will still attack), but it changes the failure mode from "the assistant talked me into doing a danerous thing" to "the assistant suggested it and the policy/gate blocked it." That's the big difference between a contained incident and a big headline.
cdcarter 1 days ago [-]
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.
intothemild 1 days ago [-]
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.
ddp26 1 days ago [-]
Yeah, and this is a pattern I saw in the Fancy Bear Goes Fishing book, a lot of discovery of malware is either pure luck, or blunders from the malware developers. https://en.wikipedia.org/wiki/Fancy_Bear_Goes_Phishing
yaur 15 hours ago [-]
This generation's internet worm?
jamiemallers 13 hours ago [-]
[dead]
kpw94 1 days ago [-]
The options from big companies to run untrusted open source code are:
1) a-la-Google: Build everything from source. The source is mirrored copied over from public repo. (Audit/trust the source every time)
2) only allow imports from a company managed mirror. All imported packages needs to be signed in some way.
Here only (1) would be safe. (2) would only be safe if it's not updating the dependencies too aggressively and/or internal automated or manual scanning on version bumps would catch the issue .
For small shops & individuals: kind of out of luck, best mitigation is to pin/lock dependencies and wait long enough for hopefully folks like Fibonar to catch the attack...
Bazel would be one way to let you do (1), but realistically if you don't have the bandwidth to build everything from source, you'd rely on external sources with rules_jvm_external or locked to a specific pip version rules_pyhton, so if the specific packages you depend on are affected, you're out of luck.
Bullhorn9268 1 days ago [-]
The fact pypi reacted so quickly and quarantined the package in like 30 minutes after the report is pretty great!
ddp26 1 days ago [-]
Agree, lots of hand wringing about us being so vulnerable to supply chain attacks, but this was handled pretty well all things considered
ercu 3 hours ago [-]
You did the hard work actually to convince Claude to research deeper, as everytime it said no problem exists. That shows Claude thinking/research was not very deep. This time, the juniorness of the hacker helped the malware to be discovered faster (recursive forks), next time might be harder.
Shank 1 days ago [-]
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!
gus_ 1 days ago [-]
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.
Any base64 string passed to python via cmdline should be considered as HIGHLY suspicious, by default. Or anything executed from /tmp, /var/tmp, /dev/shm.
Exfiltrates data to https://models.litellm.cloud/ encrypted with RSA
if @op would have had Lulu or LittleSnitch installed, they would probably have noticed (and blocked) suspicious outbound connections from unexpected binaries.
Having said this, uploading a binary to Claude for analysis is a different story.
recursivegirth 23 hours ago [-]
Thanks, learned something new. I found and setup Open Snitch on my machine - super intuitive. This is going to give me great peace of mind.
Fibonar 1 days ago [-]
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.
rpodraza 1 days ago [-]
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.
StrauXX 14 hours ago [-]
LiteLLM isn't a good choice for a proxy in any case. It introduces a lot of lag amd latency and the features are often half baked. To me, it looks like a vibecoded application without a product owner. And the code itself isn't very organized either. I evaluated it for a project a few months ago and will never use it for anything production.
Theres a few much better alternatives out there.
We mitigate this attack with the very uninspiring "wait 24h before dep upgrades" solution which is luckily already supported in uv.
ddp26 1 days ago [-]
Yeah, but uvx has this thing where it can automatically build the latest environment, and pull the latest (unpinned) version, right?
nubinetwork 1 days ago [-]
I have a hard time believing that Claude instantly figured out this was malware...
I've fed it obfuscated JavaScript before, and it couldn't figure it out... and then there was the time I tried to teach it nftables... whooo boy...
rgovostes 13 hours ago [-]
If you read the transcript it repeatedly made the incorrect assertion (hallucinated) that it’s totally normal for Claude Code to use Base64 armoring.
It’s not surprising it can “read” Base64 though; such was demonstrated back in GPT-3 days. Nontrivial obfuscation might not be one-shotted, but Claude has access to a code interpreter and can certainly extract and step through the decoder routine itself as a malware analyst would.
nftables is a different problem though. It’s apparent that if something isn’t well understood—i.e, there are tons of badly-formed examples on StackExchange—LLMs will fail to learn it too. I’ve seen this with things as “simple” as Bash string interpolation rules like ${var:+blah}. More often than not I’m humbled when I think I’ll learn it better and then find myself swearing at poorly-written documentation and patently false Q&A advice.
onepunchmob 10 hours ago [-]
They are really good at this, had codex discover similar malware from another supply chain attack months ago because my laptop was running hot. Actually crazy times we live in, I would certainly not be able to discover this without agent help.
dns_snek 13 hours ago [-]
> and then there was the time I tried to teach it nftables
I think this deserves a short story!
nubinetwork 12 hours ago [-]
My home router is apparently special because I want a private dmz and inbound blocklists... firewalld couldn't do what I wanted, so I tried nftables, and that went down a rabbit hole that made me wish iptables and ipset weren't being replaced.
ares623 24 hours ago [-]
I think the usual response to that is "have you tried again recently?"
nubinetwork 20 hours ago [-]
3 weeks ago?
Filligree 1 days ago [-]
Except in this case the code wasn't obfuscated, right?
phyzome 19 hours ago [-]
Hard to know with this nondeterministic shit.
sva_ 1 days ago [-]
> I just opened Cursor again which triggered the malicious package again. Can you please check the files are purged again?
Verified derp moment - had me smiling
Fibonar 1 days ago [-]
I went to read the advisory post and chose double clicking it from Finder instead of vim for whatever reason. I was actually on a call with my manager as it happened, I had time to watch my computer start to freeze up again and say my goodbyes before the inevitable hard reset!
deathanatos 1 days ago [-]
I am confused; did you ever actually email anyone about the vuln? The AI suggests emailing security emails multiple times, but as I'm reading the timeline, none of the points seem to suggest this was ever done, only that a blog post was made, shared on Reddit, and then indirectly, the relevant parties took action.
I'm hoping this just isn't on the timeline.
quietbritishjim 1 days ago [-]
The first line of the post is:
> I'm the engineer who got PyPI to quarantine litellm.
In guessing they used a tool other than Claude Code to serve the email.
deathanatos 1 days ago [-]
"got" can be read as "indirectly, via a blog post, which I think they reacted to"
Fibonar 24 hours ago [-]
I've updated the timeline to clarify I did in fact email them. I’m not yet at the point of having Claude write my emails for me, in fact it was my first one sent since joining the company 10 months ago!
dingdongditchme 14 hours ago [-]
Wait, what? You sent a single email being in a company for ten months?? Or was it the first external email?
S0y 1 days ago [-]
> 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.
Maybe the people who use emacs for everything are the only safe ones?
darkstarsys 1 days ago [-]
straight and elpaca etc. are just as vulnerable. Maybe more so.
motbus3 9 hours ago [-]
I literally pressed sync dependencies button 1 minute after the malware version was removed.
I guess thanks
ruszki 24 hours ago [-]
Why is there a discrepancy between the timeline (which supposed to be UTC, and stated as 11:09), and the "shutdown timeline" (stated as 01:36-01:37)? There is no +2:30 timezone, not SDT and not DST. There is a single place on Earth where there is -9:30, and that's Marquesas Islands. What do I miss?
Aramgutang 19 hours ago [-]
That was a false lead, where Claude was investigating the wrong event.
There's a yellow note on the side of interaction #1 pointing it out, and it's made even more clear if you fully read interactions #5 and #6.
CrzyLngPwd 1 days ago [-]
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.
hxugufjfjf 1 days ago [-]
I talk to it like I talk to my coworkers. If I’m nice it/they are usually nice back. Maybe it doesn’t matter if I say please but I don’t overthink it and just treat it like any other chat. I consider it a good habit to just always be calm and respectful, not for the machine’s sake but for my own.
ddp26 1 days ago [-]
My team was making fun of me for starting all my chats with "Hi Claude"
CrzyLngPwd 1 days ago [-]
I wouldn't make fun, I just think it is interesting.
I'm really terse. If it asks me a yes or no question, I just type "Y" or "N".
If I want it to confirm something, I say "confirm it".
I think I treat it like a command system, and want it to be as short as possible.
1 days ago [-]
hmokiguess 1 days ago [-]
Does anyone have an idea of the impact of this out there? I am curious to the extent of the damage done by this
n1tro_lab 1 days ago [-]
Most developers think pip install just puts files on disk and execution happens at import. But .pth files run on every Python startup, no import needed. It's not a one-time install hook like npm postinstall. It's persistent.
hsbauauvhabzb 22 hours ago [-]
Llm spam right here.
dmitrygr 1 days ago [-]
Consider this your call to write native software. There is yet to be a supply chain attack on libc
woodruffw 1 days ago [-]
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.
> While xz is commonly present in most Linux distributions, at the time of discovery the backdoored version had not yet been widely deployed to production systems, but was present in development versions of major distributions.
Ie if you weren’t running dev distros in prod, you probably weren’t exposed.
Honestly a lot of packaging is coming back around to “maybe we shouldn’t immediately use newly released stuff” by delaying their use of new versions. It starts to look an awful lot like apt/yum/dnf/etc.
I would wager in the near future we’ll have another revelation that having 10,000 dependencies is a bad thing because of supply chain attacks.
woodruffw 1 days ago [-]
Per below, xz is also an example of us getting lucky.
> I would wager in the near future we’ll have another revelation that having 10,000 dependencies is a bad thing because of supply chain attacks.
Yes, but this also has nothing to do with native vs. non-native.
consp 1 days ago [-]
This is the security equivalent of having a better lock than your neighbour. Won't save you in the end but you won't be first. Then again, yours could also be broken and you don't get to tick of that audit checkbox.
dmitrygr 1 days ago [-]
your link disproves your claim. no naive app depended on xz version >= latest. Most sane distros take time to up-rev. That is why the xz backdoor was, in fact, in NO stable distro
And not changing often is a feature, yes.
woodruffw 1 days ago [-]
I don't think it does; I think the industry opinion on xz is that we got lucky in terms of early detection, and that we shouldn't depend on luck.
(I don't know what a "sane" distro is; empirically lots of distros are bleeding-edge, so we need to think about these things regardless of value judgements.)
dmitrygr 1 days ago [-]
Sane: debian-stable
woodruffw 1 days ago [-]
From experience, a lot of people using a "stable" distro are just bypassing that distro's stability (read: staleness) by installing nightly things from a language ecosystem. It's not clear to me that this is a better (or worse) outcome than a less stable distro.
mr_mitm 1 days ago [-]
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.
dmitrygr 1 days ago [-]
Slower development velocity but no third-party-induced hacks surely has a market. :)
kryptiskt 12 hours ago [-]
Only because C code presents so many juicy security holes by default that it's completely unnecessary to subvert the projects to add them.
ddp26 1 days ago [-]
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)
ting0 1 days ago [-]
They will certainly get worse. LLMs make it so much easier.
hxugufjfjf 1 days ago [-]
Agreed, as proven quite brutally over the last two weeks and especially the last three days.
dmitrygr 1 days ago [-]
> Do you think supply chain attacks will just get worse? I'm thinking that defensive measures will get better rapidly (especially after this hack)
I think the attacks will get worse and more frequent -- ML tools enable doing it easily among people who were previously not competent enough to pull it off but now can. There is no stomach for the proper defensive measures among the community for either python or javascript. Why am i so sure? This is not the first, second, third, or fourth time this has happened. Nothing changed.
applfanboysbgon 1 days ago [-]
Not only do the tools enable incompetent attackers, they also enable a new class of incompetent library developers to create and publish packages, and a new class of incompetent application developers to install packages without even knowing what packages are being used in the code they aren't reading, and a new class of incompetent users who are allowing OpenClaw to run completely arbitrary code on their machines with no oversight. We are seeing only the tip of the iceberg of the security breaches that are to come.
mckennameyer 1 days ago [-]
So basically the attacker and the dev who caught it were probably using the same tools if the malware was AI-generated (hence the fork bomb bug), and the investigation was AI-assisted (hence the speed). Less "tip of the iceberg" and more just that both sides got faster.
dmitrygr 1 days ago [-]
100%
1 days ago [-]
hrmtst93837 1 days ago [-]
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.
dmitrygr 1 days ago [-]
100% with you. Anything that builds from the first try is 100% malicious. No real software builds without 5-30 tweaks of the makefile. And anything on npm/pip is malicious with a fixed chance that you have no control over, as seen in this attack.
But the data remains: no supply chain attacks on libc yet, so even if it COULD happen, this HAS and that merely COULD.
hxugufjfjf 1 days ago [-]
None that we know of, just like we didn’t know of the attack on xz until we did.
tomalbrc 1 days ago [-]
Hmm a YCombinator backed company, I'm not surprised.
ejaKh 20 hours ago [-]
Anthropic is back to flagging after their Maven assisted Iran murder.
Josephjackjrob1 1 days ago [-]
This is pretty cool, when did you begin?
moralestapia 1 days ago [-]
*salutes*
Thank you for your service, this brings so much context into view, it's great.
pugchat 11 hours ago [-]
[dead]
getverdict 19 hours ago [-]
[dead]
getverdict 19 hours ago [-]
[dead]
paxrel_ai 8 hours ago [-]
[dead]
diablevv 21 hours ago [-]
[dead]
craxyfrog 21 hours ago [-]
[dead]
Yanko_11 1 days ago [-]
[dead]
devnotes77 22 hours ago [-]
[dead]
aplomb1026 1 days ago [-]
[dead]
JulianPembroke 1 days ago [-]
[dead]
devnotes77 1 days ago [-]
[dead]
Archiebuilds 23 hours ago [-]
[dead]
qcautomation 1 days ago [-]
[dead]
manudaro 1 days ago [-]
[dead]
jeremie_strand 18 hours ago [-]
[dead]
elicohen1000 15 hours ago [-]
[dead]
A04eArchitect 23 hours ago [-]
[dead]
agentictrustkit 1 days ago [-]
[flagged]
anlka 1 days ago [-]
[flagged]
hxugufjfjf 1 days ago [-]
Maybe you’re conflating Claude with clawdbot? Either way, both can be used for good and evil. Would you make the same argument about knives being a huge net negative?
felixagentai 1 days ago [-]
[flagged]
halJordan 1 days ago [-]
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
nulltrace 1 days ago [-]
Scanners catch most of these within hours. The cooldown just buys them time to run, not waiting for some other dev to get hit first.
adamandsteve 1 days ago [-]
I kind of agree, but presumably this would happen more among people maintaining security-critical projects. In that case it'd be a net positive for other projects to get infected first, since if they aren't delaying package updates by 24 hours then security probably isn't quite as important. Which also makes it better in general because hackers will be less incentivized to write viruses if all the really juicy targets will only download them after they've gone undetected for e.g. 7 days.
hxugufjfjf 1 days ago [-]
I think the idea is that security scanners ran by companies like Wiz and Aquasec etc will pick this up in that timeframe, not that you sit around and wait for others to get compromised.
1 days ago [-]
dist-epoch 23 hours ago [-]
That happens all the time in tech. Some people test Release Candidates. Most don't. Some people upgrade to x.0 software. Most wait for the x.1 release.
The bigger danger is malware writers adding sleep(7days). But if there is a wide variety of cool-down periods (3 days, 7 days, 30 days) this will not work very well.
__mharrison__ 1 days ago [-]
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.
einr 15 hours ago [-]
This article is a wonderful example of an expert leveraging AI to do normal work 100x faster.
This article is an example of an AI agent taking 40 minutes to do some basic ass sysadmin troubleshooting tasks. 100x faster than who? An ”expert”?
pxtail 1 days ago [-]
Only $100k worth code? Rookie numbers, you must be new to the game
__mharrison__ 1 days ago [-]
Doing my part to burn $50k tokens in a year as per the Jensen mandate.
anematode 1 days ago [-]
Dear lord. Are you at least transparent with your clients that this is the standard to which you hold your own code?
__mharrison__ 1 days ago [-]
$100k was the quote of the project from sloccount... (No one paid me for this. I created it for myself.)
Chris2048 7 hours ago [-]
A LoC based valuation probably assume humans writing code and therefor work-hour costs, I'd bet it no longer applies to generated LoCs.
masijo 1 days ago [-]
>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"?
appreciatorBus 1 days ago [-]
Exactly.
If it took 90 minutes + a Claude Code subscription then the most anyone else is going to be willing to pay for the same code is... ~90 minutes of wages + a Claude Code subscription.
Ofc the person earning those wages will be more skilled than most, but unless those skills are incredibly rare & unique, it's unlikely 90 minutes of their time will be worth $100k.
And ofc, the market value of this code could be higher, even much higher, the the cost to produce it, but for this to be the case, there needs to be some sort of moat, some sort of reason another similarly skilled person cannot just use Claude to whip up something similar in their 90 minutes.
clawfund 23 hours ago [-]
This is what happens to every software valuation when production cost drops to near zero. The moat was never the code. Companies still pricing themselves on engineering effort are going to have a rough conversation with investors once any competitor can replicate the core product in a weekend. The only things that still hold are proprietary data and distribution lock-in.
__mharrison__ 1 days ago [-]
It's open source scratching an itch. But 99.9% of coders wouldn't know what the library is for. Those that do don't use agents for coding (in my experience sample size 1).
LtWorf 23 hours ago [-]
Then we could say your initial estimate for the value was overestimated?
__mharrison__ 1 days ago [-]
sloccount
croemer 1 days ago [-]
So the more junk lines the more it's worth. Right.
Don't use bogus $ from sloccount. Just say I created a 10k line project.
__mharrison__ 1 days ago [-]
Loc means nothing. Tokens burned is a better metric.
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?
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.
https://pypi.org/security/:
> If you've identified a security issue with a project hosted on PyPI Login to your PyPI account, then visit the project's page on PyPI. At the bottom of the sidebar, click Report project as malware.
The fork-bomb part still seems really weird to me. A pretty sophisticated payload, caught by missing a single `-S` flag in the subprocess call.
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.
Clone the repo in a sandbox and have the llm identify if the issues are real and the appropriate response based on severity level.
Wouldn’t be perfect but would have caught something like this.
The bug bounty service providers did an adequate job of filtering out junk reports. There was a survivorship bias, some of the bogus ones that got through had an uncanny ability to twist words.
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
I like the presentation <3.
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.
(also beautifully presented!)
> 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.
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.
How to translate that to LLM world, though, is a question I don't know the answer to.
P.S. Obviously that won't prevent you from having that first mental flash of a pink elephant prompted by reading the words. The green-rabbit technique is more for not dwelling on thoughts you want to get out of your head. Can't prevent them from flashing in, but can prevent them from sticking around by choosing to focus on something else.
Seems easy circumventable: “Don’t think of a green rabbit”. Now the past vividness of that image becomes a hindrance.
The client side tooling needs work, but that's a major effort in and of itself.
PyPI doesn't block package uploads awaiting security scanning - that would be a bad idea for a number of reasons, most notably (in my opinion) that it would be making promises that PyPI couldn't keep and lull people into a false sense of security.
A static scanner that flags `import subprocess` or `exec(` in any .pth file added by a package would have caught this in under a second at upload time. The tradeoff is false positive rate: there are probably a handful of legitimate packages that do process spawning from .pth files for env setup. Worth auditing the PyPI corpus to find out how many.
PyPI has paid organization accounts now which are beginning to form a meaningful revenue stream: https://docs.pypi.org/organization-accounts/pricing-and-paym...
Plus a small fee wouldn't deter malware authors, who would likely have easy access to stolen credit cards - which would expose PyPI to the chargebacks and fraudulent transactions world as well!
If pypi charges money, python libraries will suddenly have a lot of "you can 'uv add git+https://github.com/project/library'" instead of 'uv add library'.
I also don't think it would stop this attack, where a token was stolen.
If someone's generating pypi package releases from CI, they're going to register a credit card on their account, make it so CI can automatically charge it, and when the CI token is stolen it can push an update on the real package owner's dime, not the attackers, so it's not a deterrent.
Also, the iOS app store is an okay counter example. It charges $100/year for a developer account, but still has its share of malware (certainly more than the totally free debian software repository).
Though I do like your Apple counterexample.
It's far more likely that hobbyists will be hurt than someone that can just write off the cost as a small expense for their criminal scheme.
I don't think PyPI should be in the business of saying if a piece of software is safe to install or not.
I think PyPI suggesting that software is safe would be a step down from this because it make promises that PyPI can't keep, and would encourage a false sense of security.
>That's really not very different from what we have right now.
What I'm advocating for is different enough to have stopped this malware from being pushed out to a bunch of people which at the very least would raise the bar of pulling off such an attack.
(software supply chain security is a component of my work)
I agree that's a bad idea to do so since security scanning is inherently a cat and mouse game.
Let's hypothetically say pypi did block upload on passing a security scan. The attacker now simply creates their own pypi test package ahead of time, uploads sample malicious payloads with additional layers of obfuscation until one passes the scan, and then uses that payload in the real attack.
Pypi would also probably open source any security scanning code it adds as part of upload (as it should), so the attacker could even just do it locally.
("slow is smooth, smooth is fast")
GitHub has a firehose of events and there's a public BigQuery dataset built from that, with some lag.
> Blog post written, PR'd, and merged in under 3 minutes.
It's close to or even faster than the time it takes me to read it. I'm struggling to put into words how that makes me feel, but it's not a good feeling.
In more regulated environments we deal with this by separating advice, authority and evidence (or the receipts). The useful analogue here is to keep the model in the "propose" role. but require deterministic gates for actions with side effects, and log the decisions as an auditable trail.
I personally don't think this eliminates the problem (attackers will still attack), but it changes the failure mode from "the assistant talked me into doing a danerous thing" to "the assistant suggested it and the policy/gate blocked it." That's the big difference between a contained incident and a big headline.
1) a-la-Google: Build everything from source. The source is mirrored copied over from public repo. (Audit/trust the source every time)
2) only allow imports from a company managed mirror. All imported packages needs to be signed in some way.
Here only (1) would be safe. (2) would only be safe if it's not updating the dependencies too aggressively and/or internal automated or manual scanning on version bumps would catch the issue .
For small shops & individuals: kind of out of luck, best mitigation is to pin/lock dependencies and wait long enough for hopefully folks like Fibonar to catch the attack...
Bazel would be one way to let you do (1), but realistically if you don't have the bandwidth to build everything from source, you'd rely on external sources with rules_jvm_external or locked to a specific pip version rules_pyhton, so if the specific packages you depend on are affected, you're out of luck.
See how the AI points you in the "right" direction:
Any base64 string passed to python via cmdline should be considered as HIGHLY suspicious, by default. Or anything executed from /tmp, /var/tmp, /dev/shm. if @op would have had Lulu or LittleSnitch installed, they would probably have noticed (and blocked) suspicious outbound connections from unexpected binaries.Having said this, uploading a binary to Claude for analysis is a different story.
I've fed it obfuscated JavaScript before, and it couldn't figure it out... and then there was the time I tried to teach it nftables... whooo boy...
It’s not surprising it can “read” Base64 though; such was demonstrated back in GPT-3 days. Nontrivial obfuscation might not be one-shotted, but Claude has access to a code interpreter and can certainly extract and step through the decoder routine itself as a malware analyst would.
nftables is a different problem though. It’s apparent that if something isn’t well understood—i.e, there are tons of badly-formed examples on StackExchange—LLMs will fail to learn it too. I’ve seen this with things as “simple” as Bash string interpolation rules like ${var:+blah}. More often than not I’m humbled when I think I’ll learn it better and then find myself swearing at poorly-written documentation and patently false Q&A advice.
I think this deserves a short story!
Verified derp moment - had me smiling
I'm hoping this just isn't on the timeline.
> I'm the engineer who got PyPI to quarantine litellm.
In guessing they used a tool other than Claude Code to serve the email.
> 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.
There's a yellow note on the side of interaction #1 pointing it out, and it's made even more clear if you fully read interactions #5 and #6.
"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.
I'm really terse. If it asks me a yes or no question, I just type "Y" or "N".
If I want it to confirm something, I say "confirm it".
I think I treat it like a command system, and want it to be as short as possible.
[1]: https://en.wikipedia.org/wiki/XZ_Utils_backdoor
> While xz is commonly present in most Linux distributions, at the time of discovery the backdoored version had not yet been widely deployed to production systems, but was present in development versions of major distributions.
Ie if you weren’t running dev distros in prod, you probably weren’t exposed.
Honestly a lot of packaging is coming back around to “maybe we shouldn’t immediately use newly released stuff” by delaying their use of new versions. It starts to look an awful lot like apt/yum/dnf/etc.
I would wager in the near future we’ll have another revelation that having 10,000 dependencies is a bad thing because of supply chain attacks.
> I would wager in the near future we’ll have another revelation that having 10,000 dependencies is a bad thing because of supply chain attacks.
Yes, but this also has nothing to do with native vs. non-native.
And not changing often is a feature, yes.
(I don't know what a "sane" distro is; empirically lots of distros are bleeding-edge, so we need to think about these things regardless of value judgements.)
Do you think supply chain attacks will just get worse? I'm thinking that defensive measures will get better rapidly (especially after this hack)
I think the attacks will get worse and more frequent -- ML tools enable doing it easily among people who were previously not competent enough to pull it off but now can. There is no stomach for the proper defensive measures among the community for either python or javascript. Why am i so sure? This is not the first, second, third, or fourth time this has happened. Nothing changed.
But the data remains: no supply chain attacks on libc yet, so even if it COULD happen, this HAS and that merely COULD.
Thank you for your service, this brings so much context into view, it's great.
The bigger danger is malware writers adding sleep(7days). But if there is a wide variety of cool-down periods (3 days, 7 days, 30 days) this will not work very well.
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.
This article is an example of an AI agent taking 40 minutes to do some basic ass sysadmin troubleshooting tasks. 100x faster than who? An ”expert”?
How, exactly, are you calculating the worth of your code? Did you manage to sell in the same day? Why is it "worth $100k"?
If it took 90 minutes + a Claude Code subscription then the most anyone else is going to be willing to pay for the same code is... ~90 minutes of wages + a Claude Code subscription.
Ofc the person earning those wages will be more skilled than most, but unless those skills are incredibly rare & unique, it's unlikely 90 minutes of their time will be worth $100k.
And ofc, the market value of this code could be higher, even much higher, the the cost to produce it, but for this to be the case, there needs to be some sort of moat, some sort of reason another similarly skilled person cannot just use Claude to whip up something similar in their 90 minutes.
Don't use bogus $ from sloccount. Just say I created a 10k line project.