一条补丁说明并不等于一份威胁模型。"处理恶意构造的网页内容可能导致 Safari 意外崩溃"是厂商客气的说法，意思是对某些用户而言，这个漏洞就是浏览器在「另一段东西开始运行之前」做的最后一件事。真正有用的问题是，那「另一段东西」到底能碰到什么。

2026 年 5 月 11 日，Apple 发布了 About the security content of macOS Tahoe 26.5。这次更新在整个操作系统范围内修复了约七十个 CVE，其中有十个落在 WebKit 里——Safari 的渲染引擎，也是 macOS 上所有"网页视图"背后的引擎，从 Mail 的 HTML 渲染器，到 App Store 内嵌的浏览器。这十个里没有任何一个被 Apple 标注为正在野外被利用。这并不等于说它们没有被利用，只是说 Apple 今天还没有指向那个方向的证据。本文的其余部分会先把这份公告按字面照单全收，然后追问一个更窄、也更有用的问题：对每一个这样的漏洞，如果它落在一个 Bromure 用户身上，本来会发生什么？

简短的答案，已经写在标题里了。完整一点的答案，正是这套架构值得专门写一篇文章的原因。

这份公告，用大白话说

读一份 Apple 安全说明，有一半是在做词汇练习。那句标准措辞——"处理恶意构造的网页内容可能导致"——所覆盖的范围，从"一个标签页会关掉"一路延伸到"整台机器没了"。把它们区分开的，是漏洞类别，而公告其实也把这部分交代了，只是说得很轻。

macOS Tahoe 26.5 中的十个 WebKit CVE，按漏洞类别分组。每一类利用链所能达到的天花板都不一样。最底下的两类——具有任意代码执行潜能的内存破坏，以及释放后重用——是历史记录中最常被串成渲染器沦陷、并进一步打到主机的那两类。

Apple 在政策上从不公开发布可利用性分析。措辞是有意为之的："进程崩溃"既可能意味着渲染器命中了一个断言，然后无害地死掉，也可能意味着渲染器进入了某种状态——再花几周时间做堆排布，攻击者就能把崩溃变成一个写原语，再变成代码执行。这个领域的研究人员一再表明，对于以这种完全相同的措辞披露的 WebKit 释放后重用漏洞中，相当大一部分都是可以做到后一种结果的—— CVE-2025-43529，去年 12 月在 macOS 26.2 中修复，措辞与此处一模一样，而在披露当时正被用于定向攻击。所以，读这份公告最正确的姿势，是把它当成下一轮野外被利用的候选名单，而不是一份"我们已经知道无害"的漏洞清单。

第一类——五个释放后重用

一句话来说，所谓释放后重用，就是浏览器把某块持有对象的内存（一个 DOM 节点、一个事件监听器、一个 JavaScript 包装器）释放掉，却仍然像对象还活着一样继续用着旧的引用。等到这个旧引用被解引用时，那个槽位已经被别的东西填进来了：可能是页面刚创建的另一个对象，也可能是页面刚刚塞满字节、看上去像一个函数指针的缓冲区。于是，浏览器当作"可信"在用的那个指针，现在归页面说了算。

CVE-2026-28883、CVE-2026-28942、CVE-2026-28946、CVE-2026-28947，以及 CVE-2026-28901 — CVE-2026-28913 簇里属于 UAF 的那部分，构成了这次发布中的五个 WebKit 释放后重用漏洞。Apple 把它们的功劳分别归给了多位独立研究人员，其中有一例（CVE-2026-28942）归给了 Milad Nasr 与 Nicholas Carlini 借助 Claude 完成的工作——这与 Mozilla 在 4 月披露的那一更大类别的 AI 辅助漏洞研究属同一脉络，Mozilla 当时把单次 Firefox 发布中 271 项修复的功劳归给了 Mythos 的一次早期运行。

在一台没打这次更新的、原版 macOS 26.5 的 Mac 上，这些漏洞中任意一个最糟糕情况下的展开是这样的：

你访问了一个页面。页面运行一段 JavaScript，以某种方式触发了某个 DOM 操作中的释放后重用。
渲染器的内存被刻意排布，使得被释放的槽位被攻击者控制的内容重新填上。
代码执行落进 Safari 的内容进程中——和你的浏览会话、你的 cookie、你已登录的标签页处于同一地址空间。
一个串接在第一阶段之上的第二阶段利用，从内容沙箱里逃出来，进入更广的 Safari 进程。WebKit 的沙箱很扎实，但并非不可破；最近几年里有数起有据可查的逃逸记录。
跑出沙箱之后，攻击者就是以你的用户身份在你的机器上运行。他们可以读取 ~/Documents、~/Library/Keychains、~/.ssh，可以读 Safari 配置文件中存的 cookie，可以读 iCloud Drive 已经下下来供离线使用的内容，以及凡是你家目录底下的任何东西。

这是一条传统浏览器完整的攻击链。每一步都不是假设；过去三年里，每一步都在真实野外的 WebKit 链子里被观察到过。

同一个 WebKit 释放后重用漏洞，在原版 Safari 中，对比它在 Bromure 标签页里引爆时的样子。漏洞本身两种情况下都会触发。差别在于：当它触发时，渲染器的另一边是什么。

右侧的示意图里有一个细节，值得开门见山地讲清楚：Bromure 并不使用 WebKit。每一个标签页跑的都是 Chromium，运行在它自己那台一次性的 Linux 客户机虚拟机里。所以这些 CVE 的字面文本——五个 WebKit 释放后重用——并不适用于 Bromure 所发行的渲染引擎。一位完全没装 macOS 26.5 更新的 Bromure 用户，并不会通过他在 Bromure 里打开的标签页，暴露在这些具体的 WebKit 漏洞之下。

这件事本身并不是一个有趣的论断。Chrome 有自己的内存漏洞清单。Firefox 也有自己的。真正的重点是二阶的那一层：哪怕你在脑子里把这些 CVE 替换成同等类别的 Chromium V8 或 Blink 释放后重用漏洞—— CVE-2024-7971，那个 2024 年被亲朝鲜行为者使用的 V8 类型混淆，就是最直接的对照——右边那张图也不会变。利用在渲染器里触发。渲染器在客户机虚拟机里。代码执行落进一台不包含你的钥匙串、不包含你的 Documents 文件夹、也不包含你的 SSH 密钥的 Linux 盒子里。等到标签关闭，这台虚拟机就被销毁。

第二类——另外三个内存漏洞，加上一个输入校验漏洞

CVE-2026-43658 是本次公告中唯一被 Apple 明确标为"内存处理"而不是释放后重用的 WebKit 漏洞；给出的影响是 Safari 意外崩溃。CVE-2026-28917 被标为输入校验，同样表现为进程崩溃。它们都和那批释放后重用漏洞落在同一个大类里——都是 WebKit 地址空间内、由恶意页面诱发的崩溃——而且它们的现实天花板也是一样的：只要肯下功夫，"崩溃"在某些情形下可以被提升为一个代码执行原语，在另一些情形下，则的的确确只是一个崩溃。Apple 没告诉我们到底是哪种；快速读一遍补丁本身，也没法判断这个问题。

值得强调的一点是，对用户而言，这种区分并不会改变那个架构上的答案。在原版 Safari 上，哪怕是一个看起来挺无害的 WebKit 崩溃漏洞，最坏情况也是一个立足点。在 Bromure 上，哪怕是这类漏洞最糟糕的版本——渲染器内的完整代码执行——也只是一台马上要被丢弃的客户机里的一次代码执行事件。

第三类——五个逻辑与策略漏洞

这次公告里的十个 WebKit 漏洞中，有五个完全不是内存漏洞。它们是逻辑漏洞——Safari 安全策略所声明的"允许范围"，与它的代码实际所强制执行的内容之间的那些小不一致。

CVE-2026-43660 与 CVE-2026-28907 — CSP 绕过

内容安全策略（Content Security Policy）是网站告诉浏览器"只能从这些来源运行 JavaScript，只能从那些来源加载图片"的机制。这两个漏洞都允许一个恶意构造的页面，让 Safari 在解析器的某条路径上跳过对该策略的强制执行。现实后果：原本以为靠 CSP 撑着的网站上的一个存储型 XSS，现在真的会执行了。

CVE-2026-28962 与 CVE-2026-28958 — 信息泄露

这两个都允许恶意页面读到它本不该有访问权的数据。前者在 WebKit 的访问控制逻辑里；后者在它的数据保护路径里。一旦串进链子里，它们就是把"我在你的渲染器里拿到了代码执行"变成"我现在拿到了你登录过的另一个网站的会话 cookie"的那种漏洞。

CVE-2026-28971 — iframe 下载欺骗

一个恶意 iframe 可以使用父页面的下载设置。表面上看这是一个 UI 漏洞；实际上，这正是一次顺手过路下载，搭上一个用户明确信任、允许其保存文件的网站的便车的方式。这是恶意软件最经典的初始访问原语之一。

逻辑漏洞是用来干嘛的

单独看，这些都拿不到代码执行。它们的价值是结构性的：每一个都是上面那些内存漏洞向上攀爬的一级台阶。一个赤裸的释放后重用，没有泄露指针的办法、没有绕过 CSP 的办法、没有读取跨源状态的办法，是很难武器化的。同一次发布中的逻辑漏洞，正是每一条公开利用链里那安静的另一半。

同样的论证也适用于 Bromure 这一侧，只是有一点澄清值得讲清楚。下载欺骗漏洞（CVE-2026-28971）之所以有意思，是因为它是本清单里唯一一个，在原版 Safari 上能够在磁盘上落下一个用户事后可能会打开的文件的漏洞。Bromure 里从标签页内进行的下载，默认就落在该标签页的客户机虚拟机内部；把它们提升出客户机，是一个明确的用户操作。一个被页面"下载"下来的过路文件，在 Bromure 里只是一个 Linux 客户机里的文件，而这台客户机马上就要不复存在。那两个跨源信息泄露（CVE-2026-28962、CVE-2026-28958）能读到的，是渲染器自己能看到的数据，在 Bromure 上，那就是那一个标签页虚拟机内部的数据。

房间里还剩下什么：虚拟机能隔离与不能隔离的那些事

太容易因为上面的内容而走向一个错误的结论了。Bromure 的架构擅长收窄渲染器沦陷的爆炸半径。但它不是魔法。还有几样东西仍然留在这个房间里，值得把它们摊开说清楚。

会话本身已被攻陷

其中一个漏洞的可用利用，仍然完全掌控了它所触发的那个标签页。利用窗口内你在那个标签里输入的密码，在范围内。那个标签所使用的配置文件中存的 cookie，在范围内。表单数据，在范围内。Bromure 的按配置文件隔离能保证伤害被限定在那一个配置文件之内，而不是用户的整个数字生活，但绝不是零。

剪贴板就是那座显眼的桥

Bromure 默认让客户机能用剪贴板，因为对大多数用户来说，每天都把复制粘贴打断的代价，要重过那种少见的利用场景。这是一个有意的设计选择，对于你希望严格密闭的会话，我们可以按需把它切断。但值得知道这座桥存在。

虚拟机管理程序逃逸仍在牌桌上

原则上，一条足够老练的利用链可以从 Apple Silicon 的虚拟机管理程序本身逃出去。那里的攻击面比浏览器小好几个数量级，公开记录在案的此类漏洞也很短，但并不是零。我们不会声称免疫；我们声称的是：我们把你安全所依赖的那个漏洞类别给挪了位置。

没有扩展，没有浏览器助手层

Bromure 根本不允许安装 Chrome 扩展。这是一个立场，不是一个设置。它移除了一整个第二攻击面——每一个扩展都是它自己的一段半可信代码路径，权限和渲染器并行——历史上，许多真实世界的浏览器沦陷，最后正是靠这一层拿到持久化的。

为什么 Mac 和浏览器想成为两台不同的机器

上面所有这些，有一个更一般的说法。一台现代的 Mac，并排放着、共享同一个信任域的，是：

操作系统，里头有你的文件和你的钥匙串。
你装的原生应用，连带它们各自申请的权限。
浏览器，它远远是这台系统上最大的那一块"由攻击者控制可解析"的机器。

当一个 WebKit 漏洞在原版 macOS 上触发，系统中刚被攻陷的那一部分，恰好就是对前面两部分有读取权限的那一部分。这不是 Safari 的失误；这只是把浏览器当成一个用户态应用、和用户其他所有活动并排运行所带来的直接后果。

Bromure 的设计把浏览器和 Mac 的其余部分当成两台不同的机器来对待。浏览器实际上跑在另一台机器上——一台 Linux 客户机，一颗虚拟 CPU 之上，磁盘是虚拟的，每次会话之后被重置。宿主 Mac 只能透过一组很窄的虚拟机管理程序调用看到这台客户机：帧缓冲、输入、网络、以及在允许的情况下，剪贴板。一个 WebKit 那一类的漏洞——或者它的 Chromium 等价物——在客户机里触发，从宿主的视角看，就是另一台计算机、另一套操作系统上跑的代码，没有任何通往用户文件的路径。两台"计算机"共享同一个机壳，只是一个实现细节而已。

今天该做什么

如果你正在用你做所有其他事情的那台 Mac 上读这篇文章，最重要的就是那件无聊的事：把 macOS 26.5 更新装上。从 Apple 发布补丁，到有人把这补丁变成可用利用之间的窗口，按行业自己的测量，如今是以小时而不是以周来计的。装了这次更新的原版 Safari 用户，对上面这十个 WebKit 漏洞是受保护的。没装的，不受保护。

如果你是在 Bromure 上读这篇文章，那么对于 WebKit 那类渲染器漏洞，你是靠架构而不是靠补丁覆盖率来获得保护的——因为渲染器并不是 WebKit，并不跑在宿主上，而是身处一台标签关闭后就被销毁的客户机里。但你依然应该装上 macOS 26.5 更新，因为这次发布里另外那大约六十个 CVE，修的是 Bromure 并不隔离的那些 macOS 组件——内核组件、系统服务、原生框架——而那些仍然重要。

我们希望更多人采用的那个框架，是这样的。WebKit 零日不会停。Chromium 零日不会停。对任何一个具体用户而言，能停下来的是"一个页面出问题了"与"你的电脑出问题了"之间的那道连接。Bromure 当初被造出来，就是为了打断那道连接，一份十个 CVE 的公告、一份地打断。

装上 Bromure。继续装好你的 macOS 更新。下次 Apple 再发布一个 Safari 更新，里头写着"处理恶意构造的网页内容可能导致"——而这很快就会发生，因为节奏现在是按月来的——把那句话读一遍，存档，然后留意一下：对于你这一天里花在 Bromure 内部的那一部分时间，这句话并没有写完。