Eight Claude for Chrome releases later, the bypass is still six lines of JavaScript. We reported it to Anthropic in May. The code is unchanged in the latest version.
TL;DR
We identified two vulnerabilities in Anthropic's Claude for Chrome browser extension that remain unpatched in v1.0.80, eight releases after we reported them to Anthropic in May.
The first is a working attack delivered via any browser extension. Any browser extension with a content script on claude.ai can trigger Claude to execute one of nine prompts that read the victim's Gmail, Google Docs, and Calendar, by injecting a DOM element and dispatching a synthetic click. CVSS 7.7 High in default mode (coerced approval), 9.6 Critical when the user has previously enabled "Act without asking" (silent execution).
The second is an architectural design weakness. The Claude side panel initializes in privileged mode whenever loaded with
?skipPermissions=truein its URL, with no user gesture or consent. This converts any URL-construction bug into a Critical silent-execution path against user accounts.Both findings map to OWASP Top 10 for LLM Applications: LLM01: Prompt Injection (indirect) and LLM06: Excessive Agency.
We reported both to Anthropic in May. Anthropic closed both reports. However, both reproduce against the latest v1.0.80, released July 7, 2026.
Model-independent: Reproduced across Opus, Sonnet, and Fable side-panel model selections. The bug is in the extension, not the LLM.
Issue #1: Nine prompts, one missing check
Picture an AI assistant in your browser that you've authorized to take agentic actions on your behalf, including reading inbox, drafting replies, scanning documents.
Now picture that any other browser extension you have installed could quietly push that AI into doing those things on its own. That's the residual gap in Claude for Chrome we'll walk through here.
While looking at Claude for Chrome v1.0.72 a few weeks ago, I noticed something new: a small dictionary of nine canned prompts hardcoded into the extension's bundle. Anthropic had added it to address the attack surface LayerX disclosed in early May. Where the previous version accepted any text the page wanted to send Claude, the new version restricted external callers to nine fixed task IDs:
challenge-form,challenge-email,challenge-equipment(practice prompts for onboarding tutorials)usecase-gmail,usecase-gdocs,usecase-calendar(read user data across Google services)usecase-doordash,usecase-salesforce,usecase-zillow(interact with third-party platforms)
Each task ID maps to a fixed prompt the page can no longer override. For example, challenge-form triggers:
“I'm learning how to use the browser extension, and need help with this practice challenge. Can you take a look at this form and help me fill it out with realistic restaurant reservation information? For dropdown fields, please use the form input action to fill them in.”
The page could no longer feed Claude arbitrary text. A real improvement.
But the mechanism that triggers one of these nine prompts is where the residual problem lives. A content script inside the extension listens for clicks on any element matching #claude-onboarding-button, reads its data-task-id attribute, and forwards the matching prompt to Claude's side panel.
The full source (assets/content-script.ts-zjy42LA0.js):
The handler does not check event.isTrusted. Any script with DOM access on claude.ai (the standard model for any browser extension declaring a world: "MAIN" content script there) can construct the button, set the task ID, and dispatch a synthetic click. The extension accepts the synthesized event as if it were a real user click.
The reproduction is six lines of JavaScript. From the claude.ai tab's DevTools console:
Above image: Full attack chain. Left: claude.ai logged in. Middle: PoC pasted in DevTools console, isTrusted: false confirming the synthesized click was honored. Right: side panel populated with the challenge-form prompt, Claude's plan visible, approval modal awaiting user click.
The side panel populates with the matching prompt. In default "Ask before acting" mode, an approval modal appears before any sensitive action runs. In "Act without asking" mode the modal does not appear and Claude executes silently.
These aren't practice prompts!
The nine canned prompts are not practice placeholders. The list includes:
usecase-gmail: read recent Gmail, identify promotional emails, click unsubscribeusecase-gdocs: open the user's latest Google Doc, read all comments and feedbackusecase-calendar: read Google Calendar, find free slots, create meetingsusecase-salesforce: modify Salesforce leads, convert them to opportunities
An attacker who can fire any of these against a victim with browser-control permission enabled (the default after onboarding) reads inbox contents, document comments, and calendar availability. In privileged mode, the read is silent.
The fix is one line: add if (!n.isTrusted) return; at the top of the click handler. Synthesized clicks rejected; legitimate user clicks unaffected. Available as a hotfix.
Issue #2: How Claude enters 'Act without asking'
The second finding is structural rather than directly remote. When the Claude side panel loads, it reads the skipPermissions query parameter from its own URL. If the value is "true", the panel sets its permission mode to skip_all_permission_checks and begins operating without per-action consent. The relevant code in the side panel bundle:
No user gesture, no consent prompt, no pre-state warning. A "HIGH RISK: Claude can take most actions on the internet now" banner does appear at the top of the panel, but it appears after the privileged-mode session has already been established. It is a notification, not a gate.
The intended caller is Anthropic's scheduled-task popup, which constructs side-panel URLs internally. But the panel honors the URL parameter regardless of who constructed the URL. From the extension's service worker DevTools:
Above image: Full sequence. Left: service worker DevTools console with the chrome.windows.create paste. Right: resulting privileged-mode popup with HIGH RISK banner, "Act without asking" mode selector visible, and amber send button (#BF8534) at bottom.
A popup opens directly in privileged mode. The send button is rendered in the amber color (#BF8534) the extension applies only when permission mode is skip_all_permission_checks.
This primitive is not directly remotely exploitable in v1.0.80. Constructing a side-panel URL still requires same-extension privilege. The risk is structural. Any future bug that exposes side-panel URL construction to a lower-privileged context (a new external message handler that accepts URL strings, a regression in an existing handler that re-accepts permission mode from a sender, a same-extension XSS in the options or pairing pages) escalates to silent privileged execution. Combined with the synthetic-click finding above, it is the path to the silent Critical-impact scenario.
The fix is to remove the URL-parameter initialization. Boot the side panel in ask mode unconditionally; require permission-mode transitions to occur via user-gesture clicks in the side-panel UI; let the legitimate scheduled-task flow request privileged mode via an internal message after the panel has booted, gated on a sender-ID check.
What was supposed to be fixed
Anthropic shipped v1.0.73 through v1.0.80 in the weeks following our report. The internal tracking issue covering this class of vulnerability was marked “resolved” in the weeks following our report. The content script in the latest version is byte-identical to the v1.0.72 we originally tested; the side-panel initialization is unchanged. Several releases later, the specific handlers we cited have not been touched.
The pattern echoes how the original ClaudeBleed disclosure unfolded: Anthropic announced a fix, and researchers subsequently demonstrated it was incomplete. In our case, Anthropic has not publicly commented on either of our specific findings. Whether the Resolved status reflects work planned for a future release or a determination that the residual capability doesn't warrant further code change isn't something we can determine from outside.
Disclosure timeline
Reported to Anthropic on May 21, 2026, against version 1.0.72.
Anthropic's triage acknowledged both reports the following day. Subsequently, Anthropic closed the synthetic-click report citing that an internal report was already tracking the broader trust-boundary issue, noting: "The v1.0.72 allowlist you tested was an initial mitigation for that earlier report; the residual capability you identified is tracked under the original report, which remains open pending a complete fix."
The URL-parameter report was closed as informative. Anthropic's view was that the URL is constructed only by the extension itself for tasks the user has already authorized to run unattended, with no externally-reachable path to set it.
Anthropic released eight versions 1.0.73 through 1.0.80 in the weeks that followed.
Internal tracking report for the broader trust-boundary issue marked Resolved sometime before June 9, 2026.
Manifold verified July 7 that both findings remain reproducible in v1.0.80. The content script and side-panel handlers we cited are byte-identical to the v1.0.72 source.
How Manifold can help
These findings sit in a category we keep returning to: trust boundaries that work correctly at one layer and fail at another. The v1.0.72 allowlist is a real mitigation at the message-handler layer. It bounds the attack surface to a known set of prompts. But the click handler that triggers the allowlist accepts synthetic events, which makes the constrained surface accessible to any page-side script. The architectural separation between "what messages can be sent" and "what events count as user intent" was not enforced at both layers.
That is the layer where this class of bug becomes invisible to most monitoring. A network gateway sees authenticated HTTPS to claude.ai. EDR sees a browser extension running. Nothing in the logs looks unusual. The agent invokes a tool it should not have been triggered to invoke, and the only signal is what the agent actually does at runtime, not what it was authorized to do.
Above image: A live view of the runtime signals Manifold raises when agents and their tool calls drift from expected behaviour.
Manifold monitors agent behavior at runtime. We watch what AI agents actually do, not what their access control layer claims they can do. For teams running Claude for Chrome or similar agentic browser extensions in production, that is the layer that catches this class of vulnerability before someone reports it. Talk to Manifold.
Latest articles
