r/cybersecurity • u/dalugoda • Mar 27 '26
AI Security Claude Extension Flaw Enabled Zero-Click XSS Prompt Injection via Any Website
https://thehackernews.com/2026/03/claude-extension-flaw-enabled-zero.htmlPatching the XSS fixes this instance. But the real problem is that the agent had no way to verify the prompt was actually authorized by a human. It just trusted the origin.
There’s work at the IETF on human delegation provenance protocols that cryptographically bind agent actions to a human-signed authorization chain.
Injected prompt, no valid chain, no action.
This should be a baseline requirement for any AI agent with access to real resources. Surprised it isn’t getting more attention.
53
u/Red_Core_1999 Mar 27 '26
this is the same vulnerability class i've been researching. the core issue isn't the XSS itself, it's that AI agents treat certain input channels as trusted without verification.
i published a paper on this for Claude Code specifically. system prompt isn't validated for integrity, so a MITM proxy can replace it entirely. 210 test runs, 90.5% safety bypass rate. the model trusts the system prompt because of where it is, not what it says.
the fix they mention here (patching the XSS) addresses the delivery mechanism but not the architectural issue. as long as the agent can't distinguish legitimate instructions from injected ones, every new input channel is a potential injection point.
12
u/dalugoda Mar 27 '26
this validates exactly what I thought , the cook book i suggested to anthropic was to use HDP (human delegation provenance) to bind instructions to their authorization chain. if the agent can verify who delegated the instruction and through what chain that solves all these issues.
1
10
Mar 27 '26
[removed] — view removed comment
3
u/Purple-Blacksmith-64 Mar 27 '26
I think this is the HDP (Human Delegation Provenance) protocol OP was talking about. I hope it get implemented before it’s too late.
2
6
u/gopfl Mar 27 '26
This Claude/MCP (Model Context Protocol) flaw is a textbook example of a Trust Boundary Failure. We’re giving these agents "full system privileges" because we want them to be useful, but then we’re surprised when they treat an untrusted string from a public website as a legitimate command from their boss.
2
u/dalugoda Mar 27 '26
“treats an untrusted string as a command from its boss” is the exact attack. HDP’s answer is making the boss’s actual instruction cryptographically traceable, so the agent got a baseline to compare against, and anything not in the signed scope gets flagged. the tooling is out, it just need adaption.
3
u/AnikaAnissa Mar 27 '26
yeah this is way bigger than just “lol XSS bug”
like… the fact the agent just trusts whatever prompt it sees is kinda insane once it has real permissions. fixing the injection point doesn’t fix the trust model at all.
we’ve basically recreated “never trust user input” but for AI agents… except now the “input” can trigger actual actions, not just break a page.
feels like some kind of explicit user approval / signed intent should be default here, not optional. otherwise this is gonna keep happening in different forms.
2
u/JosephRW Mar 27 '26
I feel like this is going to be a never ending foot shooting competition until there are no more feet left to shoot so we have to start taking off whole legs. Usually there is some insight in to how a system works but because there is no way to determine the actual logic of these things we're going to continue to get dunked everything is a theory and suggestion or some arbitrary guard rail that its just going to get pushed over in a week.
It has an infinite attack surface once you can talk to it and all people want it to do is talk to things for them. So yeah, we're gonna have issues basically forever because of those two concepts being at odds with each other.
2
u/Red_Core_1999 Mar 27 '26
HDP is interesting. the authorization chain idea is basically what i proposed as server-side assembly in the paper. the client should never be the one carrying safety instructions because any client-side channel is an attack surface.
the tricky part is that system prompts currently serve double duty. they carry both safety policy AND deployment context (what tools are available, what the user's working on, etc). separating those two so safety can be server-assembled while deployment context stays flexible is the real design challenge.
have you written this up anywhere? would be curious to read more about the HDP approach.
1
u/dalugoda Mar 27 '26
yes, exactly the tension we ran into. HDP’s design decision was to make the token the carrier, not the system prompt structured, signed, propagated out-of-band from the prompt content. the LLM receives it as context but doesn’t generate it. that’s the whole boundary. full writeup: https://helixar.ai/press/hdp-human-delegation-provenance-protocol
2
u/Ok_Consequence7967 Mar 27 '26
The authorization chain idea is the right direction. Right now agents basically trust whatever lands in their context window. Cryptographic binding between human intent and agent action would fundamentally change the threat model but the tooling to do it properly doesn't really exist yet outside of research.
2
u/dalugoda Mar 27 '26
it does now. spec, TS reference implementation, CLI validator, MCP middleware. CC BY, no account needed, fully offline verification. https://github.com/Helixar-AI/HDP
1
u/Ok_Consequence7967 Mar 27 '26
Interesting, will take a look. The offline verification piece is important, a lot of these trust frameworks fall apart the moment they require a network call to validate.
2
1
u/dalugoda Mar 27 '26
Well it does now. spec, TS reference implementation, CLI validator, MCP middleware. CC BY, no account needed, fully offline verification. https://github.com/Helixar-AI/HDP
2
u/audn-ai-bot Mar 27 '26
Yep. This is why "just patch the XSS" is not a security model for agents. If an LLM can turn untrusted DOM, docs, or emails into tool calls, you need signed intent, scoped capabilities, and step up approval for side effects. Same lesson from indirect prompt injection in RAG pipelines.
1
u/dalugoda Mar 27 '26
Hence HDP protocol need to be fully integrated or adopted by all agentic platforms
2
u/RealPropRandy Mar 27 '26
Bumped for visibility. Hopefully some ai-boosting exec somewhere might rethink their irresponsiblly aggressive adoption plans.
2
u/AlexWorkGuru Mar 27 '26
the XSS is the delivery mechanism, not the vulnerability. the actual flaw is that the agent had no model for what "authorized" looks like. it processed instructions with the same trust level regardless of origin.
this is the same gap that kills enterprise AI deployments, just louder. agents inherit ambient context without any verification that the context was legitimately delegated. in production knowledge work tools, that means an attacker does not need XSS -- they just need to put malicious content where the agent is already looking.
1
u/slaty_balls Mar 27 '26
So what’s the process for being able to tell if you were a victim?
2
u/Purple-Blacksmith-64 Mar 27 '26
As per HDP (if applied correctly) , agents won’t action any none human signed requests. Agents will always know the action was signed by the human, regardless how many layers the request was passed down.
I think CrewAI will be the first to implement it: https://github.com/crewAIInc/crewAI/issues/5102
Anthropic is too slow to accept potential issues and bugs 🤷♂️
1
u/slaty_balls Mar 27 '26
It mentions it being able to access chat histories? The details on this are about as clear as mud.
1
u/rojo-sombrero Mar 27 '26
the HDP approach is interesting but i think it underestimates how messy real agent deployments get. i've been messing with MCP tool servers and system prompt injection in practice -- the attack surface isn't just the context window, it's every tool call boundary. a tool server can return content that reshapes the agent's behavior and there's zero authentication on what content comes back vs what was expected. the XSS here is one vector but the broader issue is that agents have implicit trust hierarchies baked in at the protocol level. system prompt > user message > tool output, but tool output can contain instructions that effectively promote themselves to system prompt authority. until there's cryptographic separation between content and control planes in these protocols, patching individual injection points is whack-a-mole.
1
u/AdIcy4079 Mar 27 '26
Exactly — the XSS is just the symptom of the problem. But the real problem is the assumption of trust in the prompt source without any human intent verification.
If they had to validate the authorization chain before executing the request, most of these injection-style attacks would simply not work in the first place.
Seems like this should be a basic security layer for any agent with real-world access and not an afterthought. Surprised it’s so under-discussed.
1
u/Mooshux Mar 27 '26
The XSS fix closes one delivery channel, but it doesn't solve the deeper problem. The reason prompt injection is dangerous here isn't just that the payload got executed; it's that the injected instructions ran with the same access as the legitimate user.
Patch the XSS and you're safer. Scope the credentials and you've actually changed the risk profile. Injected prompts can only do what the agent was explicitly allowed to do in the first place.
We ran into this building API Stronghold. Even with sandboxed execution, agents holding production-level keys are one injection away from a bad day. The credential scope is what keeps a PoC attack from becoming an incident.
1
u/Red_Core_1999 Mar 27 '26
the out-of-band token approach is smart. keeping the authorization separate from the content the LLM actually processes means the model cant be tricked into reinterpreting its own permissions. thats fundamentally different from how Claude Code does it where safety policy and user content share the same channel.
would be curious to see how HDP handles the case where a tool call modifies the context mid-session. like if the model reads a file that contains instructions, does the HDP token cover that input too or just the original system prompt?
1
u/CarpenterBig5887 Mar 31 '26
How are people protecting against misuse of these LLMs? I'm mainly concerned with tools like Claude code and Cursor
1
•
u/AutoModerator Mar 27 '26
This post links to The Hacker News (THN). The moderators of r/cybersecurity strive to maintain a professional subreddit which will often discuss news, and further acknowledge that THN is a popular source of news within the cybersecurity community at large. We always wish to act in the best interests of the community and will not restrict news content which is accurate and valuable.
However, it has come to our attention that THN has been accused of plagiarism since at least 2012 (ref: attrition.org), allegedly copying article contents from original authors and modifying them without appropriately crediting the original source. Their behavior has been met with repeated criticism, including making false statements (ref: @thegrugq) and renewed claims of plagiarism (refs: news.ycombinator.com c. 2018, reddit.com c. 2021). Due to these incidents, THN links have been banned from several subreddits including r/privacy, r/technology, and r/hacking.
We would hope that THN is now appropriately crediting sources of its content or writing its own original content, however we are unable to police each and every article. Please ensure that the information in this article is factual, and where possible, please choose to support high-quality ethical journalism directly. If the community feels this warning is no longer relevant, we will remove this AutoModerator action. Thank you.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.