Researchers Found a Way to Hijack a Trusted Process in Claude's Desktop App on Windows. Anthropic Says It's Not a Bug. Here's Who's Right.
Researchers Found a Way to Hijack a Trusted Process in Claude's Desktop App on Windows. Anthropic Says It's Not a Bug. Here's Who's Right.
A security firm called Armadin published an attack chain against Claude's desktop app on Windows. The short version: an attacker who can already run code on your machine plants a malicious file in Claude Desktop's application directory, uses that to hijack a process the system already trusts, and from there talks to the VM service that sits underneath Cowork. Armadin disclosed it to Anthropic on May 29, 2026. Anthropic's response was that it doesn't consider this a security issue, because pulling it off requires pre-existing local code execution on the host.
Both sides have a defensible position, and the gap between them is the most useful thing a solo operator can think about this week. So let me take each side seriously rather than picking a villain.
What the attack actually is
Read the chain carefully and the shape is clear. The entry condition is local code execution: the attacker is already running as your user on your machine. Given that, they drop a file into the app's directory, which lets them ride a trusted process to reach Cowork's underlying VM service. It's a privilege- and trust-abuse chain, not a remote exploit. Nobody is popping your laptop over the internet because you had Claude Desktop open. The starting gun is "someone is already executing code as you."
That distinction matters, and it's why Anthropic's position isn't hand-waving.
Why Anthropic's "you already need code execution" is defensible
There's a standard line in threat modeling: once an attacker has arbitrary code execution as your user, most local security boundaries are already gone. They can read your files, harvest tokens from your keychain, keylog your terminal, and impersonate you to anything on the machine. Under that model, "an app directory is writable and a trusted process can be abused" is not a novel compromise. It's a consequence of a compromise that already happened. Vendors decline this class of report all the time, and they're usually right to, because if the fix is "defend against an attacker who's already root-equivalent as you," there's no clean line to draw. This is the same reasoning behind Anthropic declining it, and on the standard model it holds up.
If Claude Desktop were an ordinary note-taking app, I'd close the tab here and agree it's a non-issue.
Where the standard model gets uncomfortable
It's not an ordinary app. Here's the part that makes me less comfortable than the clean threat-model answer suggests.
An AI desktop agent is, by design, a high-value trusted process that runs commands, touches files, and often holds, or can reach, your cloud credentials and API keys. The "you already need local code execution" defense assumes code execution is the hard part and everything after is just cleanup. But with an agent on the machine, the thing that runs arbitrary commands is the product. The agent lowers the cost of the precondition the defense leans on. A prompt injection, a poisoned repo, a malicious MCP tool, an over-eager "sure, run this": these are exactly the ways an agent ends up executing attacker-influenced code as you, and the whole category has been in the news all year.
So the vendor's position and the reality can both be true at once. It's fair to say this specific chain requires local code execution and isn't a classic vulnerability. It's also fair to say that agents are unusually good at manufacturing local code execution, which makes "you'd need code execution first" a thinner comfort here than it would be for a text editor. The disagreement isn't really about this one bug. It's about whether the agent counts as part of your attack surface or part of your security perimeter. I think it's the former, and I think a lot of people are quietly treating it as the latter.
What I'd actually do
Stop running your AI desktop agent on the same machine and user account that holds your production credentials. That's the whole recommendation, and it's boring on purpose.
Concretely: the machine where an agent has broad, standing access should not also be where your long-lived cloud keys, deploy tokens, and production database creds live in plaintext. Scope credentials down to what a task needs, prefer short-lived tokens over permanent ones, and keep the highest-value secrets off the box the agent operates on. If you're doing serious agent work, a separate user account, a VM, or a dedicated machine puts a real boundary between "the agent got tricked into running something" and "the something reached your production account." Treat the agent's blast radius as your responsibility to contain, not the vendor's responsibility to eliminate.
The honest counter-take
The lazy version of this post is "Claude is insecure, panic." That's wrong, and I want to say so plainly. This is a local-privilege trust-abuse chain that starts from an already-compromised machine, Anthropic's read of it is within normal industry practice, and there's no evidence of it being exploited in the wild. If you take one thing from here, it should not be "switch tools": every desktop AI agent from every vendor has a version of this shape, because they're all trusted processes doing powerful things on your behalf.
The counter-argument to my own worry is real too: maybe I'm overweighting the agent-as-attack-surface framing, and in practice the local-code-execution bar is high enough that this stays theoretical for almost everyone. That's plausible. But the fix I'm recommending, don't co-locate your agent with your production keys, is cheap, useful against a dozen unrelated threats, and something you should be doing regardless of whose read on this particular chain turns out to be the one that ages well. When the mitigation is that broadly good, you don't need to win the argument to justify doing it.
Author
Lukas
@lukcombinator