Claude's vulnerability for Chrome: simulated clicks and unconfirmed permissions that expose Gmail, Docs and Calendar

Author: Published 4 min de lectura 229 reading

The images in this article were generated with artificial intelligence. How we publish

A new review of the "Claude for Chrome" extension again shows a broken border between the browser and the models: it is not an IA failure, but a misdefined trust between extensions. The vulnerability described above allows another extension that can already run scripts in claude.ai simule a click on the official extension interface and triggers pre-approved tasks - such as reading your Gmail, opening your latest Google Doc with its comments or accessing your Calendar - without the page checking that the click came from a real user.

In technical terms, the central problem is double. First, the handler that responds to the onboarding button does not check event.isTrusted, the browser indicator that distinguishes a human click from a synthetic one generated by script; that makes any extension with access to the claude.ai DOM can build the element, set the permitted task ID and shoot the event. Second, there is a URL parameter ( skipPermissions = true) which initiates the side panel in "act without asking" mode, so that, if the panel opens with that flag, the extension operates without requesting user approval. Overall, the combination can transform a forged action into a fully silent execution if the user had previously activated the mode without confirmation.

Claude's vulnerability for Chrome: simulated clicks and unconfirmed permissions that expose Gmail, Docs and Calendar
Image generated with IA.

Anthropic took action after the original finding that limited to nine task IDs that the page may ask for extension, an improvement against the ability to inject arbitrary prompts. However, the mitigation does not fix the root: refuse third-party scripts to simulate the user's intention and no longer rely on URL parameters for the status of permits are necessary corrections that had not yet been deployed in the inspected package. The lack of verification of event.isTrusted and reading of skipPermissions from the URL leave the door open to what in safety is known as a problem of "confused deputy" and indirect prompt injection in the context of LLM applications, two vectors that already appear in frames such as the OWASP Top 10 for LLM Apps.

The practical implications are clear: if you use the extension with your already authenticated Google accounts and you also have any other extension with access to claude.ai, an attacker can force Claude for Chrome to load one of the permitted tasks. In the default mode an approval box will appear which the user must press, but in "Act without asking" mode the same sequence runs without human interaction. This exposes mail, documents and calendar to exfiltration or to unwanted automated actions and makes the control of permissions between extensions critical.

For users and administrators, there are immediate and practical measures that reduce the risk today. Disable "Act without asking" mode and returns to the way that always requests confirmation; that restores the human control window. Check all extensions that have permission to "read and change data" in claude.ai and remove or restrict those you do not need. Consider using a separate browser profile or dedicated browser for agent / IA if you need Claude's extension; thus limit the scope of each extension to the minimum required. If you are an organization manager, apply extension installation policies and check permissions with endpoints management tools.

Claude's vulnerability for Chrome: simulated clicks and unconfirmed permissions that expose Gmail, Docs and Calendar
Image generated with IA.

In the medium and long term, Anthropic and extension developers should adopt two simple and effective changes: reject events with event.isTrusted = = = false in the IU and do not depend on the status of permissions passed by URL parameters, deciding the mode of permits based on internal states or secure calls that cannot be forged from less privileged contexts. These corrections link with good safe design practices for interfaces that act with high permissions and reduce the risk that future vulnerabilities (XSS, back-up in message handlers, or hostile repositories) will allow you to climb to silent execution.

If you want to follow the case with technical sources and reference frameworks, check the OWASP risk guide for applications using LLM and Claude's official page to understand the product and its deployment: OWASP Top 10 for LLM Apps and Claude - Anthropic. Also keep an eye on the list of the Chrome Web Store if you use the extension in browser: search for "Claude" in Chrome Web Store.

Finally, it requires transparency for suppliers: it calls for a public notice and a CVE when these failures are reported, it checks that the version you install includes the arrangement and its evidence, and it keeps official communiqués alert. The central lesson is that giving "agency" to a web assistant within the browser involves risks that are not corrected only by limiting prompts; solid controls are needed in the human interaction layer and in the management of permissions between extensions. Until then, the caution and segmentation of environments are your best defense.

Coverage

Related

More news on the same subject.