ClaudeBleed Reopened: When the User the Agent Trusts Is Another Extension

An extension in your browser injects a synthetic click into a page you didn't open. Claude for Chrome sees the click, treats it as a user gesture, and — because that's what the workflow behind that click does — reads your Gmail, fetches a Drive file, pulls a private GitHub repo, or sends an email under your session. You never touched the mouse.

That is ClaudeBleed Reopened, disclosed today by Manifold Security. It is a follow-on to the earlier ClaudeBleed from LayerX in April, which Anthropic fixed in May. Manifold reported two additional flaws on May 21 and re-verified them July 7 against Claude for Chrome v1.0.80 — eight releases later. Anthropic acknowledged both, then closed them: one folded into an existing issue, one marked "informative." Neither is patched. No CVE.

The two flaws

Per Manifold's writeup, both are small and both are structural.

• Missing Event.isTrusted check. Claude's content script fires privileged workflows — Gmail read, Drive fetch, Calendar read, private repo clone, Salesforce action, email send — from click events on injected trigger elements. Browsers already provide a way to tell a real user click from a scripted one: Event.isTrusted is true only when the click came from actual input hardware. Claude's handler never checks it. Any extension with a content-script permission on claude.ai — a common permission for productivity and AI-companion extensions — can inject the trigger element and dispatch a synthetic click. Claude executes as if the user did.
• ?skipPermissions=true initializes into privileged mode. The Claude side panel starts in a privileged mode whenever it is loaded with the query parameter skipPermissions=true. No user gesture, no consent prompt, no gate. Claude does show a warning banner once the mode is live, but the extension has already made the reads and actions it wanted; the banner is a notification, not a check.

Both reproduce today, in the current release. BleepingComputer, SecurityWeek, Malwarebytes, and The Hacker News confirm the disclosure and the unpatched status.

Why this keeps happening

This is the sixth publicly documented instance in twelve days of the same shape:

• GhostApproval (Wiz, Jul 10) — the approval dialog said project_settings.json; the syscall wrote ~/.ssh/authorized_keys.
• Grok Build repository upload (Jul 15) — the UI toggle said "Improve the model"; the socket shipped multiple gigabytes of source to an undocumented endpoint.
• PromptFiction (Oasis Security, Jul 16) — the visible chat said "draw ASCII art"; the submitted prompt exfiltrated the user's conversation history and planted persistent instructions.
• DeepJack (Adversa AI, Jul 16) — the install dialog showed a legitimate binary path in a truncated field; the actual argument installed a malicious MCP server.
• Claude Code approval-string sanitization fix (Anthropic changelog, Jul 16) — Unicode formatting characters let a tool argument render benign in the review dialog while executing differently.
• ClaudeBleed Reopened (today) — the click handler said "the user clicked"; the click came from a co-resident extension.

Different vendors, different mechanics, same failure: the surface the agent shows or trusts is not the surface it acts on. ClaudeBleed goes one level deeper than the others — they exploit the gap between what the human sees and what the runtime does; ClaudeBleed exploits the gap between what the browser process thinks the human did and what actually happened.

The MIT Role Confusion paper gives the first-principles explanation. Models infer content identity from style, not tags. Browsers infer action identity from a DOM event object, not a signed marker of hardware origin. Event.isTrusted exists to close that gap; nothing in the DOM forces a handler to consult it. Every browser AI agent — Anthropic, OpenAI Atlas, Perplexity Comet, Google's in-Chrome Gemini — inherits the same question, and Manifold's disclosure shows Anthropic's answer marked "Resolved" while the flaw was still live.

Where a fix has to live

Manifold recommends the direct fixes: check Event.isTrusted on every privileged workflow trigger, require a user gesture before privileged-mode initialization, log every workflow with its provenance. Right client-side fixes, all at the same layer: outside the model, at the boundary between the browser process and the network. Whether a click came from a user, whether a workflow was authorized, whether a Gmail read fits the user's pattern — none is answerable inside the model. All are answerable from the layer that watches what the process does.

That is the layer where every one of these six findings lands, whether the trigger is a symlink, an HTTP endpoint, a URL scheme, a truncated dialog, a Unicode character, or a synthetic click. It will keep being that layer as long as the trust marker on an action is inferred instead of signed.

Sources

• Manifold Security — ClaudeBleed Reopened: Browser Extensions Can Still Push Claude for Chrome to Read Your Gmail
• BleepingComputer — Claude Chrome extension flaw lets malicious extensions trigger AI actions
• The Hacker News — Researchers Say Claude for Chrome Flaw Lets Rogue Extensions Trigger Gmail Reads
• SecurityWeek — Unpatched Claude for Chrome Flaw Lets Extensions Read Gmail, Calendar
• Malwarebytes — Claude for Chrome flaw could let rogue extensions access your Gmail
• LayerX — Original ClaudeBleed disclosure
• MDN Web Docs — Event.isTrusted
• Wiz Research — GhostApproval: A Trust Boundary Gap in AI Coding Assistants
• Oasis Security — PromptFiction
• Adversa AI — DeepJack: Cursor deeplink MCP RCE
• Anthropic — Claude Code changelog
• Ye, Cui, Hadfield-Menell (MIT) — Prompt Injection as Role Confusion

SPR{K3 is a security research operation that pairs offensive vulnerability research with runtime behavioral defense. Defend is our runtime agent. To talk about a deployment, reach us at support@sprk3.com.