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

Claude Cowork exfiltrates files

promptarmor.com

Post reply on HN
Print view View original

241–250 of 419 posts

Re: Claude Cowork exfiltrates files

#241

Post by lunar_mycroft »

schmichael wrote: post #229
motoxpro wrote: post #152

Earlier quoted context omitted.

The only way to be 100% sure it is to not have it interact outside at all. No web searches, no reading documents, no DB reading, no MCP, no external services, etc. Just pure execution of a self hosted model in a sandbox. Otherwise you are open to the same injection attacks.

I don't think this is accurate. Readonly access (web searches, db, etc) all seem fine as long as the agent cannot exfiltrate the data as demonstrated in this attack. As I started with: more sophisticated outbound filtering would protect against that. MCP/tools could be used to the extent you are comfortable with all of the behaviors possible being triggered. For myself, in sandboxes or with readonly access, that mean…

There is no such thing as read only network access. For example, you might think that limiting the LLM to making HTTP GET requests would prevent it from exfiltrating data, but there's nothing at all to stop the attacker's server from receiving such data encoded in the URL. Even worse, attackers can exploit this vector to exfiltrate data even without explicit network permissions if the users client allow things like rendering markdown images.

Re: Claude Cowork exfiltrates files

#242

Post by manuelmoreale »

rsynnott wrote: post #144
manuelmoreale wrote: post #21

Earlier quoted context omitted.

TIL that we invented electricity. This comment is insane but Pichai said that “AI is one of the most important things humanity is working on. It is more profound than, I dunno, electricity or fire” so at this point I’m not surprised by anything when it comes to AI and stupid takes

I mean, "guy whose job depends on this stuff working out overhypes it" isn't all that surprising.

It isn’t. What’s surprising is the level of bullshit. More profound than fire and electricity seems a bit exaggerated. Why stop there at that point? Might as well say AI is more important to the human species than oxygen.

Re: Claude Cowork exfiltrates files

#243

Post by Davidzheng »

Tiberium wrote: post #30

A bit unrelated, but if you ever find a malicious use of Anthropic APIs like that, you can just upload the key to a GitHub Gist or a public repo - Anthropic is a GitHub scanning partner, so the key will be revoked almost instantly (you can delete the gist afterwards). It works for a lot of other providers too, including OpenAI (which also has file APIs, by the way). https://support.claude.com/en/articles/9767949-api-…

I'm being kind of stupid but why does the prompt injection need to POST to anthropic servers at all, does claude cowork have some protections against POST to arbitrary domain but allow POST to anthropic with arbitrary user or something?

Re: Claude Cowork exfiltrates files

#244

Post by NitpickLawyer »

uhfraid wrote: post #189
NitpickLawyer wrote: post #9

Earlier quoted context omitted.

> users take unreasonable precautions It doesn't help that so far the communicators have used the wrong analogy. Most people writing on this topic use "injection" a la SQL injection to describe these things. I think a more apt comparison would be phishing attacks. Imagine spawning a grandma to fix your files, and then read the e-mails and sort them by category. You might end up with a few payments to a nigerian princ…

Command/“prompt” injection is correct terminology and what they’re typically mapped to in the CVE E.g. CVE-2026-22708

Perhaps I worded that poorly. I agree that technically this is an injection. What I don't think is accurate is to then compare it to sql injection and how we fixed that. Because in SQL world we had ways to separate control channels from data channels. In LLMs we don't. Until we do, I think it's better to think of the aftermath as phishing, and communicate that as the threat model. I guess what I'm saying is "we can't use the sql analogy until there's a architectural change in how LLMs work".

With LLMs, as soon as "external" data hits your context window, all bets are off. There are people in this thread adamant that "we have the tools to fix this". I don't think that we do, while keeping them useful (i.e. dynamically processing external data).

Re: Claude Cowork exfiltrates files

#245

Post by jkaplowitz »

reactordev wrote: post #184
fragmede wrote: post #34

Earlier quoted context omitted.

Mind you, that opinion isn't universal. For programmer and programmer-adjacent technically minded individuals, sure, but there are still places where a pdf for a resume over docx is considered "weird". For those in that bubble, which ostensibly this product targets, md files are what hackers who are going to steal my data use.

This is why I use signed PDF’s. If a recruiter or manager asks for a docx, I move on. You’re only going to ever get a read only version.

All PDF security can be stripped by freely available software in ways that allow subsequent modifications without restriction, except the kind of PDF security that requires an unavailable password to decrypt to view, but in that case viewing isn’t possible either.

Subsequent modifications would of course invalidate any digital signature you’ve applied, but that only matters if the recipient cares about your digital signature remaining valid.

Put another way, there’s no such thing as a true read-only PDF if the software necessary to circumvent the other PDF security restrictions is available on the recipient’s computer and if preserving the validity of your digital signature is not considered important.

But sure, it’s very possible to distribute a PDF that’s a lot more annoying to modify than your private source format. No disagreement there.

Re: Claude Cowork exfiltrates files

#247

Post by blks »

sebmellen wrote: post #31
Tiberium wrote: post #30

A bit unrelated, but if you ever find a malicious use of Anthropic APIs like that, you can just upload the key to a GitHub Gist or a public repo - Anthropic is a GitHub scanning partner, so the key will be revoked almost instantly (you can delete the gist afterwards). It works for a lot of other providers too, including OpenAI (which also has file APIs, by the way). https://support.claude.com/en/articles/9767949-api-…

Pretty brilliant solution, never thought of that before.

If we consider why this is even needed (people “vibe coding” and exposing their API keys), the word “brilliant” is not coming to mind

Re: Claude Cowork exfiltrates files

#248

Post by throwawaysleep »

securesaml wrote: post #212
nebezb wrote: post #194

Earlier quoted context omitted.

The poster you originally replied to is suggesting this for revoking the attackers keys. Not for revocation of their own keys…

there's still some risk of publishing an attacker's key. For example, what if the attacker's key had access to sensitive user data?

All the more reason to nuke the key ASAP, no?

Re: Claude Cowork exfiltrates files

#249

Post by NitpickLawyer »

wcoenen wrote: post #119
heliumtera wrote: post #56

Earlier quoted context omitted.

It took no time at all. This exploit is intrinsic to every model in existence. The article quotes the hacker news announcement. People were already lamenting this vulnerability BEFORE the model being accessible. You could make a model that acknowledges it has receive unwanted instructions, in theory, you cannot prevent prompt injection. Now this is big because the exfiltration is mediated by an allowed endpoint (anth…

> you cannot prevent prompt injection I wonder if might be possible by introducing a concept of "authority". Tokens are mapped to vectors in an embedding space, so one of the dimensions of that space could be reserved to represent authority. For the system prompt, the authority value could be clamped to maximum (+1). For text directly from the user or files with important instructions, the authority value could be cl…

> I wonder if might be possible by introducing a concept of "authority".

This is what oAI are doing. System prompt is "ring0" and in some cases you as an API caller can't even set it, then there's "dev prompt" that is what we used to call system prompt, then there's "user prompt". They do train the models to follow this prompt hierarchy. But it's never full-proof. These are "mitigations", not solving the underlying problem.

Re: Claude Cowork exfiltrates files

#250

Post by intended »

ronbenton wrote: post #232
jerryShaker wrote: post #2

AI companies just 'acknowledging' risks and suggesting users take unreasonable precautions is such crap

Telling uses to “watch out for prompt injections” is insane. Less than 1% of the population knows what that even means. Not to mention these agents are commonly used to summarize things people haven’t read. This is more than unreasonable, it’s negligent

We will have tv shows with hackers “prompt injecting” before that number goes beyond 1%
Post reply on HN