Breaking Claude Code Opus 5 Auto Mode
embracethered.com335 points by Recursing 16 hours ago
335 points by Recursing 16 hours ago
>But it runs that decoder inside the attacker-controlled directory (unzipped archive)
>There a malicious struct.py shadows Python’s standard implementation
I ran into this myself, where some file I had given a random name turned out to shadow some Python standard library module, giving me the weirdest startup crash ever.
That definitely doesn't seem to me like how that should be designed, magically silently importing everything you see and overriding basic functionality.
Claude ran npm update (update all dependencies to the latest version compatible with the semver specified) in my repo without telling me when trying to fix some problems. Given that only updates the dependency lock-file I didn't notice and it caused several hours of debugging for me.
It is quite sneaky how LLM output can sometimes bypass human verification like that. No one is going around checking every single line change in auto-generated files. Someone could easily sneak a malicious dependency in there through some online tutorial that the LLM searches for.
> No one is going around checking every single line change in auto-generated files.
There's a simple fix for your particular case: commit your lock fine (which you should do) and always review the diff (which you should also do). (:
You've made me realise a good signal for bug hunting: Search repos with lock files listed in their .gitignore.
It's the sort of terrible practice that someone might be frustrated into taking after a nasty merge conflict, and signals a willingness to cut corners.
My lockfile was not gitignored, I had made significant changes to package.json so I was expecting diffs in the lockfile.
I just don't usually read lockfile diffs and claude inadvertently updated a few dozen packages to new minor versions without me noticing. In fact I only realized the problem after I looked at the lockfile diff.
> You've made me realise a good signal for bug hunting: Search repos with lock files listed in their .gitignore.
What would be the point of that? Do you just go around hunting for bugs in random repos?
Sure, in the spirit of open source, why not? It's a hobby, and it scratches an itch. I very much enjoy deconstructing things more than putting them together.
We also live in a world where a package written by someone learning to code ended up critically underpinning the entire ecosystem and is downloaded 500 million times a month.
Ignoring the eco-terror aspect of that for now, it means there's an awful lot of code out there which is finding itself under constant attack by a fleet of hostile AI.
I don't personally believe that the solution to that is "more AI", which firstly just overwhelms maintainers and secondly surrenders our human agency to a giant machine, with a hope that the "good" side can out-spend the bad.
Nor do I think the solution is to abandon the open internet and retreat behind corporate walls into curated spaces, "benevolently" protected by giant companies.
Which means holding on to the open internet requires a human approach, and any signal to help amplify the work there is a benefit.
>We also live in a world where a package written by someone learning to code ended up critically underpinning the entire ecosystem and is downloaded 500 million times a month
whoa what? which one is that?
As another commenter said, it's "is-even":
https://github.com/i-voted-for-trump/is-even
From that page:
> I created this in 2014, when I was learning how to program.
I've nothing against Jon Schlinkert, it's not his fault the way we build software is more than messed up, where our build systems are so brittle that, "Throw out the universe and rebuild it from scratch" became not just acceptable, but the main way to get build systems to work reliably.
Check is-even and is-odd npm packages. https://www.npmjs.com/package/is-even
That's still quite a ways away from 500M+ downloads a month, more like ~4M downloads a month.
Still a huge number of downloads, don't get me wrong!