引言
9 月 24 日，爱沙尼亚独立安全研究员 Rasmus Moorats 公开了一条针对一加手机的本地提权漏洞链：一个不申请任何权限的普通 App，就能在一加 15 上悄悄拿到系统的最高控制权 root，全程没有任何弹窗提示。
这条漏洞链的特别之处在于：它不碰 Android 官方框架，钻的全是一加自研系统服务「AtlasService」和「olc2」的空子。更值得玩味的是时间线——一加今年 5 月就确认了漏洞存在，但到研究员公开披露那天，补丁没发、CVE 编号没给、安全公告也没有，厂商还在邮件里警告研究员「未经许可披露可能承担法律责任」。
很多人的第一反应是：「没申请权限的 App 能干什么坏事？」这正是本文要拆解的认知误区。今天我们把这条漏洞链怎么走通、为什么权限弹窗拦不住它、普通人该怎么防，一次讲清楚。
一、事件复盘
先把时间线捋一遍，全部信息来自研究员公开的披露材料和 The Hacker News 等安全媒体的交叉报道：
2026 年 4 月 18 日：Moorats 向一加报告了两个漏洞。
5 月 20 日：一加回信确认漏洞属实，但同时表示公司拥有「漏洞披露的排他性最终决定权」，并警告研究员：未经允许公开技术细节，可能面临法律责任。一加还透露，这些问题不止影响一加，同样基于这套软件底座的 OPPO 机型也普遍受影响。
6 月 22 日：一加告知修复有进展，请求研究员延期，双方约定至少沉默到 9 月 17 日。
7 月 20 日、9 月 11 日：研究员两次询问修复进展，没有得到回复。
9 月 24 日：研究员如约在 9 月 17 日之后公开了全部技术细节。此时一加依然没有发布修复、没有分配 CVE 编号、没有发布安全公告，也没有给出受影响机型的完整清单。
攻击能力方面：研究员在一台全新未改动的一加 15 上验证成功，一台一加 12 Pro 也复现了。攻击是本地攻击——恶意 App 必须先被安装到手机上，没法纯远程发起。目前没有发现野外利用的迹象。
作为背景，这不是安卓厂商定制层第一次出这类问题：今年 8 月另一位研究员展示了攻击三星、小米、OPPO、一加、Realme 厂商定制代码的零权限 root 技术；2025 年 Rapid7 披露过 OxygenOS 一个让任意 App 偷偷读短信的漏洞，当时一加也是在研究公开后才回应。
二、技术核心拆解
攻击链怎么走通：两节电池串出一把万能钥匙
先翻译几个词。root 可以理解为手机系统的「最高管理员账号」，拿到它，App 就能读写任何数据、关掉安全防护、安装持久的后门。正常情况下，普通 App 与 root 之间隔着一堵厚墙。
这次的问题在于，一加自己在这堵墙上开了两扇没锁好的门。
第一扇门：AtlasService。 这是一加内置的一个系统服务，负责收集调试数据，它以 root 身份运行。按理说，系统服务收到请求时应该先核实「谁在叫我」——就像门卫要查工牌。但 AtlasService 不查：任何装在手机上的 App 都能直接呼叫它。更糟的是，它会把 App 传来的文本不加检查地拼进一条系统命令里执行。这是教科书级别的命令注入。
不过这一步拿到的 root 是受限的——只能在叫 dumpstate 的一个受限区域里活动，干不了所有 root 能干的事。
第二扇门：olc2。 这是一加的一个硬件辅助服务，它有个功能是执行收到的任意 shell 指令。它唯一的防线是：调用者必须已经是 root。而第一步恰好送来了一个受限 root——正好够格敲门。这一次，命令在拥有全部底层 Linux 权限的区域里执行，包括加载内核模块的能力。至此，App 彻底掌控手机。
两个服务各自看都有一定防护逻辑，串起来却是「甲给了钥匙、乙开了金库」。这种漏洞链组合是安全研究里的常见玩法：单个缺陷看似无害，叠加起来就是全面失守。
为什么权限弹窗拦不住它
这是整件事最值得开发者琢磨的技术点。Android 的权限模型管的是标准 API 层：App 想读通讯录、定位、摄像头，系统会弹窗、会记录。但厂商私有系统服务走的是另一条路——App 通过进程间通信（IPC）直接呼叫系统服务，很多这类内部接口不在权限弹窗的管控范围内。
AtlasService 作为 root 服务「不查 caller 身份」，意味着 Android 眼中这是一次合法的系统调用——权限系统全程沉默。用户看到的是一个「零权限」App，而它实际上已经绕过了整个权限体系。
核心争议点：披露权到底归谁
一加在回信中的立场是：欧洲网络安全法规只要求厂商接收并修复报告，没有赋予研究员自行披露的权利。安全社区的普遍看法则相反：欧盟《网络弹性法案》（CRA）和 NIS2 的立法初衷恰恰是保护善意研究员，而不是给厂商「一票否决披露」的权力。
协调披露机制的默契本来是一笔交易：研究员闭嘴等待，厂商在窗口期内把问题修掉。一加拿了五个月，其中一部分时间用来警告发现漏洞的人。补丁迟迟不发的同时还威胁披露者，客观上造成的局面是：漏洞继续存在、防御方不知情、只有掌握全部细节的一方最没有动力行动。
按惯例说明：双方各执一词的部分属于争议陈述，以上仅转述公开信件与安全媒体分析，不做定性。
行业通用规范参照
对照业界惯例，一次标准的协调披露通常包含：给厂商 90 天左右的标准修复窗口、分配 CVE 编号便于追踪、发布安全公告说明影响范围、修复后允许研究员公开技术细节。CVE 编号的意义在于让全世界的防御者能用同一个「病历号」检索、检测、响应——没有 CVE 编号的漏洞，企业安全团队几乎无法纳入资产管理。
三、常见技术误区
误区一：App 没弹权限申请，就是没权限，干不了坏事
这是普通人最容易踩的坑。权限弹窗只覆盖标准 API，厂商私有服务、框架底层接口不在弹窗体系里。一个界面上「什么权限都没要」的 App，可能正通过 IPC 直接呼叫以 root 身份运行的系统服务。判断一个 App 危不危险，安装来源比权限列表更靠前——这次事件里，攻击的起点不是权限，而是「装上了」这个动作本身。
误区二：本地提权漏洞打不到我，远程漏洞才可怕
听起来有道理：得先把恶意 App 装进手机。但现实是，恶意代码很少以「恶意 App」的完整形态出现——它更常藏在正常 App 接入的第三方 SDK、广告组件、破解版工具里。用户以为装的是壁纸软件，广告模块里带了一段提权代码，用户自己并不知道手机上有个「恶意 App」。另外对企业用户，员工自备手机（BYOD）接入公司网络时，一台被 root 的设备就是内网入口。
误区三：厂商确认了漏洞，就等于快修好了
确认只是「承认问题存在」，和「发布修复」之间可能隔着几个月。这次的实锤是：5 月确认，9 月下旬公开披露时仍无补丁、无 CVE、无受影响机型清单。对普通用户来说，判断修复进展别看厂商「回应态度」，要看系统更新日志和安全公告里是否真正点名了这个修复。
四、实操指引
给普通用户（尤其一加 / OPPO 机型）：
- 管住安装来源：只从官方应用商店安装 App，暂缓安装来路不明的 APK——这是补丁落地前唯一有效的防线，因为攻击必须先有一个 App 装进手机。
- 审一遍已装应用：检查有没有不需要任何权限却常驻后台、行为异常的应用，可疑的直接卸载。
- 盯紧系统更新：关注一加 / OPPO 的系统更新公告，等更新日志里明确提到相关安全修复后，第一时间升级。
- 不要侥幸于「没听说有人中招」：目前没有野外利用，但技术细节已经公开，攻击工具化只是时间问题。
给开发者和企业管理员：
- 别把权限模型当成安全边界：评估 App 与设备风险时，把「厂商定制服务是否可被越权调用」纳入威胁模型。
- 企业 BYOD 管控：对使用一加 / OPPO 设备的员工，强制开启 Play Protect 与设备威胁检测，高风险岗位考虑暂停受影响机型接入公司资源，等官方补丁和 CVE 编号落地再恢复。
- 移动端 MDM 策略收紧：限制非商店来源安装（禁用未知来源侧载），对特权 IPC 行为异常的应用做排查。
- 关注披露争议的行业信号：这次事件会改变研究员的披露策略。企业采购设备时，厂商对漏洞的响应速度和透明度，应该进入供应商评估清单。
五、结尾
这条漏洞链技术上并不复杂：一个不查身份的 root 服务、一个只查「你是 root」的执行接口，两块拼图拼出了完整失守。真正值得记住的是两件事——权限弹窗不是安全边界，厂商定制层往往是整个安卓安全栈里最薄弱的一环；以及，协调披露机制的生命力在于双方守约，厂商拿五个月不出补丁还威胁披露者，损害的是整个行业的漏洞报告生态。
对普通用户，行动项就一条：管好安装来源，等一个真正点名的系统更新。对从业者，这又是一堂「不要迷信权限模型」的公开课。
如果觉得有用，欢迎转发给身边用一加 / OPPO 手机的朋友；关于厂商该不该垄断漏洞披露的决定权，也欢迎在评论区聊聊你的看法。