CVE-2026-49881 漏洞复现

太初众测
太初众测

太初众测

2026年11月3日 15:30
山东

去阅读

CVE-2026-49881 漏洞复现

本文基于 LSPosed 团队公开 writeup、上游补丁 commit、公开 PoC 源码与实机复现整理。复现环境为 Android 17 模拟器（AVD lsp37 / google\_apis arm64 / SPL 2026-08-05），复现全程在 SELinux Enforcing 下完成，实测普通 App 代码以 system\_server（uid 1000）身份执行，并通过注入把 Shellcode 送进 networkstack 进程（uid 1073）。

01 漏洞介绍

CVE-2026-49881 是 Android Telecom 组件 InCallController.java 中的一个逻辑错误导致的任意代码执行，由 LSPosed 团队（canyie）于 2026 年 7 月 23 日报告 Android 安全团队（被告知为重复漏洞），随 2026-09-01 安全公告修复。它自身即可让普通 App 获得 system\_server（uid 1000）内的任意 Java 执行；与 3 个月前公开的内核漏洞 CVE-2026-43284（DirtyFrag）组合后，可完成从普通 App 到 root 的完整提权并关闭 SELinux——这正是LSPosed公开的完整提权链 LSPromise 的形态。

针对车联网在采用 Android Automotive OS 的智能座舱、车载娱乐主机、T-BOX 与域控制器中，这构成“应用层立足 → 系统最高权限进程”的关键一跃。

一句话概括：一个为防系统崩溃而加的“类存在性检查”，让一个普通 App 的代码以 Android 系统最高身份进程 system\_server 的名义执行——全程无内存破坏、无竞争条件、成功率 100%。

它最反常的一点：这是一段“防崩溃”代码——注释白纸黑字写着“防止清单声明了 Service 但类没编进去导致系统崩溃”，结果却用系统最高身份、以忽略安全的方式执行了不可信 App 的代码；上游的修复方式是把整段逻辑直接删掉。

02 影响范围

两个条件同时成立即受影响：

1. 设备运行 Android 17 初始版本，安全补丁级别（SPL）早于 2026-09-01；

2. 攻击者能以普通应用形式获得立足点（恶意应用、被污染的分发渠道、产线/调试接口预装）。

• 受影响：Android 17 初始版本全设备（含 Pixel 10 首发镜像，2026 年 9 月补丁前均可触发）；运行 QPR beta 的设备当时已修复；

• 不受影响：Android 16 及更早版本（该代码是 Android 17 新引入，无历史包袱）、已升级 2026-09-01 及之后补丁级别的设备。

自检命令（adb）：

在车联网场景中：

车载座舱与T-BOX若基于 Android 17 且补丁基线滞后（车载 OTA 周期通常以季度计，远超手机），即处于受影响面内；攻击链前提是攻击者先以某种方式装上恶意应用。对封闭系统（不开放应用安装、只读根文件系统），本漏洞不构成入口。

03 修复建议

唯一可靠手段： 把平台补丁级别升级到 2026-09-01 或更新（Telecom 洞在该公告中修复）。

没有可靠的临时缓解手段：Telecom 是系统核心组件无法禁用，补丁前无任何配置级开关。补丁空窗期内可做的：

• 车端/终端应用安装管控收紧（白名单商店、禁止侧载），直接抽掉攻击前提；

• 审计清单中声明android.telecom.CLASS\_EXISTENCE\_CHECK meta-data 的应用——正常应用没有任何理由设置这个标志，出现即高度可疑；

• 关注 logcat 中 serviceClassExists check（INFO 级）的异常出现，它几乎是该漏洞触发时留下的唯一痕迹。

04 漏洞原理分析

4.1 专业术语背景介绍

关键背景点：createPackageContextAsUser(...,CONTEXT\INCLUDE\_CODE | CONTEXT\

IGNORE\_SECURITY) 是Android明文标注危险的API组合——它意味着“以我的身份加载并运行对方应用的代码”。这段API出现在任何系统身份组件里，都等于把执行权拱手让人。

4.2 漏洞原理与根因分析

正常流程：系统绑定 InCallService（第三方通话界面/呼叫处理能力）前，要扫描候选服务。Android17的 Telecom 担心“清单里声明了 Service、apk 里却没这个类”导致崩溃，新增了一道“存在性检查”（commit 478761578b3c）声明了特定 meta-data 的服务，先验证类存在，不存在就跳过。

缺陷代码

（android-17.0.0\_r1，InCallController.

java 2603-2627 行，调用方2644-2663 行）：

为什么 false拦不住：三行代码三层叠加：①标志组合让系统加载目标 App 的代码并忽略安全检查；②恶意 App 在清单里给 InCallService贴上CLASS\EXISTENCE\

CHECK=true标签，强制 Telecom 走这个检查；③ Telecom 包声明了 sharedUserId=\"android.uid.system\"、process=\"system\"

（AndroidManifest.xml 第 93 行），这段检查代码运行在 system\_

server 里。而 Class.forName(..., false, ...) 的 false 只能阻止“目标类被初始化” 但 getClassLoader() 会实例化 App在清单中声明的 AppCom-ponentFactory，其静态块随即以system\_server身份

执行。防护判断错了时机：要拦的“初始化”发生在它以为的防线之前，等Class.forName被调用时，攻击者代码已经跑完了。

根因一句话： 一个为防崩溃而加的存在性检查，用系统最高身份、以忽略安全的方式加载了不可信代码，且类加载机制保证 AppComponentFactory 的代码必然先于检查执行。

修复（commit 668eb07260ec）的思路正对病根：直接删除整个 serviceClassExists 逻辑——病根就是“不该用 INCLUDE\_CODE 加载不可信包”，无药可救只能摘除。

漏洞原理与利用链

（红框为两个漏洞本体；组合链至 root 的

实测见 4.5 节）

4.3 白话介绍

把 Android 系统想象成一栋管理严格的写字楼，system\_server 是总控室，里面的人可以调度全楼。CVE-2026-49881是前台新装的一道“来访确认”工序：前台姑娘担心有人登记了公司名字、人却根本没入职，会让大楼出洋相，于是规定——凡是贴了一种特殊标签的访客登记表，她要亲自核实公司是否真实。核实方式倒也直接：把访客的档案册翻开，对照看一眼。

坏就坏在两点。第一，她翻档案册时，用的不是楼道里的公共复印机，而是总控室自己的印鉴——按楼规，这套流程跑在总控室里。第二，访客早料到她会翻：登记表里夹着一张“公司简介”，而这份简介的封皮是特制工艺的——前台的档案册一碰到它，封皮里的机关就自动弹开，里面的指令单立刻以总控室的名义生效。更妙的是，指令单生效的时机在“对照看一眼”之前：等姑娘真正开始核对名字时，该办的事早就办完了。事后问她做了什么，她只会说“我确认了一下这家公司存不存在”。

结果就是： 一个连门禁卡都没有的访客，贴一张标签、递一份档案，就让总控室替他按了手印——没砸锁、没翻墙、没留痕迹，全靠一道“好心办坏事”的确认流程。

4.4 攻击场景与触发条件

触发前提（漏洞层面）： Android 17 初始版本且 SPL 早于 2026-09-01；攻击者能以普通 App 立足（仅需常规安装权限，无需任何危险权限申请）。

隐蔽前提（利用层面）： 无内存破坏、无竞争，内存布局与内核版本均无关；触发点是 Telecom 扫描 InCallService 候选的既有流程，App 侧无额外交互动作。

典型攻击场景：

• 恶意应用伪装成正常车机/手机 App 上架，装机后在系统处理呼叫相关流程时自动触发，以 system\_server 身份读写系统私有数据、操纵其他进程；

• 与浏览器/渲染器漏洞组合（如 IonStack 用 Firefox JIT + GhostLock），实现“点一个链接 → system\_server 内执行”；

• 物理接触场景（维修、产线、调试口）预装应用，直接获得 system 域执行能力。

绕过能力：无内存破坏意味着 KASLR、MTE、CFI、堆缓解全部无关；代码在 system\_server 的 SELinux 域内“合法”执行，SELinux 不构成拦截；触发时只留一行 INFO 级日志 serviceClassExists check，检测面近乎为零。单独本洞到不了 root——system\_server 域被 SELinux 禁止加载 native 库、禁止匿名可执行内存；LSPromise 用它的方式是反射注入把代码送进 networkstack 进程，再接内核阶段（CVE-2026-43284）完成最后一步。

4.5 漏洞复现

4.5.1 复现环境

4.5.2 复现原理

为突出本漏洞的独立危害，复现分两层：第一层是团队自研的最小化 PoC（TelecomACE），只触发 CVE-2026-49881 本身——一个普通 App 不申请任何危险权限，点击按钮后以 system\_server 身份静默授予自己四个危险运行时权限（正常路径必须弹窗经用户手动允许）；第二层是 LSPromise 官方工程验证链的“跳板”价值，确认本洞拿到的 system\_server 执行能力可以注入 networkstack、接通内核阶段。

4.5.3 复现过程与结果

第一层：单独利用（TelecomACE）。攻击前基线——App 是普通应用（uid 10235），安装时四个危险权限全部保持拒绝，读设备序列号直接抛 SecurityException：

点击按钮后，logcat 关键输出（截图与完整 logcat 逐字见文末证据文件）：

logcat 关键输出

设备端实测截图（同一屏幕呈现“攻击前基线 → 触发 → system\_server侧执行结果 → 回到 App 复测”完整故事线）：

复现实测截图

实测截图：uid 10235 的普通 App 点击按钮后，四个危险权限被 system\_server（uid 1000）静默授予，全程无用户授权弹窗

第二层：链验证（LSPromise userspace 阶段）。同一模拟器运行官方 LSPromise APK 触发 userspace 阶段，logcat 依次实证环1（本漏洞）与环2（注入 networkstack）：

第三层：组合链提权 root 实证（2026-10-28，同一模拟器换用团队自编译漏洞内核 6.12.52-4k，完整链一次跑通）：

提权root实证

提权 root 实证：四个文件页缓存补丁完成，init → modprobe 以 root 加载内核模块，SELinux 由 Enforcing 转为 Permissive

复现结论验证项：

✅ 普通 App（uid 10235，无任何特权）→ 点击按钮 → 代码以 system\_server（uid 1000）身份执行，159ms内四个危险权限静默 GRANTED，全程 SELinux Enforcing、无用户交互；

✅ 本洞单独利用的真实危害实证：无需任何内存破坏，“权限弹窗”这一 Android 核心防线被整体绕过；

✅ 链验证：system\_server → networkstack（uid 1073）注入成功、libexp.so 加载——本洞是 LSPromise 完整提权链（配合 CVE-2026-43284 至 root）的入场券；

✅ 对照说明：本机内核 6.12.81-android16 已含链的内核阶段修复，完整链的 runAll 在 patch #2 处按预期终止——框架阶段（本漏洞）行为不受影响，正反两面互证；

✅ 组合链至 root 完整实证：换用漏洞内核 6.12.52-4k 后链一次跑通，getenforce 由 Enforcing 转为 Permissive（见 4.5.3 第三层截图与逐字日志）。

05 车联网相关性分析

该漏洞并非直接影响制动、转向等功能安全的漏洞，但对采用 Android Automotive OS 的智能座舱、车载娱乐主机、T-BOX 及

实际量产系统的限制条件：封闭系统（不开放应用安装、只读根文件系统）不适用本漏洞；车企应在 SBOM 与平台补丁基线中核查 CVE-2026-49881 与 2026-09-01 补丁级别，重点排查座舱/T-BOX 的补丁滞后情况（Google 已改为季度公告，Android 17 发布到修复间隔约 3 个月），并把“应用安装管控”作为补丁空窗期的第一道闸门。该漏洞可视为 ISO/SAE 21434 网络安全风险中的“本地提权环节”，而非直接的功能安全故障。

基于 Android 的域控制器具有直接安全相关性。典型攻击链：攻击者一旦通过恶意车机应用、被污染的应用分发渠道或调试/产线接口获得应用层立足点，即可借本洞提权至 system\_server（uid 1000，system 域），进而读写系统私有数据、操纵其他系统进程，并可作为跳板向 SELinux 白名单进程注入代码——配合内核漏洞（如 CVE-2026-43284）即完成“应用 → 系统 → 内核”的完整提权。

实际车载量产系统多启用 SELinux Enforcing（Android Automotive 强制开启），且车端容器化服务与系统组件（APEX/OTA 沙箱）天然使用 overlayfs 堆叠挂载——与本漏洞的触发地形吻合。限制条件也写清楚：SELinux 处于 Permissive、无嵌套 overlay、内核不含引入提交的车型不受影响。车企应在 SBOM 与内核补丁基线中核查本 CVE，重点排查运行 Linux 7.2 早期版本的座舱与网关平台。该漏洞可视为 ISO/SAE 21434 网络安全风险中的本地策略绕过环节，而非直接的功能安全故障。

06 参考链接

• LSPromise 完整链 writeup + PoC：https://github.com/LSPosed/LSPromise

• 修复 commit：

668eb07260ec Remove serviceClassExists logic to address security vulnerability

• Android 安全公告（2026-09-01）：https://source.android.com/docs/security/bulletin/2026/2026-09-01

• 漏洞源码位置（android-17.0.0\_r1）：https://cs.android.com/android/platform/superproject/+/android-17.0.0\_r1:packages/

services/Telecomm/src/com/android/server/telecom/InCallController.java;l=2603-2663

• canyie 公告背景分析：https://blog.canyie.top/2026/03/18/android-security-bulletin-index-2026/

精彩回顾

END

扫码申请获取PoC