Your AI Assistant Was the Attack: Inside CVE-2026-0628 and the Glic Jack Chrome Exploit

A patched Chrome vulnerability gave attackers a clear path from an ordinary browser extension straight into Google's Gemini AI panel—and through it, into your camera, your microphone, and your local files. The bug is fixed. The lesson is not.

Security research rarely produces a finding that is simultaneously specific, technically elegant, and genuinely unsettling. The Glic Jack vulnerability manages all three. Disclosed publicly on March 2, 2026 by Gal Weizman, senior principal researcher at Palo Alto Networks' Unit 42, this is not your typical browser bug—it is a window into the structural risk that comes with welding AI agents directly into the browser's core. The patch arrived in January. The architecture problem it exposed is still very much with us.

The Trust Inheritance Problem

There is a concept worth naming before getting into the technical details, because it underlies everything that follows: trust inheritance. It is not a formal security term. It is a description of something that happens whenever a new capability is embedded inside an existing trusted system — the new thing automatically inherits the trust the user has already extended to the host, without any fresh act of consent.

You trust Chrome. You have trusted it for years. That trust was built through a long, accumulated history of it working correctly, updating reliably, and sitting between you and the web without obviously betraying you. That trust is institutional. It does not get re-evaluated every time Google ships a new feature. When Gemini appeared inside Chrome as a side panel, it did not arrive as an unfamiliar entity that you assessed and decided to trust. It arrived inside something you had already decided to trust, and inherited that judgment automatically.

This is not unique to Chrome or Gemini. It is a pattern. ActiveX inherited the trust of Internet Explorer. Java applets inherited the trust of the browser runtime. Flash inherited the trust of embedded media. Each of those technologies became a primary exploitation target not because attackers found them interesting in isolation, but because they lived inside a trusted container and therefore arrived on the victim's machine pre-authorized. We spent roughly a decade undoing each of those mistakes.

The browser AI panel is the same pattern at a higher privilege level. The difference this time is that the embedded component does not merely execute code or play video. It reads your files, activates your camera, takes screenshots of your screen, and acts on your behalf across authenticated sessions. The trust it inherits is not just the trust you have in Chrome as a display surface. It is the trust you have in your own machine. That distinction matters enormously, and Glic Jack is the first concrete proof that the threat model around it was not fully thought through before deployment.

What Happened: The Glic Jack Vulnerability

The vulnerability is tracked as CVE-2026-0628 with a CVSS score of 8.8, placing it firmly in the high-severity range. The NIST National Vulnerability Database characterizes it as insufficient policy enforcement in Chrome's WebView tag, allowing a crafted extension to inject scripts or HTML into a privileged page.

The unofficial name, Glic Jack, is short for Gemini Live in Chrome hijack—a reference to the internal Chrome URL chrome://glic that loads the Gemini AI side panel. It was discovered in late 2025 and responsibly disclosed to Google on October 23, 2025. Google confirmed the vulnerability, reproduced the conditions required to exploit it, and issued a fix on January 6, 2026. The patch shipped in Chrome version 143.0.7499.192 and 143.0.7499.193 for Windows and macOS, and 143.0.7499.192 for Linux.

That timeline carries a detail worth sitting with. Gemini in Chrome launched for U.S. desktop users on September 18, 2025. The vulnerability was reported to Google on October 23, 2025. That is 35 days between general availability and a confirmed high-severity flaw in the component's privilege boundary. This is not an indictment of anyone's intentions. It is a precise illustration of how feature velocity and security review operate on different schedules — and what happens when the gap between them is measured in weeks rather than months.

The root cause compounds this. According to Chromium's own post-incident assessment, the chrome://glic WebView was not included in the list of contexts that extension request interception rules were blocked from reaching. It was not that the protection was bypassed. The protection simply did not know chrome://glic existed. The most common name for this class of failure is not a vulnerability. It is institutional forgetting — the gap between what a system was designed to protect and what it was actually told about.

As of the time of writing, CVE-2026-0628 is not listed on CISA's Known Exploited Vulnerabilities (KEV) catalog, and there is no confirmed evidence of active exploitation in the wild at scale. However, at least one public proof-of-concept repository has been indexed in VulnCheck's exploit database, which meaningfully raises the risk for organizations running outdated Chrome deployments.

Why the Gemini Panel Is a Different Kind of Target

To understand what made this vulnerability dangerous, you need to understand what Gemini Live in Chrome actually is—and why it requires a level of access that no ordinary browser component does.

Google introduced Gemini Live into Chrome on September 18, 2025, rolling it out to Mac and Windows desktop users in the United States as part of a broader wave of what researchers are calling "agentic browsers." These are browsers, or browsers with integrated AI assistants, that do not merely display web content but actively act on it. They summarize pages in real time, execute multi-step tasks, fill out forms, interpret context across tabs, and respond to natural language instructions. Google's Gemini is one of these. Microsoft's Copilot in Edge, and standalone products like Atlas and Comet, operate on the same architectural premise.

To perform these functions, Gemini Live needs to see what you see. It needs to read page content, take screenshots, access your camera and microphone for certain features, and read local files when asked to help with documents. These are not bugs—they are requirements. The AI assistant cannot summarize what it cannot see. It cannot help with a document it cannot read. So Chrome grants the Gemini panel elevated, privileged access to the browsing environment that no standard extension or webpage receives.

As Weizman noted in the Unit 42 report, granting an AI direct, privileged access to the browsing environment enables complex multi-step operations that were previously impossible — but that same access introduces attack surface that did not exist in traditional browsers. His framing of the tradeoff is precise: the same capabilities that make agentic browsers useful are exactly what make them worth targeting.

That elevated access is precisely what made the Gemini panel such a high-value target. When an attacker can reach it, they do not inherit the limited capabilities of a browser extension—they inherit the capabilities of the AI itself.

How the Attack Actually Works

The attack path is worth walking through carefully, because it is both technically interesting and deceptively simple from the attacker's perspective.

Step 1: The Entry Point Is a Legitimate API

The attack exploits Chrome's declarativeNetRequest API, which is the same interface used by legitimate ad-blocking extensions such as uBlock Origin and AdBlock. This API allows extensions to intercept, modify, and redirect HTTPS web requests and responses. There is nothing inherently malicious about it. A malicious extension using this API does not look unusual to an average user reviewing extension permissions.

Normally, an extension with access to declarativeNetRequest can intercept and modify the contents of https://gemini.google.com/app when that URL is loaded in a regular browser tab. This is intentional behavior—extensions can interact with websites. But crucially, doing this in a standard tab does not grant access to anything special. The Gemini web app rendered in a normal tab is just a web app.

Step 2: The Context Difference That Created the Flaw

The vulnerability arose from a subtle but critical difference between loading the Gemini app in a regular tab versus loading it inside Chrome's Gemini side panel. The side panel uses a <webview> tag component to embed https://gemini.google.com/app at the chrome://glic address. When Chrome loads the Gemini app in this context, it hooks it with the elevated capabilities the AI needs to function—local file access, screenshot capability, camera and microphone access.

The WebView tag in that panel context was inadvertently excluded from the policy enforcement rules that should have prevented extension-level content injection. As a result, an extension that could intercept the Gemini web app in a normal tab could also intercept it inside the privileged panel—and when it did so, the injected JavaScript code inherited all of the panel's elevated permissions.

copy# Simplified attack flow (conceptual)

1. User installs malicious extension
   (disguised as productivity tool or ad blocker)

2. Extension uses declarativeNetRequest to intercept
   requests destined for gemini.google.com/app

3. Extension injects JavaScript into the Gemini panel
   when loaded via chrome://glic (NOT a standard tab)

4. Injected code executes inside the privileged WebView context

5. Attacker now has access to:
   - Camera and microphone (no additional prompt)
   - Screenshots of any open tab
   - Local files and directories
   - Ability to render phishing UI inside a trusted browser component

Step 3: What the Attacker Could Do

Once code was running inside the Gemini panel context, the attacker could access the victim's camera and microphone without any consent prompt beyond the user having clicked the Gemini button to open the panel. They could take screenshots of any website loaded in any tab, access files and directories on the underlying operating system, and render malicious content inside the Gemini panel—a panel that users trust implicitly because it is a built-in part of Chrome, not an external website.

Weizman's report explains the core mechanism: because the Gemini app depends on elevated access to perform legitimate functions, a successful hijack of the panel delivers that same access to the attacker — system resources an extension could never reach through normal channels. (Unit 42, Palo Alto Networks)

That last point—the phishing angle—deserves more attention than it typically gets in coverage of this vulnerability. A phishing page delivered inside a browser-native panel like Gemini is categorically different from any phishing attack that came before it, and the difference is not technical. It is psychological.

Every piece of security awareness training delivered in the last two decades has been built on a single cognitive foundation: teach people to be skeptical of things that come from outside. Unfamiliar websites. Unexpected emails. Links that don't look right. The mental model users have been trained to apply is one of external threat — something arriving uninvited from the open internet that warrants suspicion before engagement.

The Gemini panel is the opposite of that. It is inside Chrome. It launched from a button in the corner of your browser. It is part of the product you already use. There is no URL to scrutinize. There is no sender to question. There is no unfamiliar domain to hover over. When an attacker renders malicious content inside that panel — a fake login prompt, a spoofed notification, a fabricated security alert from "Google" — the content arrives wearing the full institutional legitimacy of the browser itself. The user's trained skepticism has no surface to attach to. No existing phishing awareness training addresses this scenario, because no existing phishing awareness training was written for a world where the browser's own built-in AI assistant is the attack surface.

The Bigger Problem Nobody Is Talking About

Most reporting on this vulnerability has focused on the specific technical flaw—the WebView policy enforcement gap, the patch, the CVSS score. That is accurate and important. But it understates the architectural issue that the vulnerability reveals.

CVE-2026-0628 is not just a bug in Chrome. It is evidence that the security model built around decades of browser development was not designed with agentic AI panels in mind, and that bolting those panels onto existing architecture creates new risk categories that the old model cannot fully contain.

Weizman's report flags this directly: embedding a new component inside the browser's high-privilege context creates openings for cross-site scripting, privilege escalation, and side-channel attacks — vulnerabilities that less-privileged extensions or webpages can then exploit. (Unit 42, Palo Alto Networks)

Traditional browsers operate on a principle of rendering and displaying content. The browser itself is mostly passive—it fetches and shows. The security model built around it, including same-origin policy, content security policy, and extension permission sandboxing, was designed around that passive model. AI agents embedded in browsers are fundamentally different. They act. They interpret page content as instructions. They make decisions based on what they see. They store context across sessions.

That active, interpretive role creates a second attack vector that CVE-2026-0628 only hints at: prompt injection. A malicious webpage does not need a JavaScript exploit to compromise an agentic browser. It can simply include hidden instructions for the AI assistant—text rendered invisibly or in a way the user cannot see but the AI can process. Those instructions could tell the assistant to perform actions the browser's security model would block from a conventional extension or script. Researchers have noted that in worst-case scenarios, a web page could manipulate the agent to store those instructions in memory, causing the behavior to persist across browsing sessions.

There is a related problem that sits beneath the technical layer and does not get named often enough: the permission model built into browsers was designed for human actions, not delegated machine agency. When Chrome asked you to allow Gemini access to your camera, that was a human making a judgment about a feature. What you were actually authorizing was an AI agent — one that can act on your behalf, interpret instructions from third-party content, and execute across sessions — to have that access on an ongoing basis. The consent was real. The mental model behind it was not. Users consented to a feature. They authorized an agent. These are not the same thing, and the security architecture does not yet have a framework for distinguishing between them.

This is not hypothetical. It is an active research area, and it is the reason that security professionals who understand this space are pushing hard for the concept of agentic browsers to be treated as high-risk infrastructure, not a convenience feature.

Enterprise Risk: Why This Hits Harder at Work

For individual users, this vulnerability is serious. For enterprise environments, it is a different category of problem entirely.

In a corporate setting, a compromised browser session does not just expose personal files—it exposes authenticated sessions inside enterprise applications. An AI agent that has inherited a user's full browser context can read emails, interact with internal tools, access documents stored in cloud drives, and potentially trigger workflows inside applications the user is logged into. The blast radius of a hijacked Gemini panel is not bounded by what the user has open—it is bounded by what the user is authenticated to access.

Enterprise environments also face a compounding risk that individual users do not: the supply chain for browser extensions. A significant number of extension-based attacks in recent years have not involved convincing users to install obviously malicious software. Instead, legitimate extensions with established user bases have been acquired by threat actors, who then push malicious updates to the existing installed base. A user who installed a trusted ad-blocking extension two years ago may have had that extension silently transferred to new ownership and updated with malicious code—without any visible change to their browser.

In the context of CVE-2026-0628, this matters because the attack does not require a sophisticated social engineering campaign. It requires only that a malicious extension with declarativeNetRequest permissions be installed on the target machine—and that Chrome not be running the patched version. Both conditions were achievable through routine extension supply chain compromise.

Anupam Upadhyaya, SVP of Product Management for Prisma SASE at Palo Alto Networks, put the enterprise risk plainly: today's agentic browsers act on behalf of the user — researching, reasoning, and executing — and without enterprise-grade controls, they can take autonomous actions entirely outside IT oversight. By inheriting an authenticated browser session, they can access screens, files, cameras, and microphones in ways that create accountability gaps organizations have not previously had to address. (IT Pro)

Upadhyaya expanded on this in remarks to Dark Reading, noting that agentic browsers can inherit authenticated browser sessions and trigger privileged actions inside enterprise applications — modifying data or initiating workflows without direct user instruction. His prescription: security that is continuous and policy-enforced by design, with real-time inspection of prompts, AI responses, and rendered content built directly into the browser rather than layered on afterward.

"Innovation can't come at the expense of security." — Anupam Upadhyaya, SVP Product Management, Prisma SASE, Palo Alto Networks (IT Pro)

That framing—"high-risk infrastructure"—is the key phrase that security teams in enterprise environments need to internalize. The Gemini panel is not a browser widget. It is an agent with privileged access to the user's entire digital environment, running inside a surface that users consider completely safe. Treat it accordingly.

What You Need to Do Right Now

The specific CVE-2026-0628 vulnerability is patched. But the broader attack surface it exposed requires ongoing attention. Here is what actually matters, in order of priority:

1. Update Chrome immediately across all endpoints. This is not negotiable. Any Chrome installation prior to version 143.0.7499.192 (Linux) or 143.0.7499.193 (Windows/macOS) is vulnerable. In enterprise environments, this should be enforced through policy, not left to users. Verify the current deployed version against those baselines today.
2. Audit installed extensions with declarativeNetRequest permissions. Navigate to chrome://extensions and review every extension that has been granted request interception capabilities. Remove any extension whose publisher you cannot identify, contact, and verify. This includes extensions that appear to be well-known tools—confirm they are the genuine, uncompromised versions.
3. Deploy extension allowlisting via Chrome Enterprise policies. For managed environments, use the ExtensionInstallAllowlist policy to restrict installation to a pre-approved list of extension IDs. This prevents both unauthorized installations and silently updated malicious versions from gaining a foothold.
4. Enable Chrome Enhanced Protection. This can be configured at chrome://settings/security and provides additional real-time protection against malicious downloads and sites. It is not a substitute for the above steps but adds a meaningful additional layer.
5. Treat agentic browser features as infrastructure, not features. If your organization is deploying AI-integrated browser features including Gemini Live, Copilot in Edge, or similar tools, apply the same security controls you would apply to any privileged access workstation. Monitor for anomalous behavior. Log and alert on unexpected Gemini panel interactions from extension contexts. Watch for cameras or microphones activating without user initiation.

Key Takeaways

1. The patch is not the full story. CVE-2026-0628 is fixed in Chrome 143. But it exposed a class of vulnerability that will recur as AI agents become more deeply embedded in browsers. The fix addressed one specific implementation flaw. The architectural risk—privileged AI panels as high-value attack targets—remains.
2. The attack required no exotic permissions. The declarativeNetRequest API used in this exploit is the same API behind legitimate ad-blockers. An extension using it does not look alarming to an average user. The danger was in where the injected code landed, not in the permissions required to get there.
3. The phishing vector inside a trusted UI is the underreported risk. Attackers could render malicious content inside Chrome's own Gemini panel—a surface users have no reason to distrust. This is a fundamentally different phishing scenario from anything that came before it, and it is not addressed by conventional phishing awareness training.
4. Enterprise environments face a compounding threat. The combination of authenticated session access, extension supply chain compromise, and the absence of patching discipline across managed endpoints makes this vulnerability category considerably more dangerous in corporate contexts than in consumer ones.
5. Prompt injection is the next frontier of this threat class. CVE-2026-0628 required a malicious extension. Future attacks on agentic browsers may require only a malicious webpage, embedding hidden instructions that the AI acts on. Security strategy for AI-integrated browsers must account for this now, not after the first confirmed incident.

The browser has been the frontline of cybersecurity for decades. Every time a new capability was embedded inside it — ActiveX, Java, Flash, extensions, and now AI agents — attackers found the gap between what the new thing could do and what the security model knew about it. That gap has always existed. It has always been exploited. And it has always eventually been closed, at the cost of years of compromise in the interim.

Glic Jack closed one instance of that gap in 35 days. The next instance will not announce itself. It will be discovered inside a feature that launched last quarter, granted access that felt reasonable at the time, and inherited trust that nobody formally decided to extend. The organizations that understand this pattern — that the vulnerability is not the bug, but the gap between capability and oversight — will be ready for it. The ones waiting for the next patch to tell them something changed will not be.

The AI panel sitting in the corner of your browser is not a chatbot. It is a privileged agent running inside the most trusted surface in your digital life. Treat it as such, or accept that someone else eventually will.

Sources

• Gal Weizman, Palo Alto Networks Unit 42 — Taming Agentic Browsers: Vulnerability in Chrome Allowed Extensions to Hijack New Gemini Panel (Published March 2, 2026)
• NIST National Vulnerability Database — CVE-2026-0628 Detail
• SecurityWeek — Vulnerability Allowed Hijacking Chrome's Gemini Live AI Assistant
• The Hacker News — New Chrome Vulnerability Let Malicious Extensions Escalate Privileges via Gemini Panel
• Dark Reading — Bug in Google's Gemini AI Panel Opens Door to Hijacking
• PCWorld — Chrome fixes a problematic security flaw in first update of 2026 (January 7, 2026 — confirms January 6 patch release date)
• Malwarebytes — Chrome flaw let extensions hijack Gemini's camera, mic, and file access
• IT Pro — Flaw in Chrome's Gemini Live gave attackers access to user cameras and microphones
• SOCRadar — CVE-2026-0628: Chrome "Gemini Live" Side Panel Injection Bug
• Cybersecurity News — Chrome Gemini Vulnerability Lets Attackers Access Victims' Camera and Microphone Remotely
• Netizen Security Brief — Monday Security Brief (3/2/2026)
• TechCrunch — Google brings Gemini in Chrome to US users, unveils agentic browsing capabilities, and more (September 18, 2025 — confirms Gemini in Chrome general launch date)