Claude for Chrome: a synthetic click still triggers Gmail reads

What is this?

On July 14, 2026, Ax Sharma of Manifold Security published ClaudeBleed Reopened, showing that two weaknesses in Anthropic’s Claude for Chrome browser extension remained reproducible in the then-latest build, v1.0.80 (released July 7). The firm reported both to Anthropic on May 21, 2026 against v1.0.72; Anthropic acknowledged the reports the next day and later closed them, but according to Manifold the specific handlers are byte-identical eight releases later.

The finding is the sequel to the ClaudeBleed trust-boundary flaw that LayerX disclosed in early May. Anthropic’s mitigation for that earlier issue is the reason this one is interesting: the fix was real, but it was placed at the wrong layer, and a residual gap survives it.

How it works

To close the original flaw — where a page could feed Claude arbitrary text — Anthropic restricted external callers to a small dictionary of nine hard-coded prompts identified by task ID. Three are onboarding practice prompts; the other six are live actions, including usecase-gmail (read recent mail and click unsubscribe links), usecase-gdocs (open the latest doc and read its comments), and usecase-calendar (read availability and create meetings). A page can no longer inject its own text — a genuine improvement at the message-handler layer.

The residual problem is how one of those nine prompts gets triggered. A content script listens for clicks on an element matching a specific onboarding-button selector, reads its task-ID attribute, and forwards the matching prompt to Claude’s side panel. Crucially, the handler never checks event.isTrusted — the browser flag that distinguishes a real user click from one synthesized in script. Any extension that runs a content script in the main world on claude.ai (the standard model for browser extensions) can build the button, set the task ID, and dispatch a synthetic click. Manifold’s proof of concept is a handful of console lines, with isTrusted: false in the logs confirming the forged event was honored.

In the default “Ask before acting” mode an approval modal still stands between the forged trigger and any sensitive read, so the practical impact is a coerced-approval nuisance — Manifold rates this 7.7 (High). But once a user has enabled “Act without asking,” the modal disappears and the task runs silently; Manifold rates that path 9.6 (Critical). The bug is model-independent — it reproduced across the Opus, Sonnet and Fable side-panel selections — because it lives in the extension, not the model.

The second finding is architectural: the side panel enters privileged mode whenever it is loaded with a skipPermissions=true URL parameter, with no user gesture and only an after-the-fact “high risk” banner. That URL is normally constructed only by the extension itself, so it is not directly remotely exploitable today. It is a latent amplifier: any future bug that lets a lower-privileged context influence side-panel URL construction would turn the synthetic-click trigger into silent, critical-impact execution.

Why it matters

A browser AI agent authorized to read your inbox is a high-value identity. This class of bug maps cleanly to the OWASP Top 10 for LLM Applications: LLM01 indirect prompt injection (the trigger comes from untrusted page-side script, not the user) and LLM06 excessive agency (the agent can reach Gmail, Docs and Calendar with a single event). It is also nearly invisible to conventional monitoring: a gateway sees ordinary authenticated HTTPS to claude.ai, and EDR sees a browser extension running normally. The only reliable signal is what the agent actually does at runtime versus what it was authorized to do. The broader lesson generalizes past this one product: an allowlist that constrains which messages are accepted is not an authorization boundary if the event that fires it accepts forged input. Trust has to be enforced at every layer, not just the one that is easiest to see.

Defenses

Verify user intent at the point of action. The single-line fix Manifold proposes is to reject synthesized events at the top of the click handler (conceptually, if (!event.isTrusted) return;). Any agent that gates a privileged action on a UI click must confirm the click was user-generated, not script-dispatched.

Boot agents in the least-privileged mode. Do not let a URL parameter or query string select a “skip all permission checks” state. Require permission-mode transitions to come from a real user gesture in the agent’s own UI, and gate any internal privileged request on a sender-ID check.

Treat browser AI agents as privileged service accounts. Inventory extensions that can reach mail, documents and calendars; disable “act without asking” for anything touching sensitive data; and minimize the other extensions installed alongside an agent, since any one of them is a potential trigger.

Monitor agent behavior at runtime. Because access-control logs look normal, the durable detection layer is behavioral: flag when an agent invokes a tool or task it was not plausibly asked to invoke.

Patch and track. Follow the Claude for Chrome release notes and Manifold’s advisory, and re-test after each update rather than trusting a “resolved” status.

Status

Item	Detail
Disclosed by	Ax Sharma, Manifold Security — July 14, 2026
Reported to vendor	May 21, 2026 (against v1.0.72); reports acknowledged, later closed
Reproduced in	v1.0.80 (released July 7, 2026)
Severity (researcher)	7.7 High (default “ask” mode) / 9.6 Critical (“act without asking”)
Mapping	OWASP LLM01 (indirect prompt injection), LLM06 (excessive agency)
Scope	Model-independent (Opus, Sonnet, Fable side-panel selections)
Vendor response	No public comment on the specific findings as of July 14, 2026