comments (10)

  • >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.

    andai

  • 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.

    colinmarc

  • 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.

    rcxdude

  • 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.

    kstenerud

  • Interesting attack, very nicely designed. Not sure if it's much related to the auto mode itself though.

    comboy

  • 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.

    hahn-kev

  • 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.

    mjmvisser

  • 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.

    alkonaut

  • 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!

    Phemist

  • 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?

    speby