Chrome CVE-2026-0628：Gemini WebView 漏洞

CVE-2026-0628 允许 Chrome 扩展通过 DNR 影响 Gemini 特权 WebView；请更新至 143.0.7499.192 或更高版本。^{[1], [3], [5]}

CVSS 向量

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

💡 通俗易懂的原理解析 (ELI5)

把 Gemini Live 想成图书馆里的公共服务柜台，柜台后面有一扇员工专用门。Chrome 阻止扩展穿过这扇门，但改道投递的规则仍可替换 Gemini 柜台加载的脚本。脚本运行在这个嵌入式柜台，而柜台设有可请求浏览器能力的服务通道。CVE-2026-0628 缺少的正是投递路径上的检查。^{[2], [5]}

核心概念与专有名词

特权 WebView: 嵌入浏览器自有界面的网页，可与普通网站无法使用的浏览器能力通信。^{[2], [5]}
declarativeNetRequest (DNR): Chrome 扩展 API，可对匹配的网络请求应用声明式规则，包括重定向和响应头更改。^{[2], [6]}
CVE-2026-0628: Google 定为高危的 Chrome 漏洞：Chrome 143.0.7499.192 之前，WebView 标签的策略执行不足。^{[3], [4]}
BragJack / prompt forcing: 2026 年 9 月发布的研究，描述扩展如何控制浏览器 AI 代理。这是研究名称，不是另一个 Chrome CVE。^{[2], [4]}

框架映射

本指南所述弱点的 CWE 参考： CWE-862

根本原因剖析 (Root Cause)

Google 将 CVE-2026-0628 描述为 Chrome WebView 标签的策略执行不足。Forever Security 的技术披露称，Gemini Live 使用浏览器控制的 chrome://glic 页面，并通过 WebView 嵌入 gemini.google.com。Chromium 会阻止扩展直接操作特权页面，但报告的漏洞允许具有 declarativeNetRequest (DNR) 权限的扩展影响嵌入页面发出的匹配 HTTPS 请求。研究者描述了更改响应头并替换脚本，使代码在嵌入的 Gemini origin 中执行，进而与浏览器 AI 代理桥接接口通信。这可能跨越普通扩展权限与特权面板功能之间的边界。报告展示了页面上下文、本地文件内容和屏幕截图访问，并描述了可能的摄像头/麦克风访问；这些是研究者报告的影响，并非野外利用证据。该 CVE 需要用户安装恶意扩展。Google 在 Windows/macOS 的 Chrome 143.0.7499.192/.193 和 Linux 的 .192 修复了 WebView 边界。 Chromium 公开的修复确认了这一边界：当 request.is_web_view 为 true 时，RulesetManager 会在原有放行判断前返回 false。Chromium 添加了 ChromeSignInWebViewTest.DeclarativeNetRequestRulesNotMatched；该测试跳过 MPArch，因此这个回归测试未覆盖该架构。^{[3], [2], [5], [4]}

攻击执行流程分解

步骤 1

确认前置条件

报告中的 Chrome 路径要求受影响版本，以及用户安装的恶意或被攻陷扩展，并具有 DNR 和匹配的主机权限。这不是仅靠访问网页即可触发的 drive-by 攻击。^{[3], [2], [6]}

步骤 2

打开浏览器自有的代理界面

Gemini Live 使用浏览器页面 chrome://glic，并在 WebView 中嵌入 Gemini Web 应用。该页面能够调用普通网站不可用的能力。^[2]

步骤 3

跨越 WebView 请求边界

研究者称，尽管扩展无法直接交互特权界面，DNR 规则仍可影响嵌入式 WebView 加载的 HTTPS 资源。^{[2], [5]}

步骤 4

触达特权页面行为

通过更改响应策略和 Gemini origin 加载的代码，演示链可以与浏览器代理桥接接口通信。研究者报告了本地文件和屏幕截图访问；目前没有公开的野外利用证据。^{[2], [3]}

步骤 5

修补并减少扩展暴露面

Google 按平台在 Chrome 143.0.7499.192/.193 中修复。请升级至当前稳定版，并限制获得广泛主机权限和 DNR 权限的扩展。^{[1], [3], [5]}

源代码对比：漏洞与安全实现

这是 Chromium 上游的 C++ 改动，不是重构的漏洞利用代码。它在原有放行判断前拒绝来自 WebView 的请求，避免 Declarative Net Request 规则匹配这些请求。Chromium 还添加了 ChromeSignInWebViewTest.DeclarativeNetRequestRulesNotMatched 浏览器测试；该测试跳过 MPArch，因此不能证明这一架构已覆盖。^[5]

存在漏洞的实现

// 代码片段：extensions/browser/api/declarative_net_request/ruleset_manager.cc
// 修复前，这个最终判定没有检查请求是否来自 WebView。
return true;

加固后的安全修复

// 代码片段：extensions/browser/api/declarative_net_request/ruleset_manager.cc
// Chromium 更改 9722f06a，位于原有的最终放行逻辑之前：
// Declarative Net Request 规则不应匹配
// 来自 WebView 的请求。
if (request.is_web_view) {
  return false;
}
return true;

工程与系统安全加固清单

✓将所有受管理的 Chrome 渠道和操作系统更新到当前稳定版本；Google 列出的首个修复版本是 143.0.7499.192/.193。^{[1], [3]}
✓盘点具有 declarativeNetRequest 和广泛主机权限的扩展；删除未经批准或闲置的扩展，优先使用集中管理的允许列表。^{[6], [2]}
✓当特权浏览器页面嵌入其他 origin 时，不要仅凭页面 URL 认定隔离充分；应针对完整嵌入请求上下文执行扩展策略。^{[2], [5]}
✓添加浏览器测试，确保扩展的重定向和响应头修改无法影响浏览器特权 WebView 内的资源。^[5]
✓作为浏览器代理集成的纵深防御规则，应将特权操作限制在绑定来源的浏览器接口后；每次操作都验证消息来源、frame 身份、请求类型和用户同意状态。^[2]
✓将该 CVE 与后续 BragJack 研究区分开：其他浏览器中的更广泛发现不代表它们共享此 CVE。^{[2], [4]}