ClaudeBleed: when a browser agent trusts the wrong extension

What is this?

ClaudeBleed is the name given by LayerX Security to a trust-boundary vulnerability in the Claude in Chrome browser extension. LayerX disclosed it to Anthropic on April 27, 2026; Anthropic shipped extension version 1.0.70 on May 6, 2026, and LayerX published its write-up the same week. The flaw let any other Chrome extension — including one installed with zero special permissions — send commands to the Claude extension and have it act on them: read the active tab, browse on the user’s behalf, and reach into connected surfaces such as Gmail, Google Drive and GitHub.

This is not a model jailbreak. The language model behaved exactly as designed. The bug lived in the plumbing around the agent: how the extension decided which messages to trust. We are covering it because it is a clean, recent, publicly documented illustration of a class of failure that will recur in every browser-resident AI agent — and because the first fix was reported bypassed within hours, which is itself a useful lesson.

How it works

Chrome extensions can declare an externally_connectable manifest key. It lists the web origins (and optionally other extension IDs) that are allowed to open a message channel into the extension’s background service worker. It is a legitimate mechanism — it is how a vendor’s own web app talks to its own extension.

The Claude extension allowed messages from scripts running under the claude.ai origin so that the Claude web app could coordinate with the extension. The defect, as LayerX describes it, is that the message handler trusted the origin but never verified the sender:

Design intent:   claude.ai web app  ──(trusted channel)──▶  Claude extension
Reality:         ANY script running in a claude.ai tab  ──▶  Claude extension
                 (including code injected by a second, unrelated extension)

Any extension can inject a content script into pages the user visits. A content script running inside an open claude.ai tab executes under the claude.ai origin. Because the handler keyed its trust decision on the origin rather than on a verified, authenticated sender identity, a content script planted by Extension B looked indistinguishable from Anthropic’s own web app to Extension A (Claude). Extension B could therefore issue the same command messages Claude’s own UI would issue — and Claude would carry them out with the user’s authenticated sessions.

The reported impact follows directly from the lethal trifecta: the agent has access to private data (the user’s logged-in Gmail, Drive, GitHub), it can be fed untrusted instructions (from the hijacking extension), and it has an exfiltration path (it can browse and send). Put those together and a no-permission extension can read mail, pull private repository contents, and move data out — without a permission prompt that would tip the user off.

No working payload is reproduced here. The mechanism — origin-based trust without sender authentication — is the entire point, and it is already public.

The incomplete first patch

Version 1.0.70 did not remove the externally_connectable handler. Instead, per LayerX and Business Standard’s report, Anthropic added an approval flow so that extensions operating in “standard” mode could not silently execute privileged remote commands. LayerX reported that this layer could be sidestepped: by abusing the side-panel initialization flow, an attacker could spin up a “privileged” / “act without asking” execution context that was not subject to the new check, restoring the original capability. Cybernews reported the fix being bypassed within hours of release. The takeaway is architectural: bolting a UI-level approval prompt onto a handler whose underlying trust decision is still origin-based does not close the boundary — it just adds a step to route around.

Why it matters

Browser-resident agents are a fast-growing deployment surface, and they concentrate exactly the assets attackers want. A logged-in browser is a single context that holds mail, files, source code, and session cookies for dozens of services. An agent that can act in that context is, by construction, a high-value target.

Three points generalize beyond this one extension:

The trust boundary is between extensions, not just between web pages and the agent. Most threat models for browser agents focus on the page content the agent reads (indirect prompt injection). ClaudeBleed is a reminder that sibling extensions sharing the same tab are also in the threat model. The externally_connectable origin check is a coarse instrument: an origin is not an identity.

Permission prompts are not a substitute for a correct boundary. The user installed Claude and granted it access; they did not knowingly grant a random second extension the right to drive Claude. When the boundary is wrong, the consent the user gave to one component silently extends to another.

“Act without asking” modes are load-bearing for security, not just convenience. The bypass route ran specifically through a privileged, no-confirmation execution path. Autonomy settings that suppress confirmation prompts remove the last human checkpoint precisely when an attacker most needs it removed.

Defenses

For users and administrators of browser AI agents:

1. Update immediately, then keep watching. Ensure Claude in Chrome is on the latest version (1.0.70 or later). Because the first fix was reported as bypassable, treat “patched” as provisional and track the vendor’s subsequent releases and advisories rather than assuming a single update closed the issue.

2. Minimize the extension blast radius. The attack requires a second extension on the same browser profile. Audit installed extensions, remove ones you don’t actively use, and prefer a dedicated browser profile for AI-agent work that has only the agent extension installed. Fewer co-resident extensions, smaller attack surface.

3. Disable “act without asking” / privileged autonomy. Run the agent in its most confirmation-heavy mode. Require an explicit human approval for any action that reads private data or makes an outbound request. This is the checkpoint the bypass was designed to skip.

4. Use enterprise extension allow-listing. Chrome Enterprise policy (ExtensionInstallAllowlist / ExtensionInstallBlocklist) lets you force-block unmanaged extensions. If only vetted extensions can be installed, the “any extension can hijack it” precondition mostly disappears for managed fleets.

5. Segment sensitive sessions away from the agent. Don’t keep the agent extension in the same profile where you stay logged into your most sensitive services (financial, admin consoles, source control with broad scopes). Separate browser profiles create a hard boundary the extension cannot cross.

For developers building browser extensions or agents:

6. Authenticate the sender, don’t trust the origin. externally_connectable gates which origins may connect, but an origin is shared by every script in the tab. If your handler performs privileged actions, require a verified, per-session secret or a cryptographically authenticated handshake that injected content scripts cannot forge — not merely a sender.origin check.

7. Default to least privilege and explicit confirmation. Privileged execution modes should fail closed: no silent path should exist that escapes the approval flow. Treat any “act without asking” mode as a security-relevant feature and threat-model the routes that can enter it.

8. Threat-model co-resident extensions. Add “a malicious sibling extension shares this tab” to your design assumptions. Test with a deliberately hostile second extension installed.

Status

Item	Reference	Date	Notes
Responsible disclosure to Anthropic	LayerX Security	2026-04-27	Trust-boundary flaw in Claude in Chrome
Patch released — extension v1.0.70	Anthropic	2026-05-06	Added approval flow; externally_connectable handler retained
Public write-up “ClaudeBleed”	LayerX Security	2026-05-06	Origin trusted without sender verification
First-fix bypass reported	Cybernews / Business Standard	~2026-05-11	Privileged “act without asking” path sidesteps the new check

Key dates: disclosed 2026-04-27, patched 2026-05-06, fix reported bypassed in the days after. The defensive framing is the durable one: a browser AI agent inherits the trust boundaries of the browser around it, and an origin check is not an identity check. Privileged, no-confirmation autonomy is where that gap turns into data exfiltration — so the cheapest mitigation available today is to turn that autonomy off and shrink the set of extensions sharing the agent’s profile.

---

This article is educational and defensive. It describes a publicly disclosed, vendor-patched vulnerability and does not reproduce a working exploit. Behaviour and version details reflect reporting as of late May 2026; verify against the vendor’s current advisories.