“大 root 时代来了？”“点击恶意链接即可远程 root 全版本安卓设备0day？”先别急 CVE-2026-43499和CVE-2026-10702组合是否真的可以一键root安卓手机？

最近看到网传安卓系统0day，说实话第一眼给我吓一跳

首先强调：漏洞是真的，攻击链也确实有技术含量。

CVE-2026-10702 + CVE-2026-43499 这两个漏洞结合在一起非常精妙，一个负责从浏览器网页进入本地进程，一个负责从本地低权限进程继续打到内核提权。

但最近一些“点击恶意链接即可远程 Root 全版本安卓设备”“安卓全版本通杀”“大 Root 时代来临”的说法，明显已经把技术事实包装成流量标题了。

说实话，用这个漏洞制造“点一下链接就被获取root”的焦虑，确实很适合博流量、博眼球，但并不适合严肃讨论安全风险。

这篇文章不讨论利用细节，只聊几个关键问题。

真的是全版本安卓设备root吗？

很多人看到 Android 17 设备受影响，就会自然推导出一句话：

新版本都能打，老版本肯定也能打。

这个推导不严谨。

Android 内核不是一个统一版本。不同厂商、不同 SoC、不同机型、不同补丁日期，内核配置和 vendor patch 差异非常大。即使都叫 Linux 5.x 或 6.x，实际结构体布局、符号偏移、KASLR 行为、SLAB 策略、SELinux 策略、seccomp 限制都可能不同。

CVE-2026-43499 的漏洞点在 Linux kernel 的 futex / rtmutex 相关路径。漏洞原理可以是通用的，但 exploit 稳定落地不是通用的。

为什么公开仓库里会有一堆：

因为这类内核提权需要做设备构建级适配。不是“Pixel 全系列”，更不是“安卓全版本”。

如果一个漏洞真的是全版本通杀，它不应该需要这么多 target.h 。

这条链真正做了什么？

这条链不是“网页直接 Root 手机”，而是把两个不同层级的漏洞串成了一条非常优雅的利用链。

用户访问恶意网页
  -> CVE-2026-10702 触发 Firefox JIT 错误编译
  -> 获得 Firefox 进程内低权限代码执行
  -> 从 Firefox 进程触发 futex / rtmutex 内核漏洞
  -> 获得内核读写或等价能力
  -> 修改当前运行时权限状态
  -> 得到运行时 root 效果

这里的关键点是：浏览器漏洞负责远程入口，内核漏洞负责本地提权。这条链的工程含量很高，在我看来是一段非常优雅的利用链。

但它仍然不是“所有安卓点开链接自动永久 Root”

它依赖：

  - 目标设备安装的是受影响版本的 Firefox，例如修复前的 151.0.2 及更早版本；
  - Firefox Android 上的 JIT 配置、优化阈值、CPU 架构和运行环境能稳定触发 CVE-2026-10702；
  - CVE-2026-10702 不只是造成崩溃，而是能被利用成稳定的 Firefox 进程内代码执行；
  - 目标 Android 内核确实没有修补 CVE-2026-43499；
  - 目标内核启用了相关 futex / RT mutex 功能路径；
  - Firefox 进程的 seccomp、sandbox、SELinux domain 没有阻断后续提权所需的关键 syscall 或文件访问；
  - 目标机型和具体构建已经完成 exploit 适配；
  - 内核提权阶段能够正确处理 KASLR、内核符号、结构体偏移、SLAB/SLUB 行为、对象布局、cred 布局、SELinux 状态等设备相关细节；
  - 提权成功后，还要处理 Android 上 root shell 可见性、mount namespace、adbd 视图、权限继承等运行时问题。

这个漏洞更准确的说法应该是：

在特定 Firefox 版本、特定 Android 内核补丁状态、特定机型和构建适配条件下，攻击者可能通过恶意网页触发 Firefox JIT RCE，并串联 Linux kernel futex / rtmutex 漏洞完成运行时提权。

少一个条件，结果可能就是崩溃、无效，或者只停留在浏览器沙箱内。

想玩机刷root，这种 root 和解 BL 刷 root 一样吗？

我还在一些b站评论区看到言论

不一样。差别非常大。

漏洞链拿到的 root，通常是瞬态 root。它是在系统已经启动后，通过漏洞临时修改当前运行环境里的权限状态。

重启之后，很多状态会消失。

如果想持久化，就会遇到现代 Android 的启动链保护：

AVB
verified boot
rollback protection
动态分区
只读分区
SELinux
厂商自定义校验

也就是说，哪怕你运行时拿到了 root，也不代表你可以随便改 boot、vendor_boot、init_boot、recovery、system，然后让设备长期启动修改后的系统。

锁 BL 状态下，启动链会验证镜像。你能不能写分区是一回事，写完能不能被 ABL / boot chain 接受，是另一回事。

所以如果你是为了玩机，比如：

刷 Magisk；
刷 KernelSU；
修改 boot 镜像；
长期保留 root；
刷第三方 recovery；
换系统；
改 vendor 或 system；

那么这种漏洞链 root 通常不能满足你的需求。

这是为什么？

很多人把 Android root 当成最高权限，是因为在普通 Linux 用户空间里，uid=0 已经非常强。

但从 CPU 特权级看，Android root 仍然是 EL0 用户态。

ARMv8 常见层级可以这样理解：

EL0: 用户态
普通 App、shell、su、root shell

EL1: 内核态
Linux kernel、驱动、内核内存、页表、调度、LSM/SELinux

EL2: Hypervisor
高通平台上可能涉及 Gunyah、pKVM 等虚拟化或隔离层，具体看设备

EL3: Secure Monitor
TrustZone 安全监控 Firmware

所以 Android root 很强，但它不是硬件最高权限。

真正控制页表、调度、驱动对象、内核内存的是 EL1 kernel。再往上还有 EL2 hypervisor、EL3 secure monitor，以及 TrustZone 安全世界里的 TEE、Keymaster、RPMB、secure storage 等。

这也是为什么“拿到 root”不等于“解锁 BL”，更不等于“掌握设备全部信任链”。

解 BL 或启动链漏洞，解决的是另一个问题：

设备是否允许物理持有人启动自己修改过的系统。

这和运行时漏洞提权不是一个层级的问题。