Chrome Gemini 漏洞允许攻击者远程访问受害者的摄像头和麦克风
谷歌 Chrome 浏览器内置的 Gemini AI 助手被发现存在高危安全漏洞，该漏洞会使用户面临未经授权的摄像头和麦克风访问、本地文件被盗以及网络钓鱼攻击的风险 ，而所有这些攻击都不需要用户进行任何交互，只需启动浏览器内置的 AI 面板即可。
谷歌 Chrome 浏览器内置的 Gemini AI 助手被发现存在高危安全漏洞，该漏洞会使用户面临未经授权的摄像头和麦克风访问、本地文件被盗以及网络钓鱼攻击的风险 ，而所有这些攻击都不需要用户进行任何交互，只需启动浏览器内置的 AI 面板即可。
该漏洞编号为 CVE-2026-0628，由 Palo Alto Networks 旗下 Unit 42 的研究人员发现，并于 2025 年 10 月 23 日负责任地披露给了 Google。Google 在公开披露之前，于 2026 年 1 月 5 日确认了该问题并发布了补丁。
Chrome 浏览器中的 Gemini Live 属于日益壮大的“AI 浏览器”类别，这类浏览器将 AI 助手直接嵌入到浏览环境中。这些助手还包括 Edge 浏览器中的 Microsoft Copilot 以及 Atlas 和 Comet 等独立产品，它们以特权侧边栏的形式运行，能够提供实时网页摘要、任务自动化和上下文相关的浏览辅助功能。
由于这些人工智能面板需要“多模态”的用户屏幕视图才能有效运行，Chrome 赋予 Gemini 面板更高的权限，包括访问摄像头、麦克风、本地文件和屏幕截图功能。这种特权架构虽然赋予了它强大的功能，但也极大地扩大了浏览器的攻击面。
漏洞在于 Chrome 处理 declarativeNetRequest API 的方式。declarativeNetRequest API 是一种标准的浏览器扩展权限，允许扩展程序拦截和修改 HTTPS Web 请求和响应。该 API 被广泛用于合法用途，例如广告拦截。
研究人员发现 Chrome 处理对 https://gemini.google.com/app 的请求的方式存在一个关键区别 。当该 URL 在普通浏览器标签页中加载时，扩展程序可以拦截并向其中注入 JavaScript，但这并不会授予任何特殊权限。
但是，当相同的 URL 在 Gemini 浏览器面板中加载时，Chrome 会使用提升的浏览器级别功能来对其进行钩取。
允许访问摄像头和麦克风
一旦攻击者通过这种技术控制了 Gemini 面板，他们就可以在无需任何用户交互的情况下执行以下操作，受害者只需点击 Gemini 按钮即可。
| 攻击能力 | 影响 |
| 摄像头和麦克风激活 | 未经用户同意的静默监视 |
| 屏幕截图 | 泄露屏幕上的敏感数据 |
| 本地文件和目录访问 | 操作系统级文件被盗 |
| 通过可信面板进行网络钓鱼 | 高可信度欺骗攻击 |
由于 Gemini 面板是可信的浏览器集成组件，因此其网络钓鱼风险尤其危险。其中显示的恶意内容具有独立钓鱼页面所不具备的内在合法性。
由于安装恶意扩展程序需要一定的前提条件，因此基于扩展程序的攻击历来被认为风险较低。然而，特权人工智能面板的集成从根本上改变了这种局面。
近年来， 部署到浏览器应用商店的恶意扩展程序数量显著增长。许多扩展程序很快被移除，但在此之前已经影响了成千上万的用户。
此外，合法的扩展程序也被劫持或出售给威胁行为者，他们将恶意更新推送至已安装的终端，使受信任的工具变成了无声的武器。
在企业环境中，被入侵的扩展程序能够访问员工的摄像头、麦克风和本地文件，这构成严重的组织安全风险，并可能导致商业间谍活动和数据泄露。
谷歌在负责任地披露信息后，于 2026 年 1 月 5 日发布了修复程序。使用最新版 Chrome 的用户已受到保护。各组织应立即确保所有终端上的 Chrome 浏览器都已更新。
关于作者
评论1次
--- ### 结论 Chrome Gemini漏洞源于`declarativeNetRequest` API对`https://gemini.google.com/app`请求的特殊权限提升逻辑，攻击者可通过恶意扩展劫持Gemini面板的运行环境，绕过用户交互直接获取摄像头/麦克风访问权限。核心问题在于浏览器未对Gemini面板的扩展请求进行严格的权限隔离，导致高危攻击面暴露。 --- ### 分析路径 **L1 攻击面识别** - **Source-Sink链**： - **Source**：`declarativeNetRequest` API对Gemini面板请求的特殊处理逻辑（权限提升） - **Sink**：Gemini面板的`getUserMedia`、`screenCapture`、文件访问等敏感API - **权限差异**： - 普通标签页加载Gemini URL：仅基础权限，扩展可拦截但无法注入敏感代码 - Gemini面板加载相同URL：浏览器赋予“浏览器级别权限”，允许扩展通过API注入恶意JS并触发布局/媒体访问 **L2 假设与验证** - **假设1**：恶意扩展通过`declarativeNetRequest`拦截Gemini子请求，注入JS劫持面板行为 - 验证路径：检查扩展是否声明`declarativeNetRequest`与`gemini.google.com`匹配规则，并在响应中注入`navigator.mediaDevices.getUserMedia`调用 - **假设2**：权限提升后可绕过用户交互验证 - 验证路径：监控Gemini面板加载时的`MediaDevices`调用栈，确认是否存在无`user activation`触发的敏感API调用 **L3 边界/异常场景** - **扩展沙箱逃逸**：合法扩展被供应链污染后，利用Gemini的权限提升漏洞突破沙箱 - **跨域注入**：通过Gemini面板的高权限，突破同源策略访问其他标签页或文件xi统 - **静默持久化**：利用Gemini面板的常驻特性，在后台持续监听媒体设备状态 **L4 防御反推与修复** - **Chrome防御机制缺失点**： - 未对Gemini面板的`declarativeNetRequest`拦截行为实施白名单限制 - 未对敏感API调用强制要求用户交互（如`user gesture`检查） - **推测修复逻辑**： - 隔离Gemini面板的权限边界，强制其与扩展请求权限分离 - 为`getUserMedia`等API添加针对Gemini上下文的额外验证（如强制弹窗提示） --- ### 验证步骤 1. **检查扩展权限**： `chrome://extensions/permissions` 确认可疑扩展是否包含`declarativeNetRequest`和`https://gemini.google.com/*`的匹配规则。 2. **模拟请求拦截**： 使用开发者工具拦截Gemini面板的`/app`请求，注入测试代码验证是否可触发媒体设备访问（无需用户点击）： ```javascript navigator.mediaDevices.getUserMedia({ video: true }).then(() => console.log("权限被滥用")) ``` 3. **监控API调用链**： 在`chrome://media-internals`观察Gemini面板启动后的媒体设备调用记录，确认是否存在无用户交互的`active: true`状态。 4. **验证权限隔离修复**： 更新至Chrome 132+版本后，重复上述测试，确认`Gemini`上下文的API调用是否强制要求用户交互弹窗。 --- ### 修复建议 1. **用户层面**： - 立即升级Chrome至版本132+ - 禁用非必要扩展，尤其关注高权限请求`declarativeNetRequest`的第三方扩展 - 启用`chrome://flags/#enable-media-stream-security`强化媒体权限拦截 2. **企业防御**： - 部署扩展白名单策略，禁止未授权扩展访问`gemini.google.com` - 在组策略中配置： ``` --disable-gpu --disable-features=GeminiPanel ``` （若业务无依赖，直接禁用Gemini面板） 3. **开发加固**： - 对敏感API（如媒体访问、文件读取）强制要求`user gesture`验证 - 在`declarativeNetRequest`规则中为Gemini请求添加`exclude_matches`黑名单机制 --- 该漏洞暴露了AI浏览器助手类应用的权限设计缺陷——高功能需求与最小权限原则的矛盾需通过架构隔离强制解决。