沙箱内UAF会突破浏览器限制吗?

CVE-2026-118330 的描述里有一句容易被读快的话：远程攻击者可通过特制 HTML 页面“在沙箱内执行任意代码”。不少人看到“执行任意代码”就直接等同于浏览器被攻破、终端沦陷。但这句话里真正的限定词是“沙箱内”。释放后使用（UAF）本身是内存安全缺陷，它决定的是攻击者能否在某个进程里取得控制权；沙箱决定的是这个进程本身有多少权限。两者属于不同层面的问题，混在一起谈，风险判断就会失真。

沙箱内代码执行意味着什么

Chromium 把渲染、脚本执行这类高风险工作放在低权限进程中，用沙箱限制其系统调用与资源访问。攻击者借特制页面触发 UAF，通常先拿到的是这个受限进程内的代码执行能力：可以读写该进程内存、可能接触页面数据，但无法直接写文件、加载驱动或访问其他进程的内存。沙箱的设计意图正在于此——把一次内存破坏的后果约束在单个进程边界内。所以“沙箱内执行任意代码”描述的是边界之内被攻陷，而不是边界本身失效。

越界通常需要第二个漏洞

要真正突破浏览器限制，攻击者需要在拿到渲染进程控制权之后，再找到一个沙箱逃逸漏洞，或借助操作系统层面的缺陷与配置弱点完成提权。这类利用往往呈现为“渲染器内存破坏 + 沙箱逃逸”的组合链，两个环节缺一不可，单个 UAF 并不构成逃逸。原文也指出，触发该缺陷所需的具体页面构造、是否依赖特定渲染路径、以及在启用站点隔离等防护配置下的实际可利用性，目前均无公开细节——而这些恰恰是判断能否越界的核心变量。在它们公开之前，既不能断言可逃逸，也不能断言不可逃逸。

这个区分如何影响处置

它不是学术洁癖，而是直接改变优先级。若仅止于沙箱内代码执行，风险主要落在数据暴露与浏览器进程本身；若叠加已知的沙箱逃逸链，才升级为终端沦陷级别。因此内部通报应把“版本边界已确认”和“利用链未公开”分开表述，不要把数据库摘要当成已验证的攻击链结论。

对运维来说，无论逃逸条件是否成立，“是否打补丁”都比“是否访问可疑站点”更具决定性，因为该漏洞的攻击面与普通网页浏览高度重合。Windows 上低于 156.0.8078.73 的安装构成暴露面，应尽快升级，并把浏览器版本作为与操作系统补丁并列的常态检查项，而不是等下一次安全事件再回头清点。