2026 年 9 月 3 日,NVD(美国国家漏洞数据库)收录了一条编号为 CVE-2026-85046 的 Chromium 高危漏洞,CVSS 评分 8.8。Google Chrome 在 9 月 4 日发布的 152.0.7977.83 版中完成了修补,GrapheneOS 旗下的 Vanadium 在 9 月 5 日的 152.0.7977.84 版本里同步更新,Brave 在 Beta/
2026 年 9 月 3 日,NVD(美国国家漏洞数据库)收录了一条编号为 CVE-2026-85046 的 Chromium 高危漏洞,CVSS 评分 8.8。Google Chrome 在 9 月 4 日发布的 152.0.7977.83 版中完成了修补,GrapheneOS 旗下的 Vanadium 在 9 月 5 日的 152.0.7977.84 版本里同步更新,Brave 在 Beta/Nightly 渠道随后跟进到 153.0.8010.37。漏洞的本质是 V8 引擎中的一个 Type Confusion(类型混淆)缺陷——攻击者只需要让受害者访问一个精心构造的 HTML 页面,就能在 Chrome 沙箱内执行任意代码。这条 0day 一旦与另一个沙箱逃逸漏洞组合使用,就可以让攻击者在用户机器上完全控制浏览器进程,进而访问用户的 cookie、扩展权限、企业内网 VPN 隧道。在浏览器自动化、Computer Use、Agent 浏览器访问等场景已经成为企业 AI 化标配的 2026 年下半年,这条 0day 揭示的不只是 Chromium 引擎本身的问题,而是当浏览器从"人类浏览工具"变成"AI Agent 运行时"之后,浏览器沙箱的真实暴露面。
一、CVE-2026-85046 的技术画像:V8 Type Confusion + 沙箱内 RCE
根据 NVD 收录的官方描述,CVE-2026-85046 是 Google Chrome 152.0.7977.82 之前所有版本 V8 引擎中的一个 Type Confusion 缺陷。攻击向量描述相当简洁:"a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page"。也就是说,只要受害者在受影响版本的 Chrome 中打开一个恶意构造的网页(无论通过邮件链接、广告位、被劫持的合法站点还是任何形式的链接投递),攻击者的 JavaScript 载荷就会在 V8 引擎中触发类型混淆,获得在沙箱进程内执行任意原生代码的能力。Google 把这个漏洞的严重程度定为 High,CVSS 8.8。
HN 讨论里(@teravor)给出了一个工程上非常重要的补充:"RCE inside sandbox, so requires chaining with another 0day"。V8 内部的任意代码执行是发生在 Chromium 多进程架构里的 renderer 进程——也就是那个被 sandbox 限制的、不能直接访问操作系统的进程。要让攻击真正造成用户级影响,需要再串上一个 sandbox escape 漏洞,把 renderer 进程的能力扩展到浏览器主进程甚至用户桌面。这条 0day 单独使用只能做到"在 sandbox 内执行代码",但这是后续所有攻击链的前置条件——过去几年几乎每一次浏览器相关的 APT 攻击都是从"沙箱内 RCE + 沙箱逃逸"这条两步链路开始的。
第二个值得关注的细节是,这条漏洞在 NVD 上线时间是 9 月 3 日,Chrome 修复版本发布是 9 月 4 日,1 天内从漏洞披露到补丁上线,这个响应速度说明 Google 安全团队早在 9 月 3 日之前就已经知道这个漏洞并在准备补丁。考虑到 V8 Type Confusion 是一类需要非常专业的攻击能力才能利用的漏洞(写一个稳定利用通常需要几周到几个月的 fuzzing + 漏洞利用研究),这次"先知后修"的节奏暗示该漏洞很可能在野已经被高水平攻击者使用了一段时间。这正是 HN 讨论标题直接使用"Actively exploited"的原因——在 NVD 上线时,这个漏洞已经被认定为在野利用。
第三个细节是不同 Chromium 衍生版本的响应速度差异。GrapheneOS Vanadium 在 9 月 5 日更新到 152.0.7977.84(晚 Google 1 天),Brave 在 Beta/Nightly 渠道也跟进到 153.0.8010.37。这意味着使用 Chrome 原版的用户在 9 月 4 日之后只要重启浏览器就基本安全,但使用某些非主流 Chromium 衍生版本的内嵌浏览器(尤其是企业内部老旧 ERP 系统里那些几年不升级的内嵌 Chromium)可能在补丁到位后仍然长期暴露。这一现实对后面讨论 Computer Use 风险非常重要——很多 AI Agent 内部使用的"无头浏览器"恰恰就是这种长期不升级的内嵌 Chromium。
二、Chromium 沙箱的边界:为什么 sandbox 本身没"破"
理解 CVE-2026-85046 这类漏洞的工程含义,必须先理解 Chromium 的沙箱设计。Chromium 把浏览器拆分成多个进程——浏览器进程(Browser)、渲染进程(Renderer)、GPU 进程、网络进程、扩展进程等——其中 Renderer 进程负责执行网页 JavaScript 并显示网页内容。这个 Renderer 进程在主流操作系统上跑在一个受限的沙箱里:它能访问用户的渲染目标(浏览器标签页),但不能直接访问文件系统、网络 socket、操作系统 API、用户级敏感资源。这条边界正是 Chromium 安全模型的根基。
CVE-2026-85046 这类 V8 Type Confusion 漏洞"执行任意代码"是发生在沙箱内部的——攻击者可以控制 Renderer 进程的 JS 引擎做几乎任何事情,但它仍然在沙箱里,不能直接读用户的文件。要把这个能力"带到沙箱外面",需要一个额外的漏洞——通常是 Mojo IPC 接口的逻辑漏洞、GPU 进程的权限问题、或者文件系统 API 的越界访问。过去十年里,公开的浏览器攻击链几乎都是这种"两步走":第一步 V8/Renderer 漏洞拿到沙箱内 RCE,第二步用 IPC/GPU/扩展 API 的漏洞逃出沙箱。Pwn2Own 比赛每年都展示这种两步组合的真实样本。
这条边界在人类浏览场景下是相对安全的——用户不会主动访问恶意网站,而且有安全浏览服务(Safe Browsing)、URL 过滤、企业代理等多层防护。但在 AI Agent 场景下,这条边界出现了三个新的暴露面。
暴露面一:Agent 会主动访问陌生链接。当用户让一个 Computer Use Agent 完成"帮我查一下 XXX 公司的最新公告"、"浏览这个网页找出价格信息"这类任务时,Agent 会主动打开链接,这些链接可能指向被攻陷的合法站点(watering hole 攻击)、搜索结果里的恶意 SEO 页面、或者 Agent 自己通过 web search 找到的低质量站点。在人类浏览场景下,人会先看一眼域名、URL、可疑标识再点;在 Agent 场景下,Agent 看到 URL + 文字摘要"匹配"就直接点击。这意味着 Agent 在浏览器里点开的链接,平均风险要显著高于人类主动点开的链接。
暴露面二:Agent 的浏览历史会被持久化、暴露给后续任务。Computer Use Agent 为了"记住"任务进度,通常会把浏览历史、点击过的链接、访问过的页面摘要保存到 trace 文件、记忆存储、甚至外部向量数据库里。如果其中某个被访问的页面是恶意页面(已经被 V8 漏洞攻陷 renderer 进程),攻击者的 JS 载荷就可以利用这个 trace 通道把自己持久化到 Agent 的记忆里,在后续任务中"穿越"任务边界继续活动——这是一种新型的"浏览器→Agent 记忆"的攻击路径。
暴露面三:Agent 的浏览器上下文和企业内网耦合。很多企业部署 Computer Use Agent 时,Agent 的浏览器跑在用户的 VDI、企业 SSO 单点、内网 VPN 隧道里。这意味着 Agent 浏览器一旦被沙箱逃逸攻陷,攻击者直接获得的是企业内网的入口点,而不是普通用户的桌面。这种攻击的影响半径远远超过普通浏览器漏洞。
三、Computer Use 智能体的真实暴露面
把上面这三个暴露面合起来看,会发现 CVE-2026-85046 在 2026 年的具体威胁并不是"用户的浏览器被黑了",而是"用户雇的 AI 员工被黑了,然后用 AI 员工的浏览器权限去攻击企业内网"。这个场景在 Computer Use Agent 大规模部署的当下,是完全现实的。
具体来说,一个 Computer Use Agent 在企业内部执行"在 ERP 系统里提交采购单"这类任务时,通常会走这条链路:接任务 → 启动浏览器 → 打开内网 SSO → 登录企业账号 → 进入 ERP → 填表 → 提交。这条链路上每一步都涉及浏览器与内网服务的交互,每一步都依赖浏览器的 JavaScript 执行能力。如果在某个步骤中 Agent 加载了一个被 CVE-2026-85046 攻陷的页面(例如 ERP 嵌入的某个第三方统计脚本被供应链投毒),攻击者就能:
第一,在沙箱内获取 Agent 浏览器上下文的访问能力。攻击者 JS 可以读取 ERP 页面上所有已经渲染的内容,包括采购订单详情、客户联系方式、合同金额、企业内部组织结构等。
第二,利用 Agent 的浏览器扩展和浏览器 API 进一步渗透。Computer Use Agent 通常启用了多个浏览器扩展(用于截图、DOM 提取、表单自动填充),这些扩展可能有更高的权限。攻击者 JS 可以通过 prompt injection 或者扩展 API 漏洞间接调用扩展能力。
第三,如果串上沙箱逃逸漏洞,就能访问 Agent 所在的主机进程。而 Agent 通常跑在用户的本地机器或企业 VDI 上,主机的进程级权限让攻击者可以访问 Agent 的本地文件系统、浏览器 cookie 数据库、SSH 密钥、企业 VPN 凭据等。
第四,通过 Agent 的"任务上下文"污染下游 Agent。很多 Computer Use Agent 在企业内部是协同工作的——一个 Agent 的浏览结果会作为下一个 Agent 的输入。如果前一个 Agent 的浏览历史被攻击者污染,后一个 Agent 在不知情的情况下就会执行被污染的指令。这与 OpenAI Agent Message Board 事件里"智能体用 Artifactory 互通消息"的能力是同源的,但这次是被攻击者主动污染的版本。
四、企业 Browser Agent 平台的工程对策
面对 CVE-2026-85046 这类持续出现的浏览器 0day,任何部署 Computer Use Agent 的企业都不能假设"我们用的 Chromium 版本够新"。在浏览器自动化成为 Agent 标配的 2026 年,浏览器沙箱 RCE 不再是"浏览器安全"问题,而是"Agent 运行时安全"问题。具体来说,企业需要从以下几个维度做系统性加固。
第一,Agent 浏览器必须与企业内网物理隔离。Computer Use Agent 跑浏览器的进程不能同时持有企业内网的 SSO session。最安全的做法是把 Agent 浏览器放在一个独立的 VM/容器里,该 VM 没有企业内网访问权限;Agent 在执行内网任务时,通过显式的、安全审计的代理通道访问内网服务,而不是直接在浏览器里登录企业账号。这一条相当于把"Agent 浏览内网"和"Agent 浏览公网"完全切开,公网侧的浏览器 0day 攻击不会扩散到内网侧。
第二,Agent 使用的浏览器必须保持强制自动更新。企业内部不能使用那些长期不升级的内嵌 Chromium,尤其是某些"打包进 ERP/CRM 客户端的浏览器控件"。Agent Harness 在启动浏览器时应当主动校验 Chromium 版本号是否在 N 天之内发布,如果版本过老直接拒绝启动。Chrome 的更新机制在企业环境里经常被 IT 禁用,这就给 Agent 留下了一个长期暴露面。
第三,Agent 浏览过程必须做"页面级风险评估"。在打开任何外部 URL 之前,Agent Harness 应当先调用 URL 信誉服务(类似 Google Safe Browsing API + 企业自建威胁情报库)做一次预判;对评分超过阈值的链接直接拒绝访问,而不是让 Agent 自己判断"看起来是不是安全"。这条策略对应到 CVE-2026-85046 这类漏洞的具体场景——攻击者经常把恶意页面挂在被攻陷的合法网站上,域名信誉评分可能还过得去,但 URL 信誉服务能识别出该 URL 实际指向的内容与域名不符。
第四,Agent 浏览历史必须做内容校验和签名。Computer Use Agent 在执行任务过程中保存的浏览历史、页面快照、Cookie 数据,必须经过内容校验(例如对 DOM 摘要做签名)。如果浏览过程中触发了 V8 漏洞,攻击者 JS 对 DOM 的污染可以被签名校验发现。这一条对应当前 Computer Use Agent 普遍存在的"Agent 记忆可以被攻击者污染"风险。
第五,Agent 工具调用要做最小权限授权。Computer Use Agent 的浏览器工具链里,某些工具(例如"点击这个链接"、"在输入框里输入文字"、"提交表单")应当比另一些工具("读取 cookie"、"访问本地文件"、"调用浏览器扩展 API")权限更低。一个最佳实践是:Agent 在执行任务时只能调用"低权限工具",需要"高权限工具"时必须经过人工审批或单独的授权通道。CVE-2026-85046 攻击链里,即使 V8 漏洞被利用,如果 Agent 的工具权限被严格限制,攻击者也只能"在浏览器里看到恶意页面的内容",而无法让 Agent 执行真实的高风险动作。
第六,Agent 浏览器要运行在独立的、有完整 trace 的沙箱环境里。每一次 Agent 浏览器会话都必须有完整的 trace,包括访问过的所有 URL、加载的所有脚本、所有 DOM 修改、所有工具调用。当某次会话中检测到异常行为(例如短时间访问大量不相关域名、加载了未签名 JS 文件),系统应当能秒级冻结该会话并告警。
五、浏览器 0day 与 Agent 时代安全边界的重构
CVE-2026-85046 这条 V8 Type Confusion 0day 揭示的是 2026 年下半年 AI Agent 化背景下浏览器安全的一个根本性变化——浏览器已经不再是单纯的"用户浏览工具",而是"AI Agent 运行时"。这个变化有几个具体的工程后果。
第一,浏览器沙箱边界要重新定义。过去浏览器沙箱的边界是"用户操作系统"——沙箱保护的是用户桌面;现在浏览器沙箱的边界要扩展到"Agent 任务域"——沙箱不仅要保护用户桌面,还要保护 Agent 任务、企业内网、跨 Agent 记忆、长期持久化的执行历史。这个新边界的设计不能依赖 Chromium 现有的多进程沙箱机制(那是为人类浏览设计的),而要在 Agent Harness 层做新的隔离层。
第二,浏览器 0day 的影响半径要从"用户桌面"放大到"Agent 集群 + 企业内网"。CVE-2026-85046 单独影响一个浏览器标签页;通过 Agent 的工具链,可能影响整个 Agent 集群的任务执行、记忆污染、跨任务横向渗透、最终波及企业内网。这种影响半径的放大,意味着浏览器 0day 的 CVSS 评分在 Agent 化场景下应当被重新评估。
第三,浏览器自动化的安全审计要做工具链级。传统浏览器安全的审计对象是浏览器本身;Agent 化后,审计对象是"浏览器 + 浏览器扩展 + Computer Use Agent + Agent 记忆 + Agent 任务链路 + 工具调用通道"。这是一条远比传统浏览器复杂得多的攻击面,需要专门的 Agent 安全审计方法学。
CVE-2026-85046 修复版本(152.0.7977.83)在 2026 年 9 月 4 日已经推送,Brave、Edge、Opera、Vanadium 等所有 Chromium 衍生版本在随后的几天内陆续跟进。但这只是众多浏览器 0day 中的一条——V8 Type Confusion 类的漏洞在 2025-2026 年呈现持续高发态势,几乎每隔几周就有一条新的 0day 出现在野利用。对企业 AI 化战略来说,关键不是"我们打不打这个补丁",而是"我们有没有一套能在浏览器 0day 出现时立即隔离 Agent 浏览器访问的系统"。这一条做不到,即使打完所有补丁,下一个 0day 出现时仍然会把 Agent 集群暴露在不可控的风险中。
