Claude for Chrome Still Has an Unpatched Extension Hijack Bug, Eight Versions On

Anthropic's Claude for Chrome extension has a security problem it acknowledged two months ago and still hasn't fixed. Any browser extension with permission to run scripts on claude.ai can forge a click event, trigger one of the extension's built-in tasks, and point Claude at your Gmail, Google Docs, or Calendar. No special access required beyond what a moderately permissive extension already has.

Researchers at Manifold Security reported this in May against version 1.0.72. Anthropic acknowledged it the next day. Eight releases later, Manifold checked v1.0.80 on July 7 and found the vulnerable code unchanged. The Hacker News independently pulled the same version from the Chrome Web Store and confirmed it: no isTrusted guard, no fix.

How it actually works

After the earlier ClaudeBleed disclosure, Anthropic did tighten things up. The extension no longer accepts arbitrary prompts from the page. Instead, external callers are limited to nine fixed task IDs hardcoded into the extension bundle: three are onboarding demos, three drive integrations for DoorDash, Salesforce, and Zillow, and three read your Gmail, your most recent Google Doc with comments, and your Calendar.

The allowlist was a sensible move. The problem is what fires those tasks.

A content script in the extension listens for clicks on a specific DOM element (#claude-onboarding-button) on claude.ai. When it sees a click carrying a valid task ID, it sends a message to open the side panel with the corresponding prompt loaded. What it never checks is event.isTrusted, the standard browser property that distinguishes a genuine user click from one dispatched by a script.

That means any extension whose content script can touch the DOM on claude.ai can create the element, attach a task ID, and fire a synthetic click. The handler treats it as real. Manifold demonstrated this with six lines of console code, with isTrusted: false sitting right there in the logs.

In the default 'ask before acting' mode, you still see an approval prompt before anything reads your data, so there's a speed bump. Manifold rates that scenario CVSS 7.7 High. If you've switched on 'Act without asking', the task runs silently with no confirmation at all. That's a 9.6 Critical. The one-line fix, checking isTrusted at the top of the handler, has not shipped.

The second issue, quieter but nastier in theory

There's a second flaw sitting underneath the first. When the extension's side panel loads with ?skipPermissions=true in its URL, it boots directly into a mode that skips all permission checks and starts acting without asking. A red banner does appear to warn you, but it shows up after the privileged session is already running. It's a notification, not a gate.

Right now, only the extension itself can construct that URL, so there's no direct remote path. But if a future bug exposed a lower-privileged context to that parameter, via a URL-handling regression, a message handler that accepts untrusted input, or an XSS in the options page, the forged-click trick would become a fully silent account read with no approval box at all. Manifold's recommended fix is straightforward: stop reading the permission mode from the URL and always boot in ask mode.

Anthropic closed both reports

When Manifold reported the click handler flaw, Anthropic closed the ticket on the basis that the trust boundary issue was already being tracked under the original ClaudeBleed report, which Anthropic said 'remains open pending a complete fix.' The URL parameter report was closed as informative, with the reasoning that the parameter is only ever set by the extension for tasks the user has already authorised.

But the ClaudeBleed parent ticket was marked resolved before June 9. And the code hasn't moved. Two months, eight releases, same vulnerable handler.

There is no CVE for either issue as of July 14, and no public advisory from Anthropic.

The bigger pattern

This isn't a one-off. A separate flaw patched earlier this year let any website silently inject prompts into the extension. ClaudeBleed itself started when LayerX found the extension trusted the claude.ai origin wholesale without checking which script was actually communicating with it. Claude Code has shown a parallel failure mode where a hostile repository could exfiltrate a developer's Anthropic API keys.

Manifold maps the forged-click issue to OWASP's LLM Top 10 as indirect prompt injection and flags the silent-execution risk as excessive agency. The bug is in the extension architecture, not the model.

The structural problem is straightforward to state. Put an AI agent in the browser with accounts already signed in, accept synthetic clicks as user intent, and let permission state be controlled from a URL, and you've built something that other extensions on the same page can drive.

Claude for Chrome is beta software, available to all paid Claude subscribers. If you're running it alongside any extension that has read or write access to claude.ai, you're in scope. Turning off 'Act without asking' restores the approval step. It doesn't close the forged-click path.