同样的 macOS，不同的固件：苹果悄悄修改了 Sequoia 和 Sonoma 更新

Q: 为什么固件自称 mBoot，而苹果的文档却写的是 iBoot？

苹果在 macOS 26.4 中重命名了版本字符串，但尚未同步更新其安全文档。在我们的 Mac 上，固件报告的是 mBoot-18000.121.3，而存储该信息的设备树键名仍然是 iboot-stage-one-tag 和 iboot-stage-two-tag。从功能上讲，这仍是同一个组件。

两台运行 Sequoia 15.7.9 的 Mac，如今可能因更新时间不同而拥有不同的 mBoot 固件版本。苹果在没有改变构建号的情况下修改了更新内容。本文教你如何检查自己 Mac 的固件版本。

假设有两台 Mac，都运行 macOS Sequoia 15.7.9，在「关于本机」中显示的构建号也完全相同。其中一台在 2026 年 8 月 7 日更新，另一台在 8 月 28 日更新。分别打开「系统信息」查看「System Firmware Version」：前者显示 18000.161.9，后者显示 18000.161.10。

苹果的发行说明对此只字未提。15.7.9 更新并未获得新的构建号，其安全说明也没有被修改。苹果只是在 8 月 17 日之后的某个时间点，开始在名称不变的更新包中夹带不同的固件——而外界之所以能知道这件事，纯粹是因为 Howard Oakley 一直保留着专门用于此类对比的虚拟机，并注意到版本号发生了变化。

本文将说明你的 Mac 本应拥有的固件版本、如何查看该版本号、这个数字为何不再与 macOS 版本同步，以及——如果需要的话——你应该采取什么行动。

核心要点

运行 Sequoia 15.7.9 或 Sonoma 14.8.9 的 Apple silicon Mac，其 mBoot 固件可能是 18000.161.9，也可能是 18000.161.10，具体取决于是在 2026 年 8 月 17 日之前还是之后安装的更新。无论哪种情况，macOS 构建号都完全相同。
18000.161.10 原本是 8 月 17 日随 Tahoe 26.6.2 单独发布的固件。苹果后来在未做任何说明的情况下，把它悄悄塞进了名称未变的 Sequoia 和 Sonoma 更新中。
**自 macOS 26.4 起，Apple silicon 固件开始自称「mBoot」**而非 iBoot，版本号也从 13822.x 系列跳到了 18000.x。我们在自己的 Mac 上核实了这一命名：启动固件确实会将自身报告为 mBoot-18000.121.3。
macOS 版本与固件版本之间已不再存在可靠的对应关系。 这种对应关系维持了六年之久，如今这一假设已不成立，建立在其上的工具和合规检查都会因此产生误报。
这并非设备遭到入侵的证据。 但由于苹果没有公布任何关于此次变更的信息，一台固件版本无法解释的 Mac，即便不是安全问题，也会成为审计上的麻烦。

变化一览表

整个事件的关键都在固件那一列。下表所有版本号均针对 Apple silicon Mac；搭载 T2 芯片的 Intel Mac 使用不同的编号体系，将在后文单独说明。

日期	Tahoe	Sequoia	Sonoma	Apple silicon 固件
12 Dec 2025	26.2	15.7.3	14.8.3	iBoot `13822.61.10` —— 三者保持同步
24 Mar 2026	26.4 (25E246)	15.7.5	14.8.5	mBoot `18000.101.7` —— 新名称、新编号；同步仍然保持
11 May 2026	26.5 (25F71)	15.7.7	14.8.7	mBoot `18000.120.36` —— 保持同步
29 Jun 2026	26.5.2 (25F84)	—	—	mBoot `18000.121.3` —— Sequoia 和 Sonoma 被落下
27 Jul 2026	26.6 (25G72)	15.7.8	14.8.8	mBoot `18000.161.9` —— 重新同步
6 Aug 2026	26.6.1 (25G76)	15.7.9	14.8.9	mBoot `18000.161.9` —— 未变化
17 Aug 2026	26.6.2 (25G83)	—	—	mBoot `18000.161.10` —— 仅限 Tahoe
8 月 17 日之后	—	15.7.9（构建号相同）	14.8.9（构建号相同）	mBoot `18000.161.10` —— 悄然改变

Oakley 指出，三个系统直到初夏都保持同步，这也是为什么 3 月那一行显示为「一致」。这些数据均来自他为每次更新撰写的发布当日文章（26.4、26.5、26.6、26.6.1、26.6.2），此外还有一行是我们可以直接确认的：撰写本文所用的 Mac 运行的是 26.5.2，报告的固件版本正是 18000.121.3。

真正关键的是最后一行：版本相同、构建号相同，固件却不同，而且没有任何公告。

如何查看你自己 Mac 的固件版本

共有三种查看方式，其中第三种能告诉你前两种无法揭示的信息。

系统信息

依次点击「苹果菜单」>「关于本机」>「更多信息」>「系统报告」，再点击侧边栏顶部的「硬件」。需要关注两行信息：

System Firmware Version: 18000.121.3
OS Loader Version: 18000.121.3

在正常的 Mac 上，这两行应当一致。它们分别对应启动固件的两个阶段，苹果会同步更新两者。

终端，快速做法

system_profiler SPHardwareDataType | grep -E "Firmware|Loader"

结果是同样的两行信息，且可以写入脚本。大多数资产管理工具采集的正是这两行。

终端，能看到标签名的做法

macOS 显示的版本字符串，是固件自我报告内容的精简版。要查看未经精简的完整内容，需要读取设备树：

ioreg -p IODeviceTree -n chosen -r | grep -E "firmware-version|iboot-stage"

在我们运行 26.5.2 的 Mac 上，返回结果如下：

"iboot-stage-two-tag" = <"mBoot-18000.121.3">
"iboot-stage-one-tag" = <"mBoot-18000.121.3">
"system-firmware-version" = <"mBoot-18000.121.3">

这里有两点值得注意：固件把自己称为 mBoot，但属性名称仍然是 iboot。这一行就是整个更名事件的缩影——苹果只改了固件报告的字符串，却没有动读取它的底层机制。

从 macOS 设备树中读取 mBoot 固件版本

「mBoot」究竟是什么

苹果自己的平台安全指南把 Apple silicon 的启动链描述为四个步骤：芯片中的 Boot ROM 启动信任链；低级引导加载程序（LLB）验证签名并从安全隔区（Secure Enclave）获取 LocalPolicy；iBoot 加载剩余固件，验证内核集合和已签名系统卷的根哈希；随后内核接管系统。这份文档中完全没有出现「mBoot」这个词。就苹果已发布的文档而言，该组件仍然叫 iBoot。

macOS 26.4 中真正发生的变化，是版本字符串本身改了。Oakley 在三月的 SilentKnight 发行说明中记录，这一转变最早出现在 26.4 beta 2，从 iBoot 13822.101.6 变为 mBoot 18000.101.6，并一直延续到最终的 18000.101.7。他的解读是，苹果想要「把 Mac 固件和设备固件纳入同一套编号体系」。这只是一种推测，苹果本身未做任何说明。我们能确认的是可观察到的那一半事实：在任何运行 26.4 或更高版本的 Mac 上，两个启动阶段都会将自己标识为 mBoot-<version>，且编号从 18000 开始。

从实际角度看：mBoot 就是换了个名字标签的 iBoot。它承担相同的职责，处在启动链中相同的位置，也通过相同的机制更新——也就是恰好包含更新版本的 macOS 更新或安装过程。

固件为何曾经与 macOS 严格同步

要理解 8 月的这次变化为何是一次「断裂」，得先了解此前的情况有多么井然有序。

在没有 T2 芯片的 Intel Mac 上，固件是按机型划分的。每个 macOS 安装程序都携带一整套 EFI 更新库，覆盖它所能安装的每一款机型，因此某台 Mac「正确」的固件版本，同时取决于 macOS 版本和具体机型。Oakley 多年来一直手工整理这些对照表。

T2 Mac 简化了这一切：每个 macOS 版本对应一个统一的 EFI 和一个统一的 iBridge 版本，与具体机型无关。

Apple silicon 则进一步简化了这套体系。从 2020 年到今年年中，运行同一 macOS 版本的每一台 Apple silicon Mac 都拥有相同的固件，而且——这一点对安全性至关重要——同时受支持的三个 macOS 版本，其固件会以完全同步的节奏更新。 2025 年 12 月，当 Tahoe 26.2 把固件升级到 13822.61.10 时，同一天发布的 Sequoia 15.7.3 和 Sonoma 14.8.3 安全更新也做了同样的升级。无论一台 Mac 运行三个系统中的哪一个，其固件版本都能准确告诉你它拥有哪个安全版本。

Oakley 表示，这种对应关系曾经十分可靠，可靠到他一度考虑干脆从 SilentKnight 中移除固件检查功能。

同步是如何在 2026 年夏天被打破的

这次断裂分两步发生。

第一步是更新节奏上出现了空档。5 月 11 日到 7 月 27 日之间，Sequoia 和 Sonoma 都没有收到安全更新，而 Tahoe 收到了两次：26.5.1 修复了 M5 Mac 在特定内容过滤网络扩展下会关机的企业级问题，26.5.2 则是一次安全更新，其中包含固件更新，升级到了 18000.121.3。在大约六周的时间里，一台打齐补丁的 Tahoe Mac 和一台打齐补丁的 Sequoia Mac 运行着不同的固件。Oakley 在六月底就此发出提示，称这是「过去六年中第一次有大量 Mac 的固件出现不同步」。

7 月 27 日的 26.6 更新浪潮修复了这个问题：Tahoe 26.6、Sequoia 15.7.8 和 Sonoma 14.8.8 全部升级到 18000.161.9，而 8 月 6 日的更新（26.6.1、15.7.9、14.8.9）则没有触碰固件。一切再次恢复一致。

接着在 8 月 17 日，苹果发布了 Tahoe 26.6.2——这是一次带外发布，从 macOS 27 测试版回植了若干修复——所带的固件是 18000.161.10。这次没有对应的 Sequoia 或 Sonoma 更新，两个系统都停留在 .9。同步再次被打破，而这一次，中间还夹着一次安全更新。

沉默的那部分

到目前为止的一切虽然混乱，但都有据可查——每个固件版本都在当天被记录了下来。没有记录的，是接下来发生的事。

Oakley 在 8 月 7 日把自己的 Sequoia 和 Sonoma 虚拟机更新到了 15.7.9 和 14.8.9，此后由于没有再收到新的更新推送，这两台虚拟机一直停留在 18000.161.9。但当他在 8 月 28 日新建了一批 Sequoia 和 Sonoma 虚拟机，并同样更新到 15.7.9 和 14.8.9 时，得到的却是 18000.161.10——那个原本只随 Tahoe 26.6.2 发布过的固件版本。

It appears that those Macs that were updated to 15.7.9 or 14.8.9 prior to the release of 26.6.2 on 17 August had their firmware updated to 18000.161.9, while those updated since 17 August have been provided with 18000.161.10 instead, without any change in macOS version or build number. There has been no mention of any such change in Apple's security release notes.

我们核实了这句话的另一半。苹果针对 26.6.2 的安全内容页面完全没有提到固件、mBoot 或 iBoot；15.7.9 和 14.8.9 的页面同样只字未提。就苹果的公开记录而言，什么都没有改变。

关于证据的一点说明：Oakley 的对比使用的是虚拟机而非物理 Mac。就这个具体问题而言，这其实是优势而非弱点——在 Apple silicon 上，macOS 虚拟机的启动固件由客户机自身的安装程序和更新程序提供，因此一台全新虚拟机在安装「15.7.9」后报告 .10，就意味着 15.7.9 更新包本身现在携带的就是 .10。但这并不能告诉我们，一台已经处于 .9 的物理 Mac 会被如何处理，我们自己也尚未能对此进行测试。

你应该拥有哪个版本号

根据上表，你可以据此判断自己应有的版本号。

你正在运行	8 月 17 日前更新	8 月 17 日后更新
Tahoe 26.6.2	（不可能）	`18000.161.10`
Tahoe 26.6.1	`18000.161.9`	—— 请更新到 26.6.2
Tahoe 26.5.2	`18000.121.3`	—— 请更新到 26.6.2
Sequoia 15.7.9	`18000.161.9`	`18000.161.10`
Sonoma 14.8.9	`18000.161.9`	`18000.161.10`
Sequoia 15.7.8 / Sonoma 14.8.8	`18000.161.9`	`18000.161.9`

如果你的 Sequoia 或 Sonoma Mac 显示 18000.161.10，说明你用的是较新的固件，无需做任何事。如果显示的是 18000.161.9，说明你用的是你更新那天正确的固件，目前也没有任何更新能让你转到新版本——苹果并未向已经拥有 15.7.9 或 14.8.9 的 Mac 重新推送这两个更新。

除此之外的任何情况——比如一台声称运行 26.4 或更高版本的 Mac 却显示 13822.x 编号，或者显示了一个不在此表中的 18000.x 编号——都值得先搞清楚原因，而不是直接忽略。最常见的无害解释是，这台 Mac 安装了不止一个 macOS，你读取到的是另一个系统卷对应的加载器版本；详见下文的「疑难排解」。

这真的重要吗

老实说：对大多数人而言，目前这件事的影响可能不大。但它之所以值得关注，原因需要说清楚，因为这些原因和人们通常以为的并不一样。

这不是「你的 Mac 不安全」

除了苹果自己，没有人知道 18000.161.9 和 18000.161.10 之间到底改了什么。它随一次安全更新一同发布，这似乎暗示它与安全相关，但固件的小版本更新同样也会修复硬件兼容性、电源管理和启动阶段的缺陷。苹果 26.6.2 的说明中列出了 28 个 CVE，但没有一个被描述为固件修复。如果你用的是 .9，那意味着你用的固件在三周前还被苹果视为最新版本。

这是「你的资产清单出错了」

六年以来，「固件版本」一直是一个可以推导出来的属性：只要知道 macOS 版本，就能知道固件版本。任何建立在这个假设之上的东西——合规规则、MDM 智能分组、Excel 表格、用来标记异常值的脚本——现在都会看到两群本应完全相同的 Mac，却无法判断哪一群才是「正确」的。SilentKnight 作为这方面最广泛使用的消费级工具，在版本 3.01 中改变了行为，只把固件版本报告为「已发现」，而不再判断它是最新还是过时——原因正是这种判断已经无法做出。

这是「苹果在没有留下任何记录的情况下修改了已发布的更新」

这一点比版本号本身更应该引起你的关注。Apple silicon 的更新是通过 Oakley 所称的 Update Brain 来执行的，这是一个针对具体更新单独下载的组件，负责运行那一次特定的更新。苹果显然改变了其中某次更新所安装的内容，同时保持版本号和构建号不变，也没有发布任何相关说明。他的结论直截了当：

In the absence of any information from Apple, some could reasonably suspect this was the result of a sophisticated attack.

他并不认为这真的是一次攻击，我们也不这么认为。但「仅凭苹果公开的信息，我们无法将其与一次攻击区分开来」——这本不应该是一个安全更新流程该有的状态。

macOS Tahoe、Sequoia 与 Sonoma 之间的固件版本谱系

如果你在使用 Sequoia 或 Sonoma，并且想要更新的固件

你有三种选择，但只有第一种是我们推荐的。

等待

Oakley 预计 Sequoia 15.8 会在 9 月下半月与 macOS 27 一同发布。那次更新几乎肯定会带上当时最新的固件，届时的版本很可能已经比 .10 更新——他预计 Golden Gate 固件会跳到大约 20457.1.29。Sonoma 的情况则不同：它的最终版本很可能就是 14.8.9，这意味着在 8 月 17 日之前更新过的 Sonoma Mac 会永久停留在 .9。不过这没什么问题，因为所有按时更新的 Sonoma Mac 情况都是如此。

从恢复模式重新安装 macOS

在 recoveryOS 中执行「重新安装 macOS」，会下载一份当前已安装版本的全新副本，如果安装程序内含更新的固件，就会一并更新固件。既然全新安装的 15.7.9 现在带的是 .10，这个方法理论上可行。我们尚未实测过，而且这个过程要花上一个小时，对于一个版本字符串的差异来说，这样做未免小题大做。不要为了追一个数字而这么做。

DFU 恢复模式（revive）

苹果针对 Apple silicon Mac 的恢复（revive）与还原（restore）流程，会通过 USB-C 数据线从第二台 Mac 重新加载固件。苹果表示 revive「不会清除你 Mac 上的数据」，并建议在使用会清除数据的 restore 之前先尝试 revive。这个操作需要一台运行 macOS 14 或更高版本的宿主 Mac，以及一条支持数据传输和充电的 USB-C 数据线——苹果特别说明不要使用雷雳 3 数据线。这个工具适合无法开机的 Mac，而不适合一台能正常开机、只是固件版本号让你不满意的 Mac。这里提到它，只是为了让你知道它的存在。

如果你在使用 Tahoe

如果你已经在用 26.6.2，那么你已经拥有 .10，本节内容与你无关。如果你还停留在 26.6.1 或更早版本，解决办法就是你本来就该安装的那次更新。

你接下来会看到的固件变化将是一次大的跃升。根据 Oakley 对测试版的解读，Golden Gate 的固件会转移到 20457.x 系列。新款 Mac mini 和 Mac Studio 将在 9 月 22 日预装 macOS 27 的预发布版本上市，届时需要立即更新到 27.0.1——预计它们的固件也会随之变化。

面向设备管理员

以下是三项具体的调整建议。

不要再把固件版本当作可以从 macOS 版本推导出来的属性。 任何形如「15.7.9 意味着 18000.161.9」的规则，现在对你设备群体中的一部分都是错误的，而这部分设备恰恰是由你很可能没有记录下来的更新时间点所决定的。

不要仅凭 .9 和 .10 的差异就触发警报。 两者都是同一个苹果更新的合法结果。如果你希望针对每个 macOS 版本设定一个统一的比对基准，可以把较新的版本设为目标值，并把 .9 视为「在安装当天是正确的，下次更新时会趋于一致」。

在设备注册时以及每次更新时都记录固件版本，这样才能区分「这台 Mac 更新得比较早」和「这台 Mac 的固件在没有 macOS 更新的情况下发生了变化」——后者才是真正值得留意的情况。在 Apple silicon 上，固件只会在 macOS 安装或更新过程中发生变化，因此没有对应 macOS 变化的固件变动才是需要警惕的异常，而不是两台 Mac 之间的版本不一致。

苹果应该做什么

这其实是个很小的请求。苹果的安全内容页面本就会列出每次更新涉及的所有组件和 CVE。只需加上一行——「本次更新包含 mBoot 18000.161.10」——不会有任何成本，却能让 8 月的这次变化在发生当天就清晰可见。如果这次改动是有意为之且无害的（这也是最有可能的情况），那就没有理由让人们只能靠对比虚拟机才能发现它。

Intel Mac

搭载 T2 芯片的 Intel Mac 会报告两个固件组件：EFI 风格的系统固件，以及 T2 的 iBridge（bridgeOS）。Oakley 在 26.6.2 相关文章中给出的数值分别是 2103.160.2.0.0 和 iBridge 23.16.16068.0.0,0，与 26.6.1 相比没有变化。mBoot 的故事完全不适用于 Intel 硬件——它的编号体系从未改变，三个版本之间的同步也从未被打破过。运行 Tahoe 的 Intel Mac 无论如何都已经在其最后一个 macOS 版本上，因此这也将是它们所能看到的最终固件谱系。

常见问题排解

系统信息显示两个不同的数字

「System Firmware Version」和「OS Loader Version」通常应当一致。两者不同最常见的原因是，这台 Mac 安装了不止一个 macOS 系统卷——比如在另一个卷上装了 Golden Gate 测试版——所报告的加载器版本对应的是另一个系统。可以启动到另一个系统卷再做比较。如果只安装了一个 macOS 却出现不一致，那就属于异常情况，值得向苹果反馈。

SilentKnight 显示「found」而不是「current」

这是该工具自 3.01 版本起的既定设计行为。它已经无法告诉你你的固件是否为最新版本，因为苹果不再保证每个 macOS 版本只对应唯一一个固件答案。请改用上文的表格自行比对。

虚拟机显示的固件版本与宿主机不一致

这是正常现象。在 Apple silicon 上，macOS 虚拟机的固件来自客户机自身的安装程序，而非宿主 Mac。这也正是 Oakley 的虚拟机能够揭示这次变化的原因。

`ioreg` 对 `chosen` 节点没有返回任何结果

你使用的很可能是 Intel Mac，其设备树结构不同，也没有 iboot-stage-one-tag。请改用 system_profiler SPHardwareDataType，它会报告「Boot ROM Version」，在 T2 Mac 上还会在 Controller 下报告 iBridge 版本。

我的 Sequoia Mac 显示 `18000.161.10`，但我是 8 月 7 日更新的

那说明在那个日期之后，有其他操作更新了固件。可能的原因包括：重新安装过 macOS、执行过 revive 恢复操作，或者有一次你没有注意到的更新。可以在「系统信息」的「软件」>「安装记录」中查看是否有 8 月 17 日之后的记录。如果没有找到任何记录，请留意——没有对应安装记录的固件变化，正是本文中唯一真正值得进一步排查的情况。

常见问题

`18000.161.10` 是安全修复吗？

不确定。它是随一次安全更新一起发布的，但苹果没有说明其具体内容。请把它理解为「更新的版本」，而不是「修补了某个已知漏洞」。

如果我的 Mac 是 `18000.161.9`，我需要做什么吗？

不需要。这是你更新那天正确的固件版本，你下次安装 macOS 更新时就会自动获得当前版本。苹果并未将任何已暴露的漏洞与 .9 关联起来。

为什么固件自称 mBoot，而苹果的文档却写的是 iBoot？

苹果在 macOS 26.4 中重命名了版本字符串，但尚未同步更新其安全文档。在我们的 Mac 上，固件报告的是 mBoot-18000.121.3，而存储该信息的设备树键名仍然是 iboot-stage-one-tag 和 iboot-stage-two-tag。从功能上讲，这仍是同一个组件。

固件能在没有 macOS 更新的情况下发生变化吗？

在 Apple silicon 上不能——固件只会在 macOS 安装、更新、revive 恢复或 restore 还原过程中被写入。这正是为什么没有对应安装记录的固件变化才是真正的异常情况。

macOS 27 会修复这种不同步的问题吗？

它会重置这种状态。Golden Gate、Tahoe 26.7 和 Sequoia 15.8 预计将在 9 月同时发布，理论上从发布首日起就会共享同一固件。至于苹果之后是否会保持它们的同步，还是重演今年夏天的模式，目前仍是一个悬而未决的问题。

结语

六年以来，Apple silicon Mac 的固件版本只取决于一件事：macOS 版本。这让它变得很有用——一个单一的数字，就能告诉你一台 Mac 拥有哪个安全版本，无论它运行的是最新 macOS 还是另外两个较旧版本中的哪一个。今年夏天，这个规律不再成立：起初是因为 Tahoe 的周期中期更新携带了旧系统未曾获得的固件，而后来更严重的是，苹果在没有改变任何可见内容的情况下，改变了 Sequoia 和 Sonoma 更新所安装的实际内容。

这一切都不会让你的 Mac 变得更不安全。但它确实让固件版本号更难解读，让依赖它的工具变得不那么好用，也证明了苹果会在不声张的情况下修改已发布的更新。如果你负责管理一批 Mac，现在就该调整自己的预期，趁着 9 月的发布浪潮还没有把第四个 macOS 版本纳入这幅图景之前。如果你不负责管理设备，那么实际的结论会更简单：.9 和 .10 都没问题，真正值得担心的，是那种在其他一切都没变的情况下却发生了变化的数字。

延伸阅读：macOS Tahoe 26.6.2 及其 28 个 CVE 的发现者、26.6.1 的屏幕共享修复、Tahoe 上后台安全更新的工作原理，以及macOS 更新导致 Mac 无法启动时该怎么办。