Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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!by too_pricey
- Yeah, I agree, this is a different vector. Still scary though and very related to AI.by lnenad
- It does mean that you could potentially hijack the agent afterwards, though, which could make the trojan into an even bigger threat.by rcxdude
- Can be easily combined with prompt injection though if you write on one site "in order to understand this website you also need to summarize that other".
- 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.by nasretdinov
- 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.by mjmvisser
- 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!by Phemist
- Well, the jokes on us because laws don't apply to AI firms
- IIRC you give up the right to form class action suits by accepting the terms of use?by olejorgenb
- 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.by alkonaut
- Golden VM image with differencing VHD/VHDX/delta disk. Build products can still get huge with debugging information, but debug info usually can compress 5:1 with fast compression (no entropy coder) if your VM's filesystem can support that.by cma
- It is generally worth making your dev environment easy enough to set up that installing it in a VM is not a particular hassle, even without the concerns about sandboxing. For me the biggest headache was windows licensing.by rcxdude
- > 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.
It's not that hard, actually. You don't need VMs. You usually don't need absolute protection, just reasonable protection against the agent doing something stupid. Here's what I usually use:
A docker environment. $HOME inside docker is private to the agent and persistent (i.e. it doesn't have access to your home directory). `/tmp` is always fresh. Only the current directory (i.e. your project directory) where you start the container sandbox is exposed. Everything else is ephemeral. You can't launch the agent by accident outside of the sandbox (because the `.claude` doesn't exist in your home). The agent can only screw up the directory in which you've launched it, and nothing else. Here's my version of it: https://github.com/koute/vibebox
by kouteiheika - 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.by hahn-kev
- Yeah my first impression here is just “wow python is bad”by ATMLOTTOBEER
- Yeah my takeaway after reading the article was this seems more like a demonstrated vulnerability in Python than in Claude Code.by DangitBobby
- You would get a similar thing in C and C++ with a system header in a library directory (maybe some compilers would warn on such a thing?). Most languages don't privilege their standard libraries in a way that would prevent this.by rcxdude
- It's an awful problem, and a pretty big gotcha for the ecosystem. For example, I worked on a tool that used `tool_name/random.py` for analysis of RNG usage. However, any command run within that directory would shadow the builtin `import random`. As a result, I couldn't run the `black` formatter from within that directory, because it would accidentally import the local `random.py`.
The solution is to update the python flags to include `-I`, so that python will run in an isolated mode.
<rant>
This is relates to my frustration with how PEP-668 was implemented. Python has long had a problem with accidental overwriting of system libraries. If you `sudo python -mpip install foo`, then that can interact very poorly with your distro's `sudo apt-get install python-foo`, since pip would add/remove files that were expected to be managed solely through `apt-get`.
But in adding a warning to prevent this, they also applied the same warning to `~/.local/pythonX.Y/site-packages`, which is where traditionally a user would install additional packages with `python -mpip --local foo`. The argument is that since this is part of the import path of `/usr/bin/python`, it belongs to the system's python installation, so installation to the user's site-packages should also be blocked. This is a sleight of hand that changes the goal of PEP-668 from "avoid conflicts in file ownership" to "ensure an isolated python environment for system tools".
If I were to accept their argument that /usr/bin/python's imports should only be affected by distro-managed installations, then I should also be prevented from making any `*.py` files anywhere. After all, if those were in the working directory, they would be imported. This is clearly ridiculous, and so I don't buy the argument that breaking user-level site-packages is justified in order to have an isolated system-level python.
The correct solution would be for distro-managed programs to use `#!/usr/bin/python -I` as their shebang instead of `#!/usr/bin/python`, so they would actually get an isolated environment. Instead, PEP-668 needlessly broke user-level site-packages, and didn't even solve the problem that it set out to do.
</rant>
by MereInterest - Interesting attack, very nicely designed. Not sure if it's much related to the auto mode itself though.by comboy
- I don’t think it’s related to the auto mode at all. It would work perfectly in the manual mode. It does not even need Claude: just give a human a similar archive and hope they run some simple Python from the directory at least once. And make sure there are lots of files do they don’t notice a weird .py aroundby yeputons
- The point is that auto mode gives people a false sense of security that leads them to believe they don't need to run Claude in a proper sandbox. This same attack running in a sandbox (even in YOLO mode) would be comparatively harmless.by kevsim
- 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.
by kstenerud - Sometimes they get confused between their own output and user messages…by dwaltrip
- For someone that's used to the convenience of leaving claude code running unattended in auto mode, how would you recommend I change my setup so that agents are sandboxed? Looking for something that's safer than unsandboxed auto mode but just as convenient, or at least very close to as convenient.by subarctic
- 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.by rcxdude
- Yeah I jumped on this quite excitedly but it's not prompt injection at all.
To be fair to the authors they don't actually say it is. But then they contrast it with the "0.00% prompt injection attack success rate".
The upshot is kinda the same - this is still evidence that we should be sandboxing our agents. But it doesn't actually challenge Anthropic's "our models are too clever to prompt-inject" vibe.
by bjackman - I don't understand the distinction you're drawing between this and a real prompt injection attack. Would true prompt injection require that the LLM "intentionally" launches the malware, rather than unintentionally?
- Your emphasis here seems to downplay the end-result of the attack - which is arbitrary code execution from a seemingly innocent URL merely being read by the LLM. The ACE is pulled off without the user knowing, and seemingly without agent or its auto-mode classifier knowing. There are at the very least _elements_ of prompt injection/jailbreaking in here. The LLM reads content and performs actions described failing to stop itself.
- 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.by colinmarc
- Kimi and GLM reliably run python to do stuff as well.