Your Next Security Incident May Start in an AI Assistant, Not an Inbox

A high-severity vulnerability in Google Chrome's Gemini AI assistant allowed malicious browser extensions to hijack the assistant's privileged access - including camera, microphone, local files, and screenshots - without user consent. The flaw (CVE-2026-0628, CVSS 8.8) was patched in January 2026, but the underlying architectural pattern it exposed applies to every browser and platform embedding AI assistants into privileged system contexts.

This incident sits alongside the McKinsey Lilli breach as another signal that enterprise AI platforms are creating attack surfaces that traditional security models were not designed to address.

Key Takeaways

• CVE-2026-0628 allowed low-privilege Chrome extensions to inject code into the Gemini Live panel and inherit its system-level capabilities, including local file access, camera, microphone, and screenshot capture (Palo Alto Networks Unit 42, March 2026)
• The vulnerability required only that a user install a malicious extension with basic declarativeNetRequests permissions - no sophisticated exploit chain needed (SecurityWeek, March 2026)
• Google patched the flaw in Chrome 143.0.7499.192 in early January 2026, prior to public disclosure (Google Stable Channel Update, January 2026)
• The same architectural risk - AI assistants with privileged access embedded in trusted UI contexts - applies to Microsoft Copilot in Edge, and standalone agentic browsers like Atlas and Comet (Malwarebytes, March 2026)
• WordPress.com now allows AI agents to autonomously draft, edit, and publish website content through its MCP integration, adding another vector where AI-driven systems operate with write access to production environments (TechCrunch, March 20, 2026)

What Happened: The Gemini Panel Hijack

Chrome's Gemini Live panel is not a typical browser extension. It runs inside a special chrome://glic URL using a WebView component that loads the Gemini web app with elevated privileges. The panel can read local files, take screenshots, access the camera and microphone, and execute multi-step browser automation tasks - all capabilities required for an AI assistant that operates on behalf of the user.

The vulnerability was straightforward. Chrome extensions with standard declarativeNetRequests permissions - the same level of access used by common ad blockers - could intercept and modify network requests destined for the Gemini panel. Because the panel was not explicitly listed as a protected target, a malicious extension could inject JavaScript directly into it. Once inside, the attacker's code inherited every privilege the AI assistant held.

Palo Alto Networks' Unit 42 researcher Gal Weizman, who discovered and reported the flaw, described the root cause as a missing entry on a blocklist. The Gemini panel was added to Chrome in September 2025. The vulnerability existed until January 2026. During that window, any extension exploiting this gap could silently capture files, activate cameras, take screenshots, and display phishing content inside what users perceived as a trusted browser component.

Why AI Assistants Change the Threat Model

Traditional browser extensions operate within a defined permission sandbox. A user grants specific capabilities during installation, and the browser enforces those boundaries. AI assistants fundamentally alter this model because they require broad, persistent access to function as intended.

The Gemini panel needs to see what the user sees. It needs to read files to process documents. It needs camera and microphone access for live interaction. These are not optional features - they are the core value proposition of an agentic AI assistant. The same architecture exists in Microsoft Copilot in Edge and in standalone agentic browsers. Every AI assistant embedded in a privileged browser context creates a high-value target that, if compromised, grants an attacker capabilities far beyond what a typical extension exploit would provide.

This is not a one-off vulnerability. It is a structural pattern. Each new AI feature added to a browser introduces a new privileged component that must be explicitly protected against existing attack vectors - extension injection, prompt injection, cross-site scripting, and side-channel attacks. As Unit 42 noted, developers integrating AI into browsers could inadvertently create new logical flaws by placing powerful components within high-privilege contexts. For a deeper look at how these risks compound when agents gain autonomy, see our analysis of AI agent security risks boards are not seeing yet.

The Expanding AI Attack Surface Beyond Browsers

The browser is not the only environment where AI assistants are gaining write access to production systems. On March 20, 2026, WordPress.com announced that AI agents can now autonomously draft, edit, publish, and manage content on websites through its Model Context Protocol (MCP) integration. The update added 19 write operations across six content types: posts, pages, comments, categories, tags, and media.

WordPress powers approximately 43% of all websites. The MCP integration allows any compatible AI client - Claude, ChatGPT, Cursor, or other MCP-enabled tools - to operate a WordPress site as if it were a logged-in user with publishing privileges. While Automattic has implemented approval workflows, draft defaults, and role-based permissions, the structural shift is significant: autonomous AI systems now have write access to production web infrastructure at scale.

The pattern is consistent across platforms. AI assistants are moving from read-only tools that summarize and suggest to write-enabled agents that execute, publish, and modify. Each expansion of capability adds a new surface that security teams must assess, monitor, and control.

What This Means for Enterprise Security Teams

The traditional approach to browser security - managing extension policies, enforcing allowlists, and monitoring network traffic - is necessary but no longer sufficient. AI assistant integrations introduce a new class of privileged component that sits outside the conventional extension security model.

Three areas require immediate attention. First, browser AI feature inventory: organizations need to know which AI assistants are active across their endpoint fleet, what system capabilities those assistants can access, and whether those features can be centrally managed or disabled. Second, extension governance in the context of AI panels: extension policies designed before AI integration may not account for the elevated risk that a compromised extension now poses when it can reach privileged AI components. Third, AI write-access monitoring: any system where AI agents have write access to production environments - content management, code repositories, communication platforms - needs the same audit trail, approval workflow, and anomaly detection applied to human privileged access.

The Chrome Gemini vulnerability was a missing blocklist entry. The fix was a few lines of code. But the architectural question it surfaced - how do you maintain security boundaries when AI assistants require broad, privileged access by design? - does not have a simple answer. It requires a reassessment of how enterprises evaluate, deploy, and monitor AI-integrated tools across their technology stack. Organizations already working through AI agent deployment security frameworks will need to extend those controls to cover embedded AI assistants in browsers and productivity tools.

If you are assessing how AI assistant integrations affect your organization's attack surface, or need to map AI write-access points across your environment, reach out to discuss.