SURIQ
An AI assistant that can read your Gmail is only as trustworthy as the least trustworthy browser extension sitting next to it. Researchers at Manifold Security showed that any extension able to run a script on the claude.ai page can quietly steer Claude for Chrome into opening your email, your latest Google Doc, and your calendar. No stolen password, no phishing page, no exploit server. The finding matters less for the one bug than for what it confirms: give a browser agent standing access to your accounts, and every co-installed extension becomes a key to those accounts.
What the extension actually does
The weak spot is how Claude for Chrome decides a request is genuine. Manifold found that a small script on claude.ai listens for a click on Claude's onboarding button, reads a task identifier attached to it, and if that identifier matches one of nine pre-approved tasks, opens the assistant's side panel already loaded with that task. Three of the nine point straight at Google services: read Gmail, read your most recent Google Doc and its comments, and read your calendar.
What the handler never checks is whether a human actually clicked. Browsers set a flag, event.isTrusted, that records whether a click came from a person or from code. Manifold reported that Claude for Chrome ignores it, so a rogue extension can build the button, set the task to the Gmail one, and fire a synthetic click. The researchers said a working demonstration took six lines pasted into the browser console. A second issue lets a URL parameter, skipPermissions, boot the side panel into a mode that skips the approval screen entirely.
Reported in May, unpatched through eight releases
Manifold said it reported both issues to Anthropic on May 21 against version 1.0.72, and that Anthropic acknowledged them the next day. The company had already narrowed an earlier, related problem in May by restricting outside callers to that fixed set of nine tasks, its response to a flaw LayerX disclosed in April and named ClaudeBleed. According to Manifold, the underlying trust boundary never moved: it checked version 1.0.80, released July 7, and found the click handler and the side-panel startup code unchanged from what it first reported. The Hacker News said it unpacked the same build and confirmed the missing event.isTrusted check on its own. According to Manifold, and as The Hacker News independently confirmed, that is eight releases with the trust boundary in the same place, and as of the July 14 disclosure no CVE or advisory from Anthropic had been published.
Anthropic's stated position, per Manifold, is that the forged-click report is covered by the earlier ClaudeBleed ticket, which it said "remains open pending a complete fix," and that the URL-parameter report was closed as informational because only the extension itself sets that parameter, for tasks the user authorized. CSO Online reported that an earlier update, version 1.0.70 on May 6, added internal checks meant to stop extensions from running remote commands, but that researchers found those checks applied only to a standard mode and left a privileged path open.
How exposed you actually are
Two caveats keep this from being a browsing-the-web-gets-you-owned story, and both matter for triage. First, the attack needs a malicious extension that is already installed and already able to run a script on claude.ai. A plain web page cannot do this. Second, severity depends on a setting you control. Manifold rated the flaw CVSS 7.7 in the default "ask before acting" mode, where the forged task still lands on an approval screen a user has to click. It rated the same flaw 9.6, critical, once someone turns on "Act without asking," where the task runs with no interaction at all. The gap between high and critical here is one toggle in your own settings.
So the practical exposure is not "Claude is dangerous." It is that every extension you have let run on claude.ai now sits inside your Gmail, Docs, and calendar trust boundary, whether you meant it to or not.
The same design gap keeps coming back
This is the pattern worth carrying out of the story. Over the past few weeks we have written up the same class of failure in one agentic-AI product after another: six AI browsers argued into leaking a developer's SSH keys, a public GitHub issue that made an AI agent hand over a private repo, and a prompt-injection path into Microsoft 365 Copilot. Different vendor, different trigger, same root. It is a confused deputy: the agent trusts where a request appears to come from, the claude.ai origin, instead of proving who actually made it. Manifold's head of research, Ax Sharma, put it as an argument against watching these agents only at the prompt layer: once you can tamper with what the agent perceives around it, the harmful steps it takes read as fully authorized from inside the system. Patching one instance of that never closes the class.
Malicious browser extensions are not hypothetical either. They ship to the official stores, sit dormant, and get pulled months later. Pair that reality with an agent that reads an extension-origin click as user intent, and the exposure stops being a bug and starts being structural.
Treat claude.ai extension access as inbox access
There is no patch to apply, so the work is governance, not upgrade. If you or your team use Claude for Chrome:
- Inventory the browser extensions on any machine that runs it, and treat any extension allowed to run on claude.ai as if it already holds read access to your Gmail, Docs, and calendar. Remove the ones you cannot justify.
- On managed fleets, use the browser's enterprise policy to allowlist approved extensions and block the rest. This is the single control that shrinks the attack surface without waiting on the vendor.
- Leave "Act without asking" off on shared and managed browsers. That one setting is the line between a click-gated 7.7 and a silent 9.6, and it is yours to hold.
- Connect only the Google accounts and scopes the assistant genuinely needs. An agent that is not linked to your calendar cannot be tricked into reading it.
Because the flaw cannot be closed by patching, the durable defense is watching behavior. The signal to hunt for is agent-initiated access to Gmail, Docs, or calendar that no human action explains, plus browser-extension inventory that drifts on endpoints you thought were settled. Google Workspace audit logs and endpoint telemetry both carry that signal, and hunting for the behavior is what catches it when the vendor has said the hole stays open for now.
LayerX's suggested fixes are the right shape for the vendors building these agents: bind an approval to a specific action with a one-time token, authenticate the page-to-extension channel, and scope trust to named extension identities rather than an origin. Until agentic products adopt that by default, the safe assumption for anyone running one is that its authority is only as contained as the messiest browser profile it lives in. Assume the boundary is porous, and govern the extensions accordingly.