Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code execution through email: How I used Claude to hack itself

pynt.io

Post reply on HN
Print view View original

41–50 of 73 posts

Re: Code execution through email: How I used Claude to hack itself

#41

Post by loa_in_ »

jcelerier wrote: post #37
stingraycharles wrote: post #13

Earlier quoted context omitted.

It’s not a great blog post. He attached a shell MCP server to Claude Desktop and is surprised that output / instructions from one MCP server can cause it to interact with the shell server. These types of vulnerabilities have been known for a long time, and the only way to deal with them is locking down the MCP server and/or manually approving requests (the default behavior)

> These types of vulnerabilities I don't understand why it's called a vuln. It's, like, the whole point of the system to be able to do this! It's how it's marketed!

People want to eat the cake and have it too.

Re: Code execution through email: How I used Claude to hack itself

#42

Post by timhh »

jcelerier wrote: post #37
stingraycharles wrote: post #13

Earlier quoted context omitted.

It’s not a great blog post. He attached a shell MCP server to Claude Desktop and is surprised that output / instructions from one MCP server can cause it to interact with the shell server. These types of vulnerabilities have been known for a long time, and the only way to deal with them is locking down the MCP server and/or manually approving requests (the default behavior)

> These types of vulnerabilities I don't understand why it's called a vuln. It's, like, the whole point of the system to be able to do this! It's how it's marketed!

Yeah I also don't understand how this is unexpected. You gave Claude the ability to run arbitrary commands. It did that. It might unexpectedly run dangerous commands even if you don't connect it to malicious emails.

Re: Code execution through email: How I used Claude to hack itself

#43

Post by pftburger »

Oh come on… if you’re running a shell executing MCP, then this is fair game. It’s like saying the PC is vulnerable because people leave their passwords on post it notes on the screen.

Ok wait, apple said that and then made better auth.

Nevermind, continue

Re: Code execution through email: How I used Claude to hack itself

#45

Post by neogodless »

simonw wrote: post #25

This exact combo has been my favorite hypothetical example of a lethal trifecta / prompt injection attack for a while: if someone emails my digital assistant / "agent" with instructions on tools it should execute, how confident are we that it won't execute those tools? The answer for the past 2.5 years - ever since we started wiring up tool calling to LLMs - has been "we can't guarantee they won't execute tools based…

~~Does MCP stand for "malicious code prompt"?~~

Ah finally in your last link there, I see it:

https://modelcontextprotocol.io/introduction

Model Context Protocol

Re: Code execution through email: How I used Claude to hack itself

#46

Post by rollcat »

simonw wrote: post #28
rollcat wrote: post #15

Language models and actors are powerful tools, but I'm kinda terrified with how irresponsibly are they being integrated. "Prompt injection" is way more scary than "SQL injection"; the latter will just f.up your database, exfiltrate user lists, etc so it's "just" a single disaster - you will rarely get RCE and pivot to an APT. This is thanks to strong isolation: we use dedicated DB servers, set up ACLs. Managed DBs li…

It's just YOLO. This problem remains almost entirely unsolved. The closest we've got to what I consider a credible solution is the recent CaMeL paper from DeepMind: https://arxiv.org/abs/2503.18813 - I published some notes on that here: https://simonwillison.net/2025/Apr/11/camel/

Interesting! So this is kinda like whole-program static analysis, but the "program" is like eBPF - no loops, no halting problem, etc. This is great for defence in depth (stops the agent from doing the wrong thing), but IMO the process still needs sandboxing (RCE).

I would love to see a cross-platform sandboxing API (to unify some subset of seccomp, AppCointainer, App Sandbox, pledge, capsicum, etc), perhaps just opportunistic/best-effort (fallback to allow on unsupported capability/platform combinations). We've seen this reinvented over and over again for isolated execution environments (Java, JS, browser extensions...), maybe this will finally trigger the push for something system-level, that any program can use.

Re: Code execution through email: How I used Claude to hack itself

#47

Post by simonw »

rollcat wrote: post #46
simonw wrote: post #28

Earlier quoted context omitted.

It's just YOLO. This problem remains almost entirely unsolved. The closest we've got to what I consider a credible solution is the recent CaMeL paper from DeepMind: https://arxiv.org/abs/2503.18813 - I published some notes on that here: https://simonwillison.net/2025/Apr/11/camel/

Interesting! So this is kinda like whole-program static analysis, but the "program" is like eBPF - no loops, no halting problem, etc. This is great for defence in depth (stops the agent from doing the wrong thing), but IMO the process still needs sandboxing (RCE). I would love to see a cross-platform sandboxing API (to unify some subset of seccomp, AppCointainer, App Sandbox, pledge, capsicum, etc), perhaps just oppo…

Yeah, the CaMeL approach is mainly about data flow analysis - making sure to track how any sources of potentially malicious instructions flow through the system. You need to add sandboxes to that as well - and the generated code from the CaMeL process needs to run in a sandbox.

Re: Code execution through email: How I used Claude to hack itself

#48

Post by klabb3 »

nelsonfigueroa wrote: post #11
sebtron wrote: post #10

> In traditional security, we think in terms of isolated components. In the AI era, context is everything. In traditional security, everyone knows that attaching a code runner to a source of untrusted input is a terrible idea. AI plays no role in this. > That’s exactly why we’re building MCP Security at Pynt, to help teams identify dangerous trust-capability combinations, and to mitigate the risks before they lead to…

I would say company blogs are basically just ads

Yes, it’s content marketing. But out of all the commercial garbage out there, the signal to noise ratio is quite high on avg imo. I find most articles like this somewhat interesting and sometimes even useful. Plus, they’re also free from paywalls and (often) cookie popups. It’s an ecosystem that can work well, as long as the authors maintain integrity: the topic/issue at hand vs the product they’re selling.

Unfortunately, LLMs (or a bad guy with an LLM, if you wish) will probably decimate this communication vector and reduce the SNR ratio soon. Can’t have nice things for too long, especially in a world where it takes less energy to generate the slop than for humans to smell it.

Re: Code execution through email: How I used Claude to hack itself

#49

Post by anonymousiam »

Back in the day, you could do similar things with a .forward file. I once wrote a script using a .forward file, "expect", "telnet", and "pppd" that would bring up a VPN into my company when I sent a crafted email to my work account.

The corporate IT folks had a pretty good firewall and dialup VPNs, but they also had a "gauntlet" BSD machine that one could use to directly access Internet hosts. So upon receiving the activation email, my script connected to the BSD proxy, then used telnet to reach my Internet host on a port with a ppp daemon listening, and then detached the console and connected it to a local (from the corporate perspective) ppp daemon. Both ppp daemons were configured to escape the non-eight-bit-clean characters in the telnet environment.

I used this for years, because the connection was much faster than the crummy dialup VPN.

I immediately dismantled it when my company issued updated IT policies which prohibited such things. (This was in the early 1990's.)

https://www.cs.ait.ac.th/~on/O/oreilly/tcpip/sendmail/ch25_0...

Re: Code execution through email: How I used Claude to hack itself

#50

Post by rafram »

franga2000 wrote: post #16

If you pipe your emails to bash, I can also run code by sending you an email. How is this news? You must never feed user input into a combined instruction and data stream. If the instructions and data can't be separated, that's a broken system and you need to limit its privileges to only the privileges of the user supplying the input.

> You must never feed user input into a combined instruction and data stream.

Well, I have some bad news about how LLMs work...

Post reply on HN