The AI Panel That Forgot It Was Part of the Browser: CVE-2026-0628 and the Privilege Problem Nobody Planned For

A researcher at Palo Alto Networks quietly filed a bug report in late 2025 that exposed something deeper than a code mistake: the security industry's oldest rule — that trust levels must never be allowed to blur — had been broken by design, inside the browser billions of people use every day.

There is a foundational rule in browser security: extensions live below websites in the privilege hierarchy, and websites live far below the browser's own internal components. That layered trust model is what keeps a sketchy ad-blocking extension from reading your local files, turning on your webcam, or impersonating a trusted interface. CVE-2026-0628 broke that rule — not through some exotic memory corruption trick, not through a zero-day kernel exploit — but through a policy enforcement gap so specific it only mattered once Google added an AI assistant to Chrome's sidebar.

That AI assistant is Gemini Live. And the gap that made it exploitable had been sitting unnoticed in Chrome's codebase the entire time Google was building it.

What CVE-2026-0628 Actually Is

The National Institute of Standards and Technology's National Vulnerability Database describes CVE-2026-0628 as a case of insufficient policy enforcement in Chrome's WebView tag, noting that it allowed an attacker who convinced a user to install a malicious extension to inject scripts or HTML into a privileged page. Palo Alto Networks Unit 42 researcher Gal Weizman, who discovered the flaw, dubbed it "Glic Jack" — shorthand for Gemini Live in Chrome hijack. The name captures what the vulnerability does more precisely than the NVD language does: it allowed an attacker to commandeer Chrome's integrated Gemini AI panel, a component operating with system-level browser privileges, through a rogue extension with permissions no more exotic than those carried by a typical ad blocker. That description is accurate but clinical. To understand why the security community should care, you need to understand exactly what the Gemini panel is and why it sits at a uniquely dangerous intersection of browser architecture and AI capability.

Chrome's Gemini Live panel is not a website running in a tab. It is a browser-native component — an integrated AI assistant that lives in the browser sidebar and is reachable via the internal URL chrome://glic. That URL matters. The chrome:// scheme signals privileged browser space, the kind of address space where Chrome stores its settings, its internal tools, and its highest-trust functionality. Inside chrome://glic, Chrome uses a <webview> tag to embed the Gemini web application hosted at gemini.google.com. The architecture made sense from a product perspective: load a polished web app inside a trusted browser-native container and hook it to the browser's most powerful capabilities.

The problem was that when Chromium's engineers configured the rules governing what browser extensions could and could not influence, the <webview> components used by chrome://glic were left out of scope. They were not explicitly protected from extension manipulation. This omission is what Gal Weizman of Palo Alto Networks Unit 42 found, and it is what CVE-2026-0628 documents. Unit 42's own published research states the disclosure was made to Google on October 23, 2025; Google's Chrome Releases blog credits a report date of November 23, 2025. Both dates fall within roughly five to ten weeks of the Gemini panel's September 18, 2025 free-user rollout to all U.S. desktop Chrome users — itself an expansion from the initial subscriber-only launch that began May 21, 2025, the day after Google I/O. Google’s Chrome Releases blog, NIST NVD, and all contemporaneous reporting corroborate November 23 as the report date; Unit 42’s published research states October 23, with no other source confirming that earlier date. Either way, what is not in dispute is that the researcher found a critical architectural gap faster than it took Google to complete one product release cycle.

Weizman explained on X that the root cause was simply that the WebView components inside chrome://glic had been "forgotten from being rejected" when engineers applied the declarativeNetRequest rule-exclusion logic — a single oversight with outsized consequences. — Gal Weizman, Palo Alto Networks Unit 42, via X (formerly Twitter)

The Forgotten Boundary: WebView and the Trust Gap

To fully appreciate what went wrong, it helps to understand how the declarativeNetRequest API works and why it is relevant here. This API is one of Chrome's most widely used extension capabilities. It is the mechanism by which ad-blocking extensions intercept outbound requests to advertising networks and silently drop them before they complete. It allows extensions to apply rules to HTTPS web requests and responses in real time. Ad blockers, privacy tools, and content filters all depend on it for their core functionality.

Under Chrome's normal security architecture, an extension using declarativeNetRequest can influence requests made by web pages inside standard browser tabs. That is expected. A browser extension influencing a webpage is something Chrome's permission model anticipates and controls. What Chrome did not anticipate — before this vulnerability was discovered — was an extension using the same mechanism to influence a <webview> component embedded inside a privileged browser surface like chrome://glic.

The difference between those two cases is the entire story of CVE-2026-0628. When the Gemini web application loads inside a standard browser tab, it is just a website. An extension injecting JavaScript into it is manipulating a web context. That is a security concern, but it is within known parameters. When the same Gemini web application loads inside the chrome://glic panel via a <webview> tag, it inherits the privileges Chrome has granted that panel — access to local files, screenshots, camera, microphone, and the ability to interact deeply with the browser environment. An extension injecting JavaScript into that context is no longer manipulating a website. It is manipulating a privileged browser component.

Unit 42 drew the line precisely: an extension altering a website is expected behavior; an extension altering a component baked into the browser is a security risk. The Gemini panel sat on the wrong side of that line. — Palo Alto Networks Unit 42, published research report, March 2, 2026

The root cause, then, is not that declarativeNetRequest is inherently broken. It is that the logic which decides which components are off-limits for extension-driven rule application did not include the new <webview> surfaces introduced with the Gemini panel. A gap opened between where Chrome's isolation policy ended and where the Gemini component's elevated privileges began. That gap is CVE-2026-0628.

How the Attack Plays Out Step by Step

The attack requires one thing from the victim: installing a malicious Chrome extension. That extension does not need exotic permissions. It needs access to the declarativeNetRequest API, which is a standard, broadly approved permission that the Chrome Web Store allows for a wide range of legitimate extension categories including ad blockers, productivity tools, and privacy utilities. A malicious extension disguised as any of those categories would not stand out.

Once installed, the attack chain proceeds as follows:

1. The extension registers declarativeNetRequest rules targeting requests destined for gemini.google.com/app.
2. When the victim opens the Gemini panel in Chrome's sidebar, the panel loads the Gemini web app inside its <webview> container via chrome://glic.
3. Because Chrome's policy enforcement failed to exclude <webview> components from extension-driven rule manipulation, the extension's rules apply to content inside that panel.
4. The extension injects arbitrary JavaScript into the Gemini panel's privileged context.
5. That injected code now runs with the elevated permissions Chrome had granted to the Gemini panel itself — not the restricted permissions the extension was originally given.

# Conceptual attack flow (not exploit code)
# Extension declares a rule targeting Gemini's panel context:
{
  "id": 1,
  "priority": 1,
  "action": {
    "type": "modifyHeaders",
    "responseHeaders": [
      { "header": "Content-Security-Policy", "operation": "remove" }
    ]
  },
  "condition": {
    "urlFilter": "gemini.google.com/app",
    "resourceTypes": ["sub_frame", "main_frame"]
  }
}
# When the Gemini panel loads gemini.google.com inside chrome://glic,
# the rule fires against the WebView context, not just a standard tab.
# JavaScript injected here inherits panel-level browser privileges.

What an Attacker Gets Once Inside

The consequence of executing code inside the Gemini panel's context is not abstract. Chrome deliberately grants the Gemini Live panel elevated access to browser-level capabilities so that it can perform the multi-step AI tasks it was designed for: summarizing web pages, reading documents, interpreting screen content, and engaging in voice conversations. Those capabilities require real hardware and file system access. They do not require user confirmation once the panel has been opened, because the panel itself is already trusted.

An attacker with arbitrary code execution in that context could, according to Palo Alto Networks Unit 42's published research, access the victim's camera and microphone without triggering any additional permission prompts, take screenshots of any open website or browser tab, read and interact with files on the local operating system, and inject phishing content directly into what the user sees as a legitimate, trusted Gemini interface. That last capability is particularly concerning. A phishing message delivered through the Gemini panel carries the full visual authority of a trusted browser component. The victim has no obvious reason to doubt what they are seeing.

Weizman told The Register that the Gemini app's legitimate need for system resources is precisely what made hijacking its panel so dangerous: the attacker inherits capabilities the extension was never supposed to have. — Gal Weizman, Palo Alto Networks Unit 42, published March 2, 2026

It is worth being precise about what confirmed exploitation would have meant in practice. The access gained through this vulnerability is not the same as a full system compromise. An attacker cannot install malware, escalate to root, or persist across reboots through this vector alone. What they can do is conduct high-fidelity surveillance: live camera and microphone feeds, real-time screenshots, and local file browsing — all from within a browser session, all without triggering any permission dialog the victim would see after the extension was installed.

There is an important UX security question here that has gone unasked in the broader coverage: does a user have any visual indication when the Gemini panel is using the camera or microphone versus when injected code is using those same capabilities? The honest answer is no, not in a way that distinguishes the two. The Gemini panel's camera and microphone access is granted at the panel level as a standing capability. When the panel has those privileges, the operating system's camera indicator light may activate when the camera is accessed — but that indicator does not tell the user whether Gemini or injected code is the agent doing the accessing. A user who has opened the Gemini panel and consented to camera access for an AI task has no native mechanism to distinguish that legitimate access from malicious code that has inherited the same privileges through CVE-2026-0628. This visibility gap is not unique to Glic Jack — it is an architectural property of how the panel's capabilities are currently scoped. It persists after the patch, because the patch closed the access vector but did not change the per-session capability model. That is one of the structural problems the "Runtime permission scoping" solution discussed below is specifically designed to address.

There is one additional capability that standard coverage has underemphasized: persistent hidden prompts. Because the injected code runs inside the Gemini panel's privileged context and has access to the panel's interaction model, an attacker could embed hidden instructions into the panel's operating environment — instructions that persist as long as the panel session is active and that the user cannot see. In a summarization-only Gemini panel, this is a surveillance and influence risk. In an agentic auto browse context, this becomes a command injection risk: hidden prompts that direct the AI to take specific actions (navigate to a URL, extract and transmit data, modify a form before submission) could be planted through the compromised panel and executed autonomously. This attack path is distinct from indirect prompt injection through web content because it originates inside the trusted panel context rather than from untrusted page content. Neither Google's User Alignment Critic nor Agent Origin Sets was designed with this specific vector in mind; both are architected to catch adversarial content coming from untrusted external sources, not from a compromised internal execution context.

The Bigger Picture: AI Features as New Attack Surfaces

CVE-2026-0628 did not happen in a vacuum. It happened because the browser industry is in the middle of a fundamental architectural shift. For years, browsers were primarily document viewers with JavaScript engines bolted on. They became application platforms. Now they are becoming agentic platforms — environments where AI components are granted standing access to hardware, file systems, and browsing context so that they can take actions on users' behalf without step-by-step prompting. Unit 42 uses the term "agentic browser" or "AI browser" to describe this emerging category, which currently includes Gemini Live in Chrome, Microsoft Copilot in Edge, and standalone products like Atlas and Comet.

That shift creates a structural security problem that CVE-2026-0628 illustrates clearly. When you build a new privileged component into a browser — one that by design has access to camera, microphone, local files, and the ability to observe every open tab — that component becomes the highest-value target in the entire browser surface. It concentrates capability in one place. Any policy enforcement mistake around it carries outsized consequences, because breaching it does not just compromise a tab or a domain; it compromises everything the AI component can touch.

The speed of that risk materialization is striking. Gemini in Chrome began its initial rollout to Google AI Pro and Ultra subscribers in the U.S. on May 21, 2025 — the day after Google I/O — and then expanded to all free desktop users in the U.S. on September 18, 2025, as confirmed by Google's own announcement. According to Unit 42's published research, the architectural gap was identified and disclosed on October 23, 2025, less than five weeks after free-user general availability. NIST's National Vulnerability Database describes the core flaw as an insufficient policy enforcement failure in Chrome's WebView tag that allowed a crafted extension to inject scripts or HTML into a privileged page — the authoritative technical anchor for what CVE-2026-0628 actually is.

One dimension of enterprise exposure that deserves more attention than it typically receives: managed Chrome deployments in enterprise environments do not behave like consumer Chrome. Administrators can push extensions silently to employee devices through Google Workspace policies, bypassing the user-facing extension install prompts entirely. An attacker who compromises an organization's extension distribution pipeline — or who socially engineers an IT administrator into deploying a trojanized extension — does not need to rely on individual users installing anything. The malicious extension lands on every managed endpoint automatically. In that scenario, the prerequisite for CVE-2026-0628 (a user installing a malicious extension) dissolves into a supply-chain and IT governance problem with much larger blast radius than individual consumer exposure. This is precisely why Gal Weizman stated to Dark Reading that the risk profile was "significantly amplified within business and organizational environments."

Weizman warned that embedding AI components in the high-privilege browser context opens the door to XSS, privilege escalation, and side-channel attacks from less-privileged extensions or websites — risks that did not exist before the browser became an agentic platform. — Gal Weizman, Palo Alto Networks Unit 42, published March 2, 2026

This dynamic is not unique to Google. Microsoft's Copilot integration in Edge, Apple's browser-level AI features, and any future browser that embeds an agentic AI sidebar face the same architectural challenge. They must grant the AI component enough privilege to be useful, and they must then correctly defend every boundary around it against every lower-trust component in the browser ecosystem. Chrome missed one boundary with the Gemini panel. There is no reason to assume similar gaps do not exist elsewhere in similar implementations.

The downstream exposure of CVE-2026-0628 makes this concrete rather than theoretical. Because Microsoft Edge is Chromium-based, it ingests the same upstream engine Google patched. Microsoft recorded CVE-2026-0628 in its own Security Update Guide so that Edge customers would have an authoritative downstream patch status for their builds. Edge customers on unpatched builds were exposed through the same Chromium WebView policy gap, not through any independent Microsoft engineering failure — but exposed nonetheless. The patch cadence for Edge and Chrome are not synchronized; organizations running Edge in enterprise environments needed to verify their build independently rather than assuming Chrome's January patch applied to them. This is the Chromium supply-chain dynamic in practice: one upstream vulnerability becomes a downstream patching coordination problem across every Chromium consumer simultaneously. Electron applications and embedded WebView2 runtimes used by enterprise software are in the same position and have no automatic update mechanism comparable to Chrome's.

Unit 42 framed their research under the headline "Taming Agentic Browsers" for a reason. The vulnerability is specific to Chrome and Gemini. The structural risk it demonstrates is industry-wide.

There is also a broader pattern worth naming: attackers are not waiting for defenders to catch up to AI-integrated tooling. On February 19, 2026, ESET researcher Lukáš Štefanko published analysis of a newly discovered Android malware family named PromptSpy — the first known case of Android malware using Google's Gemini generative AI model at runtime in its execution flow. PromptSpy's primary function is a built-in VNC module that gives operators full remote access to the victim's device, including the ability to capture lockscreen PINs, record the screen, and intercept passwords. The Gemini integration serves one specific purpose within that broader framework: persistence. The malware sends an XML dump of the device's live UI to the Gemini API and receives JSON-formatted tap and swipe instructions in return, allowing it to pin itself in Android's recent apps list on any device, regardless of manufacturer or OS version. Traditional Android malware relies on hardcoded screen coordinates that break across different device layouts; by delegating that UI navigation to Gemini, PromptSpy removes that limitation. ESET noted it had not yet observed PromptSpy in its telemetry as of publication — suggesting it may still be at proof-of-concept stage, though the existence of dedicated distribution infrastructure indicated real-world deployment intent. The malware has never appeared on Google Play, and ESET shared its findings with Google through the App Defense Alliance; Google Play Protect automatically protects Android users against known versions. While the Gemini integration covers only one feature in PromptSpy's code, ESET's Štefanko noted it demonstrates how generative AI can make malware "far more dynamic and capable of real-time decision-making" by adapting to virtually any device or screen layout. The combination of AI-as-target (as CVE-2026-0628 illustrates) and AI-as-attack-tool (as PromptSpy illustrates) represents a genuinely new threat surface that existing security frameworks were not designed to handle.

The Question Nobody Is Asking Loudly Enough

Here is the question that the standard coverage of CVE-2026-0628 mostly sidesteps: if this policy enforcement gap existed from the moment the Gemini panel was built, what does that say about the security review process for new chrome:// surfaces?

Chrome's Manifest V3 extension platform was built, at considerable cost to the developer community, partly on the premise that declarative APIs like declarativeNetRequest are safer than imperative ones because they limit what extensions can observe and modify. That premise is not wrong. But CVE-2026-0628 shows that the "safer" API can still be catastrophic if the boundary of what it cannot touch was never explicitly drawn around a new privileged surface. MV3 reduced the surface for abuse inside standard tab contexts. It said nothing about AI panels that did not exist when MV3 was designed.

This is a category of gap that will recur every time a browser adds a new high-privilege component without simultaneously auditing every extension API against it. The question security teams and policy researchers should be asking is not only "was this specific bug fixed?" but "what is the process by which new chrome:// surfaces are evaluated against the full extension API surface before they ship?" The publicly available record does not describe such a process. If one exists inside Google, it did not catch this gap. If one does not exist as a formal gate, it needs to.

There is a related and equally underexplored question about the Chrome Web Store's role. The Web Store's extension review process is designed to catch malicious behavior in submitted extensions. It is not designed to catch extensions that are benign at submission and later become attack vectors because a new privileged browser surface was introduced. An extension holding declarativeNetRequest and *.google.com host permissions would have passed review at any point in the past two years. It only became a Glic Jack vector after September 18, 2025. That retroactive risk transformation — where a legitimate permission set becomes dangerous because something upstream changed — is not currently reflected in how browser vendors think about or communicate extension risk to users.

There is a compounding factor the industry almost never discusses: extension ownership transfer. Well-reviewed, widely-installed extensions are regularly acquired by third parties, sometimes without any visible notification to users. The new owner inherits the original extension's trust reputation, its install base, and its permission set. An acquired extension holding declarativeNetRequest and *.google.com permissions would carry everything needed to execute a Glic Jack-class attack on day one under its new owner. Users have no native mechanism to discover that the extension they trusted for three years is no longer operated by its original developer. The Chrome Web Store does not require disclosure of ownership transfers or mandate re-review when ownership changes hands. This is a supply-chain problem nested inside the extension trust model, and CVE-2026-0628 is precisely the scenario where it produces the worst outcomes.

Finally, and perhaps the question with the longest tail: what happens when the Gemini panel stops being a summarization tool and becomes a fully agentic browser that can navigate sites, fill forms, and complete purchases on your behalf — features Google has explicitly announced are coming? The access model for an agentic AI browser is categorically more dangerous than a summarization panel. An agent that can take actions needs permissions that mirror what a human user can do in the browser. Any policy enforcement gap around that agent is not just a surveillance risk. It is an execution risk. An attacker who can inject code into a fully agentic AI context could not just observe what you do — they could instruct the AI to act on your behalf. Glic Jack is the warning shot for that future.

Auto Browse Is Already Live: The Stakes Just Changed

One of the central arguments in most coverage of CVE-2026-0628 — including in the original Unit 42 research — frames the agentic browser future as something on the horizon: capabilities coming soon, risk that will escalate when they arrive. That framing aged quickly. On January 28, 2026, three weeks after the CVE-2026-0628 patch shipped, Google launched Chrome auto browse — a full agentic capability powered by Gemini 3 that can navigate websites, fill forms, compare prices across multiple tabs, schedule appointments, file expense reports, and complete multi-step tasks on the user's behalf. It is available now to Google AI Pro and Ultra subscribers in the U.S. The risk that Glic Jack was framed as a preview of is not hypothetical anymore.

Auto browse operates from the same persistent sidebar architecture that made CVE-2026-0628 possible. It uses Chrome's password manager for credential-based tasks (with explicit user authorization), and it processes page content via Google's cloud infrastructure. Critically, auto browse has access to the same hardware and file system capabilities that the Gemini panel used for summarization — but it also now takes autonomous actions. The distinction that made Glic Jack primarily a surveillance risk — an attacker could observe but not easily act — largely collapses in an agentic context. An attacker who can inject code into an agentic Chrome panel that has been granted auto browse permissions is no longer a passive observer. They can potentially direct the AI to act.

Google did publish its security architecture for auto browse in December 2025, and it is worth examining carefully — both for what it addresses and for what it does not. The primary announced defense is a User Alignment Critic: a second Gemini model that runs after the planning phase is complete, isolated from untrusted page content, whose job is to evaluate whether each proposed action actually aligns with what the user asked for. If it determines an action does not match the user's intent, it rejects the action and the planning model reformulates. Repeated failures return control to the user. This is a meaningful addition to the architecture. It is also a probabilistic defense against a class of attack that is fundamentally adversarial — attackers building against it will probe its failure modes.

The second major announced defense is Agent Origin Sets: an extension of Chrome's existing origin-isolation capabilities that limits which sites the agent can read from and act on to those directly relevant to the task. A gating function categorizes origins into read-only (Gemini can consume content from them) and read-writable (the agent can also type and click). This limits cross-site data exposure and reduces the blast radius if a compromised agent tries to interact with unrelated logged-in sites. It directly addresses what Google identified as the primary new threat: indirect prompt injection, where malicious instructions embedded in a web page, an iframe, or user-generated content (a product review, a restaurant listing, a social media post) attempt to hijack the agent's actions.

To be precise about the threat taxonomy: indirect prompt injection and the CVE-2026-0628 extension-based vector are two distinct attack categories that now coexist in the same browser surface. Glic Jack was an extension-based privilege escalation: an installed extension exploiting a policy enforcement gap to gain the panel's capabilities. Indirect prompt injection is a content-based agent hijack: malicious instructions embedded in web content that the agent reads and then acts on. The two converge at a concerning intersection. An extension that has compromised the panel context could theoretically plant instructions in a form that the agent reads and executes, combining both attack vectors. That compound threat is not documented in the existing CVE-2026-0628 research because it requires the agentic capability to be present — which it now is. OWASP's 2024 assessment of production AI deployments found prompt injection in 73% of systems evaluated, ranking it the top risk in its threat list for large language model applications. The UK's National Cyber Security Centre has stated that prompt injection may never be fully mitigated because LLMs cannot reliably distinguish between instructions and data. Chrome's User Alignment Critic is a serious attempt at mitigation. "Serious attempt" and "solved" are different categories.

Gartner's posture on this is worth naming directly. The research firm has advised enterprises to block AI browsers in their environments until the associated risks — indirect prompt injection, erroneous agent actions, and organizational data loss — can be appropriately managed. Gartner also flagged a specific enterprise scenario that most security coverage ignores: employees may be tempted to use browser AI agents to automate tasks that are technically mandatory, including compliance workflows and required cybersecurity training. An AI agent completing mandatory security training on an employee's behalf is not a hypothetical edge case. It is the kind of governance gap that emerges naturally when agentic capability is given to users before organizational policy frameworks have caught up. The patch for CVE-2026-0628 closed the specific door Glic Jack opened. The category of risk it represents — agentic AI as attack surface and governance problem simultaneously — is now fully in production.

"The primary new threat facing all agentic browsers is indirect prompt injection." — Nathan Parker, Chrome security engineer, published December 8, 2025

Google patched CVE-2026-0628 on January 6, 2026, with the stable channel release of Chrome 143.0.7499.192 for Linux and 143.0.7499.193 for Windows and macOS. The fix addresses the policy enforcement gap by ensuring that <webview> components embedded within privileged browser surfaces are explicitly excluded from extension-driven declarativeNetRequest rule application. The Extended Stable Channel for Windows and macOS received the fix in version 142.0.7499.265. Chrome for Android also received the fix in version 143.0.7499.193, as Google confirmed.

Google patched CVE-2026-0628 on January 6, 2026, with the stable channel release of Chrome 143.0.7499.192 for Linux and 143.0.7499.193 for Windows and macOS. The fix addresses the policy enforcement gap by ensuring that <webview> components embedded within privileged browser surfaces are explicitly excluded from extension-driven declarativeNetRequest rule application. The Extended Stable Channel for Windows and macOS received the fix in version 142.0.7499.265. Chrome for Android also received the fix in version 143.0.7499.193, a detail that most security coverage has not emphasized: the Gemini panel is available on Android, and Android users who had not updated since before the January patch were in-scope. Google's bug bounty reward for the discovery was listed as to-be-determined at the time of initial disclosure and had not been publicly finalized as of the date of Unit 42's March 2 publication.

As of the time of writing, there is no confirmed evidence of CVE-2026-0628 being exploited in active attacks. Google's Chrome Releases blog entry does not include the "exploited in the wild" language that typically accompanies confirmed zero-day exploitation. The vulnerability is not listed in CISA's Known Exploited Vulnerabilities catalog. However, at least one public proof-of-concept repository has been indexed in VulnCheck's exploit database, referencing a GitHub repository explicitly named as a CVE-2026-0628 PoC. That matters operationally: a PoC in the wild lowers the bar for opportunistic attackers who did not independently discover the flaw. The standard assumption that "no confirmed exploitation" equals low urgency does not hold when a realistic precondition (extension installation), a high-value target (panel-level privileges), and indexed PoC code coexist simultaneously. The window between responsible disclosure and opportunistic abuse compresses substantially once PoC code is publicly searchable.

For individual users, the action is straightforward: verify Chrome is on version 143.0.7499.192 or later by navigating to chrome://settings/help. Chrome updates automatically, but auto-update does not always apply immediately, particularly on managed enterprise systems where updates are staged.

For enterprise security teams and administrators, the response should go beyond patching:

• Audit all installed Chrome extensions across the organization and flag any that hold declarativeNetRequest permissions combined with host permissions covering *.google.com or AI-related domains.
• Implement extension allowlisting policies. Extensions should be explicitly approved, not passively permitted because no one blocked them.
• Monitor for <webview> process spawns originating from extension contexts that target AI panel URLs, and watch for unexpected camera or microphone permission grants tied to Gemini-related origins.
• Treat browser AI integrations as privileged endpoints in your security architecture, subject to the same scrutiny as any other high-privilege system component.
• Review extension governance policies with the assumption that future AI browser integrations will introduce new high-privilege surfaces that will need to be explicitly protected.
• Do not limit your Chromium patch audit to Chrome and Edge. Inventory Electron applications and embedded WebView2 runtimes in your environment and verify their bundled Chromium versions independently. These do not auto-update with the browser and represent a persistent exposure window that most enterprise patch management tooling does not cover without explicit configuration.
• If you manage Chrome through Google Workspace policies, review your extension deployment pipeline for supply-chain risk. Extensions pushed silently via policy bypass user-facing install prompts entirely; a compromised extension in that pipeline reaches all managed endpoints without any individual user action.

Deeper Solutions: Beyond the Point Patch

Patching Chrome closes the specific door CVE-2026-0628 opened. It does not close the category of risk. The vulnerability class — new privileged browser surface created without auditing the extension API boundary — will recur unless something structural changes. And with auto browse now live, the stakes for getting structural solutions right have materially increased. Here is where the conversation should go beyond standard guidance, and beyond what has been publicly proposed so far — including what Google has already announced.

A formal privileged surface registry for new chrome:// contexts. Every new chrome:// URL or internal browser component should require a pre-ship security review that explicitly enumerates which extension APIs can reach it. That list should be maintained as a living document and updated whenever a new extension API is added. CVE-2026-0628 happened because chrome://glic did not exist when the existing rejection logic was written, and nobody went back to recheck. A registry with explicit inclusion/exclusion logic would have made that gap visible before the feature shipped publicly. This is the structural gap that Glic Jack exposed. Google's announced defenses (User Alignment Critic, Agent Origin Sets) address the threat model for agentic browsing but do not address this upstream gap in the extension isolation framework itself.

Evaluating Google's User Alignment Critic honestly. The User Alignment Critic is the most sophisticated defense Google has publicly described for auto browse, and it deserves careful assessment rather than uncritical praise or dismissal. The concept — a second model, isolated from untrusted content, that independently evaluates whether each planned action matches user intent — is architecturally sound. The limitation is that it is a probabilistic defense against an adversarial problem. Attackers who study the critic's behavior can probe for input combinations that pass validation while achieving malicious outcomes. Google acknowledges this: the critic "substantially increases the complexity, cost, and sophistication required for an attacker to succeed" rather than eliminating the risk. What this design does not address is the CVE-2026-0628 vector specifically — an extension that has already compromised the panel context can potentially generate actions or content that the critic then evaluates as legitimate, because the injection happened upstream of the critic's observation point. The solution to that problem requires the extension isolation fix, not a second model.

Evaluating Agent Origin Sets honestly. Agent Origin Sets is a meaningful improvement to the site isolation model for agentic contexts. Limiting the agent to reading from and acting on origins relevant to the current task reduces the cross-site blast radius significantly. The mechanism — a gating function that categorizes task-relevant origins as read-only or read-writable before navigation begins — is a genuine architectural constraint, not just a policy rule. The limitation is that the gating function itself must correctly identify which origins are task-relevant. An attacker crafting an indirect prompt injection through a malicious site that appears to be task-relevant could potentially include that site in the read-writable set. The origin control reduces the attack surface; it does not eliminate adversarial exploitation of the origin classification process. These defenses are better than nothing — they are substantially better than nothing — but treating them as a solved problem before they have faced adversarial pressure in production would be a mistake.

Process isolation for AI components as defense-in-depth. Chrome's architecture already uses separate renderer processes for tabs and extensions to limit blast radius. A fully isolated process for AI sidebar components — with its own capability whitelist that does not inherit from the extension renderer process space — would structurally prevent an extension from reaching across the trust boundary, rather than relying on policy rules being correctly applied. This is a harder engineering investment but provides defense-in-depth that point patches cannot. The User Alignment Critic and Agent Origin Sets operate within the existing process architecture. Process isolation would change the architecture so that a future CVE-2026-0628-class gap cannot produce the same outcome even if the policy gap recurs. Microsoft Edge's Copilot panel faces the same architectural question, and there is no public indication that either vendor has adopted this approach.

Runtime permission scoping for AI panel capabilities. Currently, the Gemini panel's access to camera, microphone, and local files is granted at the panel level as a standing capability. An alternative design would scope those capabilities per-session and require the user to explicitly grant them for each new session, similar to how mobile operating systems now require per-use permission grants rather than install-time blanket access. This would not have prevented CVE-2026-0628's mechanism, but it would have limited the damage window: an attacker injecting code into the panel context would only inherit capabilities the user had actively granted in that session, not the full standing capability set. Auto browse's confirmation gates for sensitive actions (purchases, password use, social media posts) are a step toward this model but they apply to agent actions, not to hardware capability grants. The two are separate concerns that need separate policies.

Retroactive permission risk signaling in the Web Store. When a new privileged browser surface ships, the Web Store should have a mechanism to flag existing extensions whose permission sets are now potentially relevant to that surface — even if those extensions were not malicious at the time of review. This is technically complex, but the alternative is the current situation: users holding extensions with declarativeNetRequest and *.google.com permissions who have no idea their extension became a potential attack vector the day Gemini in Chrome hit general availability. Proactive notification is better than silence. With auto browse now live and the agentic attack surface meaningfully larger than it was in September 2025, this becomes more urgent, not less.

Mandatory CTA-style sharing for browser-native AI feature vulnerabilities. Unit 42 shared its findings with the Cyber Threat Alliance before publication, enabling other CTA members to deploy protections rapidly. That coordination was voluntary and commendable. Browser vendors should formalize a similar process: when a vulnerability in a browser-native AI component is patched, the technical details should be shared with a defined set of enterprise security vendors under coordinated disclosure terms, so that endpoint detection rules and SIEM signatures exist by the time public technical details are released. The current cadence — patch ships, then details drop, then the security industry starts building detections — leaves an unnecessary gap between disclosure and defense.

None of these solutions are simple. Some require changes to Chrome's architecture that would take multiple release cycles to implement. But the pattern of retrofitting security onto new AI features after a vulnerability is found is not sustainable at the pace Google, Microsoft, and Apple are building browser-native AI capabilities. Auto browse is already live. The structural conversation needs to be happening at the same pace as the feature roadmap — not trailing it by a full product cycle.

There is also a Chromium ecosystem problem that extends far beyond Chrome and Edge. Electron applications — including widely deployed enterprise tools like Slack, VS Code, and Teams — and embedded WebView2 runtimes used by enterprise line-of-business applications all run Chromium under the hood. When a Chromium vulnerability like CVE-2026-0628 is patched upstream, those applications do not automatically inherit the fix. They must actively update their bundled Chromium version and ship a new release. Enterprise teams that patched Chrome and Edge in January 2026 may still be running vulnerable Chromium inside Electron apps months later without knowing it. If any of those Electron applications expose a WebView surface with elevated privileges, the architectural gap that Glic Jack exploited is potentially present there too. Chromium-based AI integrations are not limited to standalone browsers, and the extension API boundary problem does not stop at the browser window.

Key Takeaways

1. The vulnerability was architectural, not incidental: CVE-2026-0628 was not a random coding error. It was a gap between where Chrome's extension isolation policy ended and where the Gemini panel's elevated privileges began. That gap existed because the new Gemini panel introduced a new type of privileged surface that the existing policy framework had not been updated to cover.
2. Low permissions plus a high-privilege target equals a high-severity outcome: An extension with entirely ordinary, widely approved permissions was sufficient to exploit this vulnerability. The CVSS 8.8 score reflects the severity of what a successful attacker could access — camera, microphone, local files, screenshots, and phishing capability inside a trusted interface — not the complexity of the attack itself.
3. AI browser integrations are now a primary target class: Any AI feature that is granted standing access to hardware and the file system inside a browser is a high-value target. CVE-2026-0628 is the first well-documented example of that target being reached through an extension-based attack. It will not be the last.
4. Extension hygiene is not optional: The precondition for this attack was a user installing a malicious extension. Patching closes the vulnerability, but it does not remove the social engineering risk that enabled it. Organizations that treat extension installation as a user preference rather than a security boundary are accepting ongoing exposure to future variants of this class of attack. In enterprise managed Chrome environments, the precondition shifts: it becomes an IT governance and supply-chain problem, not an end-user behavior problem.
5. Responsible disclosure worked here: Google's Chrome Releases blog, NIST NVD, and all contemporaneous sources record the report date as November 23, 2025. Unit 42's published research states October 23, 2025 as the disclosure date; no other source corroborates that earlier date. Regardless of which date is precise, Google reproduced the conditions, worked with Unit 42 on remediation, and issued a fix on January 5–6, 2026 — before public technical details were released. That is the coordinated disclosure process functioning as designed. Unit 42 waited for the patch to ship before publishing the research on March 2, 2026.
6. The Chromium supply chain extends beyond Chrome: Microsoft Edge had to independently ingest and ship the upstream Chromium fix; Microsoft recorded CVE-2026-0628 in its own Security Update Guide for exactly this reason. But Edge is not the end of the chain. Electron applications and embedded WebView2 runtimes — which run Chromium under the hood without automatic patch inheritance — represent a persistent exposure window that enterprise patch management commonly misses. Any Chromium consumer that embeds a privileged WebView surface faces the same class of risk.
7. Extension ownership transfers are an unaddressed supply-chain gap: A well-reviewed extension holding the permissions needed for a Glic Jack-class attack can be silently acquired by a new owner with no mandatory re-review and no notification to users. The Chrome Web Store does not require disclosure of ownership changes. CVE-2026-0628 makes this gap directly exploitable: the precondition for the attack is a trusted permission set, and trusted permission sets can be inherited through acquisition.
8. The agentic present raises the stakes dramatically: The Gemini panel as it existed at the time of CVE-2026-0628's discovery was primarily a summarization and Q&A tool. On January 28, 2026 — three weeks after the patch shipped — Google launched Chrome auto browse: a fully agentic capability that navigates websites, fills forms, uses saved passwords, and completes multi-step tasks autonomously. That capability is now live for paid subscribers in the U.S. When an agentic AI can take actions, any policy enforcement gap around that AI component transforms from a surveillance risk into an execution risk. An attacker who can inject code into a fully agentic context can direct the AI to act, not just observe. Google has published architectural defenses for auto browse (User Alignment Critic, Agent Origin Sets), and these are meaningful. They are also probabilistic defenses against adversarial pressure that has not yet arrived in force. Glic Jack is the proof of concept for a threat category that is no longer on the roadmap. It has shipped.

Štefanko observed that because PromptSpy delegates UI navigation to Gemini rather than hardcoding screen coordinates, it can operate across virtually any device or OS version — expanding the attacker's pool of viable targets beyond what traditional malware could reach. Paraphrased from Lukáš Štefanko, ESET researcher, published February 19, 2026

CVE-2026-0628 is patched. Chrome users who are current are protected. But the vulnerability leaves behind a more durable lesson: every time a browser adds a new AI component with elevated access to hardware and the file system, it adds a new target. And with Chrome auto browse now live — an AI that takes actions, not just answers — that target is materially more valuable to an attacker than it was the day Glic Jack was discovered. Security teams need to treat agentic browser components the way they treat any other privileged endpoint: with explicit access controls, active monitoring, and the assumption that someone is already looking for the gap between where the policy ends and where the privileges begin. A researcher found that gap within ten weeks of general availability. The next one will not be slower.

One additional detail in Unit 42's disclosure is worth noting for defenders: Palo Alto Networks shared its technical findings with fellow members of the Cyber Threat Alliance (CTA) before publishing the research publicly. CTA members use shared threat intelligence to deploy protections across their respective customer bases more rapidly than any single vendor could achieve alone. That coordination is part of what distinguishes responsible disclosure done well from responsible disclosure done by the numbers. It is also the model that should be formalized, not left to the voluntary goodwill of individual researchers and vendors, as browser-native AI capabilities continue to ship at the current pace.