Chrome Gemini CVE-2026-0628 Extension Flaw

CVE-2026-0628 let a Chrome extension affect Gemini’s privileged WebView through DNR; update Chrome to 143.0.7499.192 or later.^{[1], [3], [5]}

CVSS vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H^[3]

💡 Plain English Explainer (ELI5)

Think of Gemini Live as a public service counter inside a library, with a staff-only door behind it. Chrome blocked extensions from entering through that door, but a delivery-routing rule could still swap a script at the Gemini counter. The script ran at that embedded counter, which had a service hatch for requesting browser capabilities. CVE-2026-0628 was the missing check on that delivery route.^{[2], [5]}

Core Concepts & Subsystem Terms

Privileged WebView: A web page embedded in a browser-owned surface that can communicate with browser capabilities unavailable to ordinary websites.^{[2], [5]}
declarativeNetRequest (DNR): A Chrome extension API that applies declarative rules to matching network requests, including redirects and response-header changes.^{[2], [6]}
CVE-2026-0628: Google's High-severity Chrome flaw: insufficient policy enforcement in the WebView tag before Chrome 143.0.7499.192.^{[3], [4]}
BragJack / prompt forcing: A September 2026 research report describing extension-driven control of browser AI agents. It is a research label, not another CVE for Chrome.^{[2], [4]}

Framework mappings

CWE reference for the weakness described in this guide: CWE-862

Root Cause Analysis

Google describes CVE-2026-0628 as insufficient policy enforcement in Chrome's WebView tag. Forever Security's technical disclosure says Gemini Live used a browser-owned chrome://glic page embedding gemini.google.com in a WebView. Chromium rejected extension interaction with the privileged page itself, but the reported gap let an extension with declarativeNetRequest (DNR) influence matching HTTPS requests made by the embedded page. The researcher describes changing response headers and substituting a script so code could execute in the embedded Gemini origin, then interact with the browser-agent bridge. This could cross from ordinary extension privileges into capabilities exposed to the privileged panel. The report demonstrates access to page context, local-file content and screenshots, and describes possible camera/microphone access; treat these as researcher-reported impact, not evidence of exploitation in the wild. The published CVE requires a user to install a malicious extension. Google fixed the WebView policy boundary in Chrome 143.0.7499.192/.193 for Windows/macOS and .192 for Linux. The public Chromium fix confirms the boundary: RulesetManager returns false when request.is_web_view is true, before the existing allow decision. Chromium added ChromeSignInWebViewTest.DeclarativeNetRequestRulesNotMatched; the test skips MPArch, so that architecture is not covered by this regression test.^{[3], [2], [5], [4]}

Step-by-Step Attack Flow

Step 1

Confirm the preconditions

The reported Chrome path requires an affected Chrome build and a malicious or compromised extension installed by the user with DNR and matching host permissions. This is not a drive-by webpage-only attack.^{[3], [2], [6]}

Step 2

Open the browser-owned agent surface

Gemini Live uses the chrome://glic browser page and embeds the Gemini web app in a WebView. The browser page can invoke capabilities that an ordinary web page cannot.^[2]

Step 3

Cross the WebView request boundary

The researcher reports that DNR rules could affect HTTPS resources loaded within the embedded WebView, despite restrictions on extension interaction with the privileged surface.^{[2], [5]}

Step 4

Reach privileged page behavior

By changing response policy and the code loaded in the Gemini origin, the demonstrated chain could communicate with the browser-agent bridge. The researcher reports local-file and screenshot access; no public evidence establishes in-the-wild exploitation.^{[2], [3]}

Step 5

Patch and reduce extension exposure

Google's fix is in Chrome 143.0.7499.192/.193 depending on platform. Upgrade to the current stable build and restrict extensions that receive broad host and DNR permissions.^{[1], [3], [5]}

Source Code: Flaw vs. Secure Implementation

This is the upstream Chromium C++ change, not a reconstructed exploit. It adds a deny check for WebView-originated requests before the existing allow decision, preventing Declarative Net Request rules from matching them. Chromium also added ChromeSignInWebViewTest.DeclarativeNetRequestRulesNotMatched; that browser test skips MPArch, so it does not establish coverage for that architecture.^[5]

UNPATCHED FLAW

// Excerpt: extensions/browser/api/declarative_net_request/ruleset_manager.cc
// Before the fix, this final decision had no WebView-origin check.
return true;

HARDENED SECURE PATCH

// Excerpt: extensions/browser/api/declarative_net_request/ruleset_manager.cc
// Chromium change 9722f06a, before the existing final allow:
// Declarative Net Request rules should not be matched against requests
// originating from WebViews.
if (request.is_web_view) {
  return false;
}
return true;

Engineering & System Hardening Checklist

✓Upgrade all managed Chrome channels and operating systems to a current stable release; 143.0.7499.192/.193 is the first fixed release listed by Google.^{[1], [3]}
✓Inventory extensions with declarativeNetRequest and broad host permissions; remove unapproved or unused extensions and prefer managed allowlists.^{[6], [2]}
✓Do not treat a privileged browser page's URL as sufficient isolation when it embeds web origins; apply extension policy to the full embedded request context.^{[2], [5]}
✓Add browser tests that assert extension redirects and header modifications cannot affect resources inside browser-owned privileged WebViews.^[5]
✓As a defense-in-depth rule for browser-agent integrations, keep privileged operations behind an origin-bound browser interface; validate message source, frame identity, request type, and user-consent state at each operation.^[2]
✓Distinguish the CVE from later BragJack research: the report's broader findings across other browsers do not mean those products share this CVE.^{[2], [4]}