Extension Permissions

CVE-2026-0628 and the Gemini side panel: when WebView met declarativeNetRequest

A patched Chrome flaw ("Glic Jack") showed how a malicious extension could reach a high-trust browser surface—the Gemini Live panel—via WebView and request rules. What broke, what Google fixed, and why it matters.

eSafe TeamPublished Mar 2, 2026Last reviewed Apr 1, 20268 min read

Palo Alto Networks Unit 42 researcher Gal Weizman reported a Chrome issue, disclosed as CVE-2026-0628 (CVSS 8.8), described in public databases as insufficient policy enforcement involving the WebView path used by Chrome’s Gemini integration. Google addressed it in Chrome 143.0.7499.192 / .193 (Windows and Mac) and 143.0.7499.192 (Linux), with fixes called out around early January 2026. The research nickname “Glic Jack” refers to Gemini Live in Chrome—the side panel opened from the toolbar that loads Google’s assistant experience.

The scenario starts with a user installing a malicious extension. Under the bug, that extension could inject script or HTML into the privileged panel context instead of staying within the normal extension–website boundary you expect from the permission model.

What made the panel different

Chrome exposes Gemini through chrome://glic, which embeds gemini.google.com using a WebView-style surface. That UI is intentionally close to the browser: it is where camera, microphone, screenshots, and file-oriented helpers can make sense for an AI assistant. Unit 42’s analysis stressed the tension: powerful by design, dangerous if an extension can steer it.

Coverage summarized the impact path as privilege escalation relative to what the extension was supposed to have: possible access to camera and microphone without the usual user consent path, screenshots across sites, and local file access—capabilities tied to the assistant feature set, not to a typical low-trust content script.

The declarativeNetRequest angle

Declarative Net Request (DNR) lets extensions declare rules that alter network requests and responses (famously used by ad blockers). The research narrative is that rules were applied in a way that also affected the WebView loading Gemini, where Chromium’s policy should have treated that component differently.

Weizman (and reporting on Chromium’s postmortem framing) described the core mistake as WebView-backed surfaces like chrome://glic being left out of the “do not apply this class of rule here” boundary for DNR—so a crafted extension with relatively ordinary-looking permissions could reach the panel in a way that crossed privilege lines.

After the patch

With current Chrome, the forgotten-WebView class of issue is closed for this CVE. For users, the durable lessons are:

  • Update Chrome on a steady cadence; browser updates are part of extension security.
  • AI panels inside the browser are new attack surface: they sit in high-trust UI, so implementation bugs there have outsized impact.
  • Extensions remain a trust decision—especially any add-on that asks for network-rule or broad site powers.

Practical next step

Confirm Chrome → About Google Chrome shows a patched 143.x (or newer) build on every machine you care about. Then trim extensions you do not recognize. eSafe can help you see permissions and risk signals in one place.

Go deeper

Browser extension permissions explained → — what common APIs imply, and how to read an install prompt.

Report: The Hacker News.

FAQ

Do I need to update Chrome if I do not use Gemini?
Yes—security fixes apply to the whole browser. Attackers can target latent code paths; patching is the primary mitigation regardless of feature usage.
What is the role of declarativeNetRequest in the issue?
Public write-ups describe how network filtering rules and WebView loading interacted with policy gaps; the technical detail is for defenders and browser engineers, but the user takeaway is to stay on current stable Chrome.
Does this mean all AI side panels are unsafe?
It means high-trust UI embedded in the browser is an attractive target and requires strict enforcement between extension, page, and built-in surfaces—something vendors address through coordinated disclosure and patches.

Scan your extensions to see if this permission is active on your profile—clear labels, no guesswork.

Add eSafe to Chrome