This blog spends most of its time making the case that Claude Code’s terminal-native, agentic architecture is the right model for serious software development. That case is stronger, not weaker, when the same scrutiny gets applied to Anthropic’s own products when they fall short. This is one of those times.
Two bugs, same name, worth telling apart#
“ClaudeBleed” has been used loosely enough in coverage that it’s worth being precise before going further, because it actually names two distinct findings from two different research firms, four months apart.
The original ClaudeBleed came from LayerX Security in April 2026: an externally_connectable origin-trust failure where any script running on claude.ai — not necessarily Anthropic’s own code — could message the Claude for Chrome extension without the extension verifying who was actually talking to it. Anthropic shipped a fix in version 1.0.70 within about a week, described by researchers at the time as partial rather than complete.
The bug this article is actually about is a second, separate one: a synthetic-click bypass reported by Manifold Security, whose July 14 disclosure post is titled “ClaudeBleed Reopened” — a deliberate callback to LayerX’s name, meant to say the underlying trust-boundary problem never fully closed, even though the specific mechanism is different. That framing is fair, but it also means anyone citing “ClaudeBleed” needs to be clear about which chapter they mean. This piece is about Manifold’s finding, reported May 21, 2026, disclosed publicly July 14, and — as of this writing — still open.
The bug itself#
Manifold’s own writeup, fetched directly from manifold.security, names the exact defect: a content script inside the extension listens for clicks on any element matching #claude-onboarding-button, and the handler never checks event.isTrusted — the standard browser API that distinguishes a real human mouse click from one synthesized by JavaScript. Any other extension with script access on claude.ai can fire a fake click using, in Manifold’s words, six lines of JavaScript, and Claude for Chrome treats it as genuine user approval.
That approval isn’t cosmetic. It unlocks one of nine hardcoded task IDs baked into the extension, including usecase-gmail (read and unsubscribe from email), usecase-gdocs (read document comments), usecase-calendar (find free time and create meetings), and usecase-salesforce (modify CRM leads). A rogue extension sitting alongside Claude for Chrome in the same browser doesn’t need to compromise Anthropic’s code at all — it just needs to fake one click, and Claude does the rest with whatever access the user already granted it.
Manifold rated the bug CVSS 7.7 High in the extension’s default mode, rising to 9.6 Critical if the user has enabled “Act without asking” — the unattended-operation setting that lets Claude execute tasks without a confirmation prompt at all. The same report flags a second, related bug: the extension’s side panel reads a skipPermissions URL query parameter, and setting it to true silently drops the session into skip_all_permission_checks mode with no user gesture required.
Reported in May, still broken in August#
The timeline is the part that should actually bother a security-conscious reader. Manifold reported both issues to Anthropic on May 21, 2026, against extension version 1.0.72. Anthropic acknowledged the reports the next day — that acknowledgment is real, but it comes to us only through Manifold’s account of the private triage exchange, not a public Anthropic statement, so it’s worth flagging as secondary-sourced even though it’s not in dispute. According to that account, Anthropic closed the synthetic-click report by folding it into an existing internal ticket already tracking “the broader trust-boundary issue” from the original LayerX finding, and closed the skipPermissions report as informational, reasoning that the parameter is only ever set by the extension itself for tasks a user already approved for unattended execution.
Between the report and Manifold’s public disclosure, Anthropic shipped eight point releases of the extension — 1.0.73 through 1.0.80. Manifold retested on July 7 and found both bugs fully reproducible in 1.0.80; The Hacker News independently confirmed the relevant handler was “byte identical” to the version originally reported in May. As of this writing, roughly a month after that retest and three months after the original report, this blog found no evidence of a patched version, no CVE or GHSA advisory number attached to either finding, and no public Anthropic blog post, changelog entry, or statement addressing the bug by name. SecurityWeek’s July 14 coverage notes it reached out to Anthropic for comment; the available record doesn’t show one being given.
To be fair to Anthropic’s side of the ledger: this isn’t a hard bug to fix. Manifold’s own assessment is that a single event.isTrusted check on the existing click handler would close the primary vector. That it’s still sitting open after eight shipped releases — releases that presumably touched other parts of the same extension — is the detail that’s hard to read charitably.
Why the terminal-CLI/browser-extension distinction actually matters here#
It’s worth being explicit about scope, because it’s easy to let a headline like this bleed (no pun intended) into a broader “Claude is insecure” takeaway that the facts don’t support. Every source on this bug — Manifold’s own report, BleepingComputer’s coverage, the rest of the secondary press — scopes it specifically to the Claude for Chrome browser extension. BleepingComputer states it plainly: “this vulnerability affects only the Chrome browser extension, not the Claude Code CLI or other Claude implementations.” Nothing in the public record suggests or even raises the possibility that Claude Code, the terminal-native agent this blog covers most, shares this exposure.
That’s not a coincidence of naming — it’s architectural. The whole vulnerability class depends on concepts that only exist in a browser: DOM click events, the isTrusted flag that distinguishes real user input from scripted input, other extensions sharing a page context, a side panel reading URL query parameters. Claude Code has no DOM, no synthetic click events, no concept of a “trusted click” to forge in the first place. This is precisely the attack surface this blog has argued repeatedly comes bundled with editor- and browser-embedded AI tooling that Cursor-style, human-in-the-loop-anchored products also carry, versus the smaller, more auditable surface of a CLI agent that operates on files and shell commands rather than on a live, script-accessible browser page shared with every other extension the user has installed.
That architectural point doesn’t excuse the specific failure here, though. Anthropic ships Claude for Chrome as a real product, sells it as part of the Cowork ecosystem this blog covered on August 13 — the same announcement that expanded Claude in Chrome into a full, persistent session across desktop, web, and mobile without a word about this exact security history — and a three-month-old, trivially reproducible, high-severity bug with a known one-line fix sitting unpatched is a legitimate gap between the “safety first” branding and what’s actually shipping. If you or your team run Claude for Chrome with “Act without asking” enabled, the honest recommendation right now is to turn that setting off until Anthropic actually confirms a fix — the CVSS delta between the default and unattended modes, 7.7 to 9.6, exists precisely because that setting removes the one human checkpoint standing between a forged click and real access to your inbox.
Sources: Manifold Security, “ClaudeBleed Reopened” (primary, July 14, 2026), SecurityWeek, “Unpatched Claude for Chrome Flaw Lets Extensions Read Gmail, Calendar” (secondary, July 14, 2026), The Hacker News coverage of the same disclosure (secondary, July 14, 2026), BleepingComputer, “Claude Chrome extension flaw lets malicious extensions trigger AI actions” (secondary, July 16, 2026).