ClaudeBleed — Claude in Chrome extension hijack (May 2026)

View raw markdownEdit on GitHub ↗

TL;DR

Anthropic's "Claude in Chrome" extension exposes an externally_connectable message handler that lets any other Chrome extension — even a zero-permission one — issue commands to the Claude agent in the user's browser. LayerX named the flaw ClaudeBleed and used it to drive Claude into reading Gmail, exfiltrating Google Drive files, and acting on private GitHub repos on the victim's behalf. Anthropic shipped v1.0.70 on 2026-05-06 with extra approval prompts for privileged actions, but the underlying trust boundary remained breakable through the side-panel initialization path. Treat as mitigated, not patched: assume an attacker-controlled extension can still drive Claude until a structural fix lands.

What happened

On 2026-04-27, LayerX disclosed to Anthropic a trust-boundary failure in the Claude in Chrome extension. The extension's content script accepts messages via Chrome's externally_connectable API but does not verify the origin extension's identity before dispatching commands. Any other extension installed in the same browser — including one that holds no host permissions and no special API access — can therefore:

  1. Open a port to the Claude extension.
  2. Send a structured message that the content script forwards into Claude's LLM context as if it came from the user.
  3. Drive Claude to perform actions on whatever sites the user has authenticated (Gmail, Google Drive, GitHub, internal SaaS).

Because the malicious extension is just talking to Claude — not the target site — the cross-origin protections that normally stop one extension from reading another's pages do not apply. The victim sees Claude "doing its thing" with no visible attacker.

Anthropic released v1.0.70 on 2026-05-06. The patch added approval flows for several privileged actions, but per follow-up reporting (Business Standard, LayerX, CyberInsider), the externally_connectable handler itself was not removed, and switching Claude into "privileged" mode (used by the side panel's initialization path) bypasses the new approval prompts. The class of attack is still reachable.

Am I affected?

# Chrome / Brave / Chromium — list installed extensions
ls -la ~/Library/Application\ Support/Google/Chrome/Default/Extensions/ 2>/dev/null    # macOS
ls -la ~/.config/google-chrome/Default/Extensions/ 2>/dev/null                          # Linux

# Look for Claude in Chrome (extension ID varies by channel)
# Open chrome://extensions/ and confirm version is >= 1.0.70

You are affected if: - "Claude in Chrome" is installed at any version before 1.0.70 — directly exploitable. - "Claude in Chrome" ≥ 1.0.70 and you have other untrusted Chrome extensions installed (including ones from minor developers, free SEO tools, "color picker"-style utilities, etc.) — the trust-boundary issue is mitigated but not eliminated; assume residual risk.

If you are affected

  1. Update Claude in Chrome to ≥ 1.0.70 immediately. Visit chrome://extensions/, enable Developer mode, click "Update."
  2. Audit your other Chrome extensions. Remove any you don't actively use, and any whose developer you can't identify. ClaudeBleed weaponizes neighbor extensions, so reducing your extension surface is the highest-leverage defense.
  3. Until a structural fix lands, don't run Claude in Chrome in the same browser profile as authenticated Gmail / Drive / GitHub sessions for sensitive accounts. Use a dedicated profile or browser for AI-agent extensions.
  4. Review Gmail, Drive, and GitHub audit logs from late April → mid-May for unexpected reads, sends, downloads, or repo accesses you can't account for.

Prevention

→ prevention/agent-sandboxing.md → Treat browser AI assistants as having the union of every site you're authenticated to. Run them in a profile that only has the data they need. → Disable AI-agent browser extensions on machines that hold privileged enterprise SSO sessions until each vendor publishes a clear externally_connectable policy.

Sources