iOS 漏洞为什么总出在这几个组件

4249 个漏洞、79 个在野利用、40+ 个组件————但真正的杀机，集中在不到 5 个名字上。

一、一个反直觉的事实

从 2007 年 iPhone OS 1 到 2026 年 iOS 26，苹果在安全公告中披露了 4249 个安全漏洞，其中 79 个被确认在野利用（in-the-wild exploit）。这组数字本身并不令人意外————一个运行了将近二十年的操作系统，漏洞数量庞大是正常的。

真正令人惊讶的是这 4249 个漏洞的分布。

如果把 iOS 的 40 多个安全组件按漏洞数量排个序，前三大集群————WebKit、内核、媒体处理————合在一起，占据了全部漏洞的 45%，却包揽了在野利用的 94%。

这不是"雨露均沾"的故事，而是"赢家通吃"的战场。

二、漏洞的 80/20 法则

让我们把数据摊开来看：

WebKit 和内核两个集群加起来，占全部漏洞的 33%，但占全部在野利用的 83%。如果再加上媒体处理集群，三个集群就拿下了在野利用的 94%。

这就是 iOS 安全的"80/20 法则"————只不过实际上比 80/20 更极端，更接近 90/10。

打个比方：iOS 的攻击面就像一座城池，有四十多扇门，但攻城者几乎只从三扇门冲锋。不是因为其他门没有锁，而是这三扇门后面就是金库。

三、为什么是这三个集群？

WebKit：浏览器即操作系统

WebKit 是 iOS 上最大的单一攻击面，没有之一。802 个漏洞、45 个在野利用，这两个数字都远超任何其他组件。

原因很本质：WebKit 就是一个操作系统里的操作系统。它要解析 HTML、执行 JavaScript、渲染 CSS、解码图片、处理字体、管理网络请求、维护沙箱————一个现代浏览器引擎的复杂度，已经不亚于一个操作系统内核。而 iOS 上所有 App 的内嵌网页渲染，默认都必须使用 WebKit（这是苹果的 App Store 审核规则）。

这意味着：Safari 用它，邮件 App 用它，消息 App 用它，甚至你刷到的一个广告页也在用它。攻击者不需要你打开某个特定 App————任何能渲染网页的场景，都是 WebKit 的战场。

内核：提权的终南捷径

XNU 内核是 iOS 安全的根基。607 个漏洞、21 个在野利用，数量不如 WebKit，但杀伤力更致命。

内核漏洞的价值在于提权（privilege escalation）。Webkit 漏洞能让你在沙箱里"越狱"，但沙箱里的权限有限。内核漏洞能让你跳出沙箱，获得 root 权限，甚至禁用系统的安全机制。在几乎所有完整的攻击链中，内核漏洞都是不可或缺的一环————它是从"有限控制"到"完全控制"的关键跳板。

内核集群中，除了 XNU 本体（437 个漏洞），还有几个特别"高产"的子组件：IOMobileFrameBuffer 虽然只有 19 个漏洞，却有 4 个在野利用（21% 的利用比率，远超平均水平）；IOSurfaceAccelerator 的利用比率也高得吓人。这些驱动层面的组件，代码量不大，但处于内核态运行，一旦出问题就是致命的。

媒体处理：零点击的最佳入口

媒体处理集群有 518 个漏洞、8 个在野利用。数量上不如前两者，但它有一个独特属性：它是零点击攻击（zero-click attack）的首选入口。

ImageIO、FontParser、CoreGraphics、CoreMedia————这些组件的共同特点是：它们在后台自动处理用户接收到的数据，无需用户任何交互。你收到一条 iMessage，里面有一张图片，ImageIO 就会自动解析它。你收到一个字体文件，FontParser 就会自动处理它。甚至邮件中的一个 PDF 附件，CoreGraphics 也会在后台预览渲染。

这就是 FORCEDENTRY 攻击的原理————一张特制的 PDF 图片，经过 CoreGraphics 解析，就能在用户毫不知情的情况下攻破设备。不需要点击，不需要打开，数据到达即攻击。

四、和 Android 的对比

iOS 的漏洞集中度远高于 Android，这背后有架构差异的原因：

Android 的攻击面更分散。 Android 设备的基带处理器、Wi-Fi 芯片、蓝牙栈都有大量独立漏洞，因为 Android OEM 厂商各自实现这些组件，代码来源五花八门。而苹果自研 A 系列芯片、统一管理驱动，使得 iOS 在这些无线攻击面上的漏洞相对较少。

iOS 的 WebKit 是强制垄断。 所有 iOS App 必须使用 WebKit 渲染网页（不像 Android 允许 Chrome/Chromium），这让 WebKit 成为 iOS 上独一无二的高价值目标。Android 的浏览器漏洞分散在 Chrome、WebView、各厂商定制浏览器中。

iOS 内核统一但单点风险高。 XNU 内核在所有 iOS 设备上一致，一处漏洞全设备通杀。Android 的 Linux 内核因 OEM 定制而碎片化，一个内核漏洞往往只能影响部分设备————这既是安全优势（攻击面分散），也是安全噩梦（补丁推送困难）。

简言之：Android 漏洞多但分散，iOS 漏洞集中但致命。

五、三个集群的协作关系

这三个集群不是孤立的，它们在真实攻击中形成了一条清晰的攻击链：

媒体处理 (零点击入口)
    → WebKit (代码执行)
        → 内核 (提权)
            → 完全控制设备

大多数在野攻击链都遵循这个模式：

1. 1. 入口：通过媒体处理组件（ImageIO、FontParser）或 WebKit 实现初始代码执行
2. 2. 沙箱逃逸：通过 WebKit 或其他机制突破沙箱限制
3. 3. 提权：通过内核漏洞获得 root 权限
4. 4. 持久化/功能：完全控制设备，部署间谍软件

FORCEDENTRY（2021）走的是"媒体处理 → 内核"路线；BLASTPASS（2023）走的是"WebKit → 内核"路线；Operation Triangulation（2023）则利用了 iMessage 的隐藏附件处理机制。路径不同，终点一致。

六、苹果的应对

苹果并非没有意识到这种集中性风险。近年来的防御策略，本质上就是在给这三扇门加锁：

• • WebKit 加固：引入 PAC（指针认证码）、JIT 编译器强化、网站隔离（Site Isolation）、Lockdown Mode 中禁用部分 WebKit 特性
• • 内核加固：KTRR/CTRR（内核只读区域保护）、kalloc/free 机制强化、iOS 16 引入的快速安全响应（Rapid Security Response）
• • 媒体处理隔离：将 ImageIO、FontParser 等移入独立沙箱进程，限制其权限；iOS 15 起 iMessage 不再自动加载附件

但这些加固有一个共同的局限：它们是在原有架构上的修补，而非架构的重构。WebKit 依然复杂，内核依然是单点，媒体处理依然要自动解析不受信任的数据。只要这些根本条件不变，漏洞就会继续集中在这些组件中。

七、本系列要做什么

"苹果攻防志·组件篇"系列将逐一深入 iOS 上最关键的攻击面，从漏洞数据、技术原理、在野利用案例到苹果的防御演进，给出完整的攻防图景。

接下来的七篇文章，你会看到：

• • WebKit 为什么被称为"新 Flash"，45 个在野利用是怎么发生的
• • XNU 内核的哪些子组件最脆弱，IOMobileFrameBuffer 为什么四度被在野利用
• • 一张图片、一个字体如何成为零点击攻击的弹药
• • 无线攻击面（Wi-Fi、蓝牙、基带）为什么在 iOS 上相对安静
• • Safari、iMessage 这些 App 层的攻击入口
• • 从 FORCEDENTRY 到 Operation Triangulation 的完整攻击链复盘
• • 从零开始理解 iOS 安全术语

每一篇文章都值得单独关注，但更值得把它们连起来读————因为 iOS 攻防从来不是单个组件的故事，而是组件之间如何协作、如何被链条式攻破的故事。

苹果攻防志·组件篇 系列目录

• • No.00 总序：iOS 漏洞为什么总出在这几个组件（本文）
• • No.01 WebKit：苹果最危险的组件没有之一
• • No.02 Kernel：从提权到越狱的必经之路
• • No.03 媒体处理：一张图片一个字体就能攻破
• • No.04 无线攻击面：Wi-Fi、蓝牙和基带
• • No.05 App 层：Safari、消息和那些不起眼的后门
• • No.06 在野利用链：从 FORCEDENTRY 到 Operation Triangulation
• • No.07 iOS 安全术语从小白到入门