Can A Rogue Chrome Extension Make Claude Read Your Gmail?

July 26, 2026

Researchers found that another Chrome extension could trigger Claude for Chrome workflows involving Gmail, Docs, Calendar, and Salesforce. We checked the current v1.0.81 package and found the disputed click boundary unchanged.

Yes, under specific conditions. Manifold Security found that another Chrome extension able to run code on claude.ai could simulate a click that Claude for Chrome accepted as user intent, triggering fixed workflows involving Gmail, Google Docs, Calendar, and Salesforce. The demonstrated default flow still showed an approval prompt, while a no-approval mode could allow silent action. No reviewed source reports exploitation in the wild.

Watch The 30-Second Summary

Watch this video on YouTube

Updated July 26, 2026: OpenVeil independently inspected Claude for Chrome v1.0.81 from the Chrome Web Store distribution path. The current package still contains the reported onboarding-button listener without an event.isTrusted check. That code finding does not, by itself, prove every v1.0.80 attack path remains exploitable end to end.

Who This Article Is For

This article is for:

The important question is not simply, "Is Claude safe?" The useful question is: which extension can trigger an action, which account can Claude reach, what approval still appears, and what happens after that approval is removed?

What Is Confirmed

Researchers Demonstrated A Synthetic-Click Trigger

Manifold Security's primary disclosure describes two findings reported to Anthropic in May 2026 and retested against Claude for Chrome v1.0.80 on July 7.

The first finding concerned a content script that listened for a click on an element identified as Claude's onboarding button. That element could select one of nine fixed task IDs. According to Manifold, the handler did not verify whether the click came from a real user or was dispatched programmatically.

The browser already exposes that distinction. MDN's documentation for Event.isTrusted explains that a browser-generated event is marked trusted, while a click dispatched by script is marked untrusted.

Manifold says another extension with the ability to run a content script on claude.ai could:

  1. add the expected onboarding element to the page
  2. choose one of Claude's hardcoded task IDs
  3. dispatch a synthetic click
  4. cause Claude's side panel to load the matching workflow

The available workflows were constrained, not arbitrary. They reportedly included reading recent Gmail messages, opening a recent Google Doc and its comments, checking Calendar availability, creating meetings, and modifying Salesforce leads.

That limitation matters. The finding was not "any website can send any prompt to Claude." It was a narrower but still consequential trust failure: another installed extension could allegedly activate a small set of powerful, prewritten cross-account workflows.

The Attack Required Another Extension With Access To Claude.ai

This was not a drive-by attack available to every webpage.

The demonstrated trigger required another browser extension capable of running code in the claude.ai page. That could be a malicious extension, a legitimate extension that became compromised, or an overprivileged extension abused through another flaw.

Chrome's extension-permission documentation explains that content-script match patterns and host permissions determine where an extension may inject scripts or interact with pages. Google recommends limiting permissions because narrower permissions reduce the damage a compromised extension can cause.

The distinction creates a five-part precondition test:

Required condition Why it mattered
Claude for Chrome was installed and signed in The targeted agentic extension had to be present
Another extension could run on claude.ai The synthetic element and click needed page access
Claude had browser-control permission The selected workflow needed authority to act
A relevant account was open and authorized Gmail, Docs, Calendar, or Salesforce data had to be reachable
Approval was granted or skipped The task still needed to cross Claude's action-approval boundary

These conditions narrow the risk. They do not erase it. Browser extensions routinely share one browser profile, and users often grant broad site access to tools that edit pages, manage passwords, block content, automate work, or assist with development.

Default Approval And Silent Execution Were Different Cases

Manifold assigned different severity scores based on approval mode.

In the default mode it tested, the synthetic trigger loaded the workflow but Claude displayed an approval dialog before sensitive actions continued. The researchers scored that path CVSS 7.7 High because a fake trigger could still coerce the user into approving an unexpected plan.

When the user had previously enabled the old Act without asking mode, Manifold says the triggered workflow could proceed without that visible approval. It scored that case CVSS 9.6 Critical.

Anthropic's current Claude in Chrome permissions guide now describes three modes:

Current mode Documented behavior
Manually approve Claude pauses for approval before each action
Automatically approve Claude reviews actions for safety and pauses when needed
Skip all approvals Claude does not pause, and no automatic action check runs

Anthropic warns users to choose Skip only when they completely trust every action, connector, file, app, and other input involved in the task.

That is the central security multiplier. A surprising trigger is serious; a surprising trigger combined with connected accounts and no approval is much more serious.

The Second Finding Was Structural, Not A Standalone Remote Exploit

Manifold's second finding involved a skipPermissions URL parameter used by Claude's scheduled-task flow. The researchers found that Claude's side panel could initialize in a privileged mode when that parameter was set.

The primary disclosure explicitly says this second primitive was not directly remotely exploitable in v1.0.80. Constructing the relevant side-panel URL still required same-extension privilege. Manifold described it as an architectural weakness that could amplify a future bug capable of influencing that URL.

That boundary should not be collapsed into the first finding.

A defensible account must keep those claims separate.

Claude For Chrome v1.0.81 Still Has The Disputed Click Handler

The Chrome Web Store listing for Claude showed version 1.0.81, updated July 16, 2026, when this article was researched. The listing reported approximately 12 million users and disclosed handling of personal communications, location, web history, user activity, and website content.

OpenVeil downloaded the current public package through Google's extension-update distribution path on July 26 and performed a static inspection. We did not run the proof of concept, access a real user's connected account, or test any sensitive workflow.

The package identified itself as v1.0.81. Its content script still:

The v1.0.81 package also still contained skipPermissions references in its scheduled-task and side-panel code.

This is useful current evidence, but its scope must remain precise. Static code continuity shows that the exact click check Manifold proposed was not added to that handler. It does not rule out a mitigation elsewhere in the service, a feature flag, a changed permission state, a server-side validation, or a different end-to-end behavior in v1.0.81.

Anthropic Publicly Warns That Browser-Agent Risk Is Not Zero

Anthropic's current Claude in Chrome safety guide says prompt injection is the biggest risk facing browser-using AI tools and acknowledges that novel attacks can bypass evaluated defenses.

The same guide says:

Anthropic reports a low attack-success rate in its internal prompt-injection testing, but it also says no defense is perfect. The current Manifold report is about an extension trust boundary rather than only a model being fooled by text, so one evaluation number cannot settle the entire product-level question.

Multiple Outlets Picked Up The Disclosure

SecurityWeek and TechRadar independently summarized the report and highlighted the difference between an approval-gated trigger and no-approval execution.

The coverage adds attention, not independent technical reproduction. The underlying exploit mechanics and affected-version claims still come from Manifold's research and OpenVeil's limited static inspection of v1.0.81.

What Is Still Unclear

Anthropic Has Not Published A Dedicated Advisory

Anthropic's public safety and permissions documentation explains the general risks and controls for Claude in Chrome. It does not provide a dedicated advisory for these two findings, a CVE, an affected-version table, or a statement that v1.0.81 fixes or accepts the reported behavior.

Manifold says Anthropic acknowledged the reports, treated the URL-parameter finding as informative, and tracked the broader trust-boundary issue internally. The public record does not explain Anthropic's full technical assessment of v1.0.81.

End-To-End v1.0.81 Exploitability Is Not Confirmed Here

The current package still lacks the disputed isTrusted check. That is stronger evidence than merely assuming v1.0.81 inherited v1.0.80 behavior.

It is still not the same as a complete live exploit test. A full confirmation would need to establish:

This article does not claim those steps were all reproduced against v1.0.81.

The Number Of Exposed Users Is Unknown

The Chrome Web Store reported roughly 12 million users, but the available sources do not say how many:

The installation count is an attention and potential-reach signal, not an affected-user count.

No Exploitation Report Does Not Prove No Attempt Occurred

No reviewed source reports exploitation in the wild.

That should not be rewritten as "no one was affected." Public reporting may be incomplete, and a triggered workflow could resemble an ordinary action performed inside a legitimate browser session.

The responsible conclusion is narrower: there is no public evidence of real-world exploitation in the sources used for this article.

How One Extension Could Reach Another Extension's Authority

The durable lesson is a trigger-to-authority chain:

Layer Security question Reported weakness
Page access Which extension may alter claude.ai? Another extension with page access could add the expected element
User intent Did a person actually click? The handler allegedly accepted a synthetic click
Task scope What instruction could be sent? The task was limited to nine fixed workflows
Agent permission What could Claude do in the browser? Existing browser-control permission made the workflow meaningful
Account access Which services were reachable? Logged-in Gmail, Docs, Calendar, or Salesforce could supply data or actions
Approval Would a person stop the action? Manual approval reduced risk; no-approval mode removed that checkpoint
Monitoring Would the action look unusual? Activity could resemble ordinary authenticated browser automation

This is why "the prompt was allowlisted" was not enough. Restricting the message to nine known tasks reduced arbitrary injection, but the system still needed to prove that a real user intentionally selected one of those tasks.

It is also why browser extensions should be reviewed as a group. One extension's permissions can become the trigger for another extension's authority.

This differs from AgentForger's crafted-link agent creation, but the shared lesson is recognizable: login state, connectors, approval settings, schedules, and agent permissions must be reviewed together.

What Claude For Chrome Users Should Do

1. Confirm The Installed Version

Open chrome://extensions, enable the details view for Claude, and confirm that Chrome has installed the newest available version.

Updating is still worthwhile even when a public advisory is incomplete. New releases can contain unrelated security fixes, and remaining on an older version adds avoidable uncertainty.

Do not treat "latest" as proof that this exact report is resolved. Treat it as the minimum starting point.

2. Audit Every Extension That Can Run On Claude.ai

Google's Chrome Help instructions explain how to review an extension's site access and change it to:

For each installed extension, ask:

  1. Does this tool need to read or change claude.ai?
  2. Does it need access on every site?
  3. Is the publisher still trustworthy?
  4. Has the extension changed ownership or purpose?
  5. Would disabling it break a real workflow?

Remove extensions you no longer use. Restrict site access where the extension still works with narrower permission.

3. Prefer Manual Approval For Sensitive Work

Use manual approval when Claude can reach:

Automatic safety checks can reduce friction, but they are not equivalent to a person reviewing the intended site, data, destination, and action.

Skip all approvals should not be a convenience default. Anthropic's own documentation says nothing checks actions automatically in that mode.

4. Use A Separate Browser Profile

Anthropic recommends a separate browser profile without access to sensitive accounts.

That advice creates a meaningful containment boundary:

A separate profile is not a perfect sandbox. It reduces the number of accounts, cookies, tabs, and extensions sharing one trust domain.

5. Review Connected Accounts And Recent Actions

Check Gmail, Google Account, Calendar, Docs, Salesforce, and any other connected service for:

If something looks wrong, revoke sessions and app access, rotate affected credentials, and follow the provider's account-recovery guidance.

6. Use Organization Controls Where Available

Anthropic documents organization-level allowlists, blocklists, and the ability to disable Claude in Chrome.

Administrators should:

The goal is not to trust one classifier more. It is to reduce the number of paths from untrusted content or software to sensitive authority.

What This Report Does Not Prove

The disclosure and current code inspection do not prove that:

The flaw described by Manifold was in an extension-level trust boundary. The report says it reproduced across multiple Claude model selections, which supports treating the model and the browser integration as separate layers.

Where OpenVeil Fits - And Where It Does Not

OpenVeil is a paid, privacy-focused AI chat workspace with browser-local chat history and no server-side chat-history record for private chat sessions. It supports web search, uploads, voice, and image tools where enabled.

For someone who wants general AI chat but does not need an agent controlling Gmail, Docs, Calendar, Salesforce, or arbitrary browser tabs, choosing a narrower capability surface can be a reasonable form of data minimization.

That is a product-fit distinction, not protection from this vulnerability.

OpenVeil does not claim to:

Active OpenVeil requests may still be processed by OpenVeil and necessary AI, search, upload-processing, hosting, routing, security, billing, and infrastructure providers. OpenVeil also keeps the account and billing records required to operate the service.

The relevant comparison is scope. If the task is chat, browser-local AI chat history may fit without granting an AI browser agent ongoing access to unrelated logged-in accounts.

Before choosing any AI tool, use the AI privacy-claim checklist and match the product's authority to the task.

FAQ

What Is The Claude For Chrome Vulnerability?

Manifold Security reported that another browser extension able to run code on claude.ai could dispatch a synthetic click that Claude for Chrome accepted, triggering one of nine fixed workflows. The workflows included tasks involving Gmail, Google Docs, Calendar, and Salesforce.

Can Any Website Make Claude Read Gmail?

Not through the demonstrated path. The report required another installed extension with the ability to run code on claude.ai. A normal unrelated webpage did not have that permission merely because it was open.

Does The Attack Bypass Every Approval Prompt?

No. Manifold says the default mode it tested still displayed an approval prompt. Silent action was associated with a mode that skipped approvals. Current Anthropic documentation calls that mode Skip all approvals and says no automatic action checks run in it.

Is Claude For Chrome v1.0.81 Fixed?

Anthropic has not published a dedicated advisory that answers that question. OpenVeil's static inspection found that v1.0.81 still contains the reported click handler without an isTrusted check. A complete end-to-end v1.0.81 exploit test was not performed, so this article does not claim every step remains exploitable.

Was The Vulnerability Exploited In The Wild?

No reviewed source reports exploitation in the wild. That means there is no public evidence in the sources used here, not that an attempted or undetected use is impossible.

Should I Uninstall Claude For Chrome?

That depends on whether you need the browser-control capability and can manage its permissions. At minimum, update the extension, audit every other extension with access to claude.ai, use manual approval for sensitive actions, restrict connected accounts, and consider a separate browser profile. Organizations that cannot enforce those boundaries may reasonably disable the extension.

Does A Separate Chrome Profile Make Claude Safe?

A separate profile reduces exposure by separating cookies, accounts, tabs, and extensions. It does not prove the agent or browser is invulnerable. Keep the profile narrow and avoid signing it into accounts the workflow does not need.

Is OpenVeil Vulnerable To The Same Claude Extension Flaw?

The reported flaw concerned Claude for Chrome, not OpenVeil. OpenVeil's relevant distinction is that it focuses on privacy-oriented AI chat with browser-local history. It does not claim to secure another vendor's extension or protect a compromised browser.

The Bottom Line

Manifold's report describes a narrow but high-stakes chain: another extension could allegedly fake user intent, Claude could translate that trigger into a connected-account workflow, and a no-approval mode could remove the final visible checkpoint.

The latest public Claude for Chrome package was v1.0.81 when checked. Its disputed click listener still lacked an isTrusted check, but Anthropic has not published enough technical detail to say whether every live attack step remains open.

The practical response does not require waiting for perfect certainty:

If your actual need is private AI chat rather than cross-account browser automation, explore OpenVeil and read the OpenVeil privacy policy before choosing a paid plan.

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.