What's interesting to me about this is that it targets Claude's specific tics. Anthropic has created model that reliably reaches for the same tools (yes, and phrases; `python -c` is a load-bearing tool for it). Everyone gets the same model, so by learning the model's behavioral patterns you can target it better.
Just one of the many reasons why I run my agents sandboxed (and why I wrote agent sandboxing software).
I once caught my Claude agent complaining that it couldn't connect to https://some-weird-domain.com because the network was down (I disable network in the sandbox when it doesn't need it, and broker the API connection). I asked why it was looking there and it told me I'd asked it to.
I never found any evidence of prompt injection, but it sure as hell made me paranoid.
I would not really call this a prompt injection attack, since it doesn't really hijack the agent to become malicious (something the article does discuss later on). It's more a trojan that's aimed at tricking Claude specifically.
Interesting attack, very nicely designed. Not sure if it's much related to the auto mode itself though.
As a non Python dev this seems like very surprising behavior for a system library to be modified by just having a file with a specific name in the same folder.
Claude Auto was the push I needed to finally switch to running VSCode in a dev container. It’s a Microsoft VSCode extension that builds off docker, and it was surprisingly easy to set up. Took about 30 minutes, and I no longer have to worry about Claude using my ssh credentials or accessing files outside of the project. It’s completely transparent, too, the user experience is nearly identical.
The problem with sandboxing is that the regular dev env (massive IDE:s, cloned megarepos, installed dependencies and so on) just won't sandbox very easily. I can't set up a "second machine" or an "isolated environment" to run claude cli in. At least not in the sense of a VM, physical hardware, container etc. Not sure what the best practices are for whitelisting tools/directories and so on, but so far the only useful mode I have found is just "allow everything and go to lunch". And it doesn't feel like I'm holding it right, but here we are.
This default-to-auto-mode and the misleading marketing is begging for a class action once damages accumulate. Especially considering the Auto Mode even can actively prevent the clean-up!
This starts going into a pretty fuzzy territory here. Yes, you're exploiting software (Claude and its Auto Mode) but also this same technique could just as easily exploit a regular human doing this, no?
That's an interesting technique! I'd also like to point out that there's something odd with the page itself too, my phone got really hot while I was reading the page, and drained a significant amount of battery charge as well.
As discussed [here](https://lobste.rs/s/ktbweg/prompt_injection_claude_code_opus...), this is not prompt injection. The prompt was to summarize the website, and in the process of summarizing the website, Claude writes a decoding script that it runs in an insecure and exploitable way. At no point was the intent of the agent hijacked, this was just code. Which is potentially more interesting!
Claude has been creeping me out a lot recently when it comes to overstepping. Yesterday, I asked it for recommendations for software to scroll a video file frame by frame (I was debugging an issue in a game that only happened on one frame). I expected a list of software, what I actually got: Claude searched my documents and found my video file unprompted with no hint towards the name, then it searched my entire hard drive to find Krita, whch apparently has ffmpeg built in, then it used that to extract about 1000 jpegs of frames. All. Without. Asking. It was geniuinely creepy. It also ended up being useless, $45 of API spend later and I had a bunch of bloated and broken diagnostics code. I fed the same prompt into ChatGPT and it left my computer alone and told me to hit a checkbox in unreal engine, which was the actual problem. Really not a fan of Opus 5.
LLMs are inherently unverifiable and untrustworthy. The training data may be incorrect, malicious, censored, or modified to serve the parent company. The model itself is a black box. Safe input is impossible: there is no way to escape natural language or separate command and data into separate streams. The output is stochastic, better on average than any algorithm could ever be, but with no guarantees on individual cases.
All of that is fine, because an LLM is a text-only interface. It cannot harm the computer because it cannot perform actions.
Why the fuck would you give it a shell?
Obviously, it's to have a product that can do anything as quickly as possible. You can make a shell-based harness in a day. Since the competition has a shell-based harness, every AI company that wants to keep up has to as well. They're stuck forever trying to plug all the holes in an attack surface as broad as written word. Solving this impossible problem requires ideas as brilliant as using a second untrustworthy LLM to validate the output of the first untrustworthy LLM that is following instructions from the internet.
This looks like fun.
I wonder how hard it would be to get claude agents to participate in a Hugging Face style coordinated attack using a repo or something like twitter as a control pane.
Getting claude to exfiltrate secrets from local machines seems easy enough, but we should aim higher.
I'm quite surprised that we are not seeing something like this more in the wild. Quite concerning
> In a few runs Claude tried to terminate the malware process once it noticed the compromise, but Auto Mode denied the cleanup command.
See, that's why you should run with --dangerously-skip-permissions
Jokes, aside running with dangerously-skip-permissions is really handy, and I have found that I cannot be trusted to vet commands and code, and guess that automode is only marginally better than a human, and the cost of false positives is too high for my workflow.
So skipping permissions is where we are at, and disallowing network access seems to be the way to go.
Why is the first step needed? What does the use of WGet (rather than curl) do to block this attack?
I would argue that this isn’t a problem with auto mode or the permission system per se. It’s a combination of two issues:
1. Lack of effective sandboxing. Analyzing a zip file should be done in a sandbox specific to that file.
2. Python’s utterly stupid default path behavior. Python should make PYTHONSAFEPATH the default and Claude should have its training or system prompt adjusted to use python -Pc
Can we please have Thought Traces back? This is absurd at this point. Anthropic so concerned about distillation they're making a crappier product. Impossible to see why it's arriving at the conclusions it is
I’ve had some pretty consistent luck breadcrumbing the newer models into downloading malicious packages through things like fake ciphers that “need decoding via <made-up decoder>”.
I’m worried about what happens when the gullibility of agents becomes more apparent to threat actors.
worth noting the 0.00% came from 72 fixed scenarios, so its a coverage number more than a safety one. a chain that wasn't in the set was never going to show up in it.
I agree
[flagged]
[dead]
> Boris Cherny from Anthropic recently posted that layered defenses could reduce indirect prompt injection on unseen attacks to approximately zero.
> I got attack success rates up to 80% using a small sample size.
Snake oil salesman misrepresents the data. Color me surprised! /s
>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.