Mainline模块滞后风险

安全公告列出的修复项全部到位，不等于受管终端已处于同一安全基线。2026 年 11 月 Android 安全公告把框架组件的远程代码执行漏洞排在首位，同时列出由 Google Play 系统更新分发的 Mainline 组件：媒体编解码器、MediaProvider、性能分析、Telephonycore 与 WiFi。前者跟随 AOSP 安全补丁级别，后者按模块独立分发，两条交付路径的时间轴并不重合。

设置中显示的安全补丁级别达到 2026-11-05 或更新，只说明公告所述的 AOSP 层面问题已被解决。Mainline 模块能否更新，取决于 Play 系统更新是否真正推送并安装到该设备。常见偏差有三类：厂商 OTA 节奏与模块推送节奏不同步；受管设备因稳定性或流量策略被限制使用 Play 系统更新；设备长期离线或处于隔离网段，模块停留在旧版本。

对攻击者来说，滞后的模块同样是可用入口。Mainline 拆分的初衷是让这部分修复不必等待完整系统 OTA，代价是它不再被补丁级别这一个指标覆盖。仅以补丁级别衡量设备健康度，会系统性低估暴露面。

核查因此需要拆成两步：先拉取补丁级别清单，标记低于 2026-11-05 的终端；再单独核对 Mainline 组件是否已通过 Play 系统更新到达。对补丁级别达标而模块滞后的设备，重点确认更新通道是否被策略阻止。处置按暴露面排序，面向公网、处理敏感数据、难以接收 OTA 的终端优先，离线与隔离网段设备可后置但仍需登记。

还有一处边界：公告确认的是 AOSP 层面的修复，具体机型何时收到 OTA、厂商是否追加自有组件修复，以设备厂商公告为准，这部分信息不会出现在 AOSP 公告里，也没有统一时间表。

把“公告已修复”当成“终端已安全”，是补丁管理中常见的判断偏差。更稳的做法是把补丁级别与 Mainline 模块作为两个独立指标纳入固定核查，对暂时无法收敛的终端施加补偿性管控，比如限制其访问敏感内网资源、缩短凭证有效期。风险窗口通常不在漏洞本身，而在两条更新路径之间的时间差。