Google 的问题追踪器里,一条编号 526109803 的讨论最近吵起来了。起因是无线 ADB 的配对认证被曝出漏洞 CVE-2026-0073,可以绕过验证;负责 ADB 的一位核心维护者提出方案,让 adbd(ADB 守护进程)只绑定 wlan0 接口。这意味着手机本地的 ADB 回环连接,可能被连带切断。
这条提案还没变成产品决定。发布时间、最终监听接口、受影响的系统版本,目前都没有定论。但消息传开后,一批依赖手机本地 ADB 的开发者工具已经开始紧张——Shizuku、libadb-android、App Manager,都建立在这条回环连接上。真正的悬念不是安卓该不该收紧 ADB,而是 Google 能不能把安全补丁和已经获得用户授权的合法用途分开处理。
发生了什么:一条 wlan0 提案,牵动本地 ADB 生态
大多数人熟悉的 ADB,是电脑连手机跑命令那种用法。还有一种更小众的玩法:直接在手机里用 Termux 之类的终端跑 ADB 客户端,通过 127.0.0.1 回环地址连接本机的 ADB 服务端。这就是所谓的"本地 ADB"。
如果 adbd 真的被限定只监听 wlan0,本地回环连接、走 VPN 或以太网的调试路径,大概率会一起失效。这不是猜测,是提案本身的技术后果。
提出这个诉求的开发者做的是 Shizuku 应用 ShizuCallRecorder,本来是为了解决自己的通话录音需求。后来他发现有用户靠这个工具保存已故亲人的语音留言。这类依赖 Shizuku 的无障碍场景,恰恰是最容易被牵连的一批。
为什么重要:安全收益和开发者代价不对等
安卓的调试连接方式这些年一直在收紧。传统 TCP/IP ADB 走明文,靠一个 YES/NO 弹窗认证,打开后会在所有网络接口上监听。Android 11 引入的 Wireless Debugging 要求先配对再加密连接,安全性更高,但依然监听全部接口。本地回环 ADB 只对本机开放,不涉及网络暴露,风险不在"被外部攻击",而在"被本机应用滥用"。
问题在于,如果只允许 adbd 绑定 wlan0,砍掉的恰恰是暴露面最小的那一档。真正暴露在网络上的传统 TCP/IP ADB 和 Wireless Debugging,反而不受影响。这是这条提案最让开发者不服气的地方——安全收益指向的是网络层,代价却落在本机开发者头上。
谁会受影响,接下来看什么
CVE-2026-0073 绕过的是 Wireless Debugging 的配对认证环节,不是普通 TCP/IP ADB 的授权弹窗。传统 TCP/IP ADB 走的仍是明文 YES/NO 弹窗,用户点否,链路照样中断。也就是说,恶意应用不能凭空拿到 ADB 权限,前提始终是用户已经手动打开了调试开关。
但 CVE-2026-0073 提醒了另一件事:配对认证本身也可能被绕过。本地 ADB 的风险不是零,是"低概率但真实存在"。普通用户从没打开过调试开关,链路第一步就断掉,谈不上被攻击;真正暴露的是主动开启调试的开发者本人。
哪些项目会被牵连,程度不一样:
| 项目 | 依赖的连接方式 | 典型用户 | 若仅放开 wlan0 |
|---|---|---|---|
| Shizuku | 本地回环 / 配对后转发 | 需要系统权限的自动化、无障碍开发者 | 可能被迫改走 Wireless Debugging,配对流程变复杂 |
| libadb-android | 本地回环 ADB 客户端库 | 集成 ADB 功能的第三方 App 开发者 | 库本身可能需要重写连接逻辑 |
| App Manager | 本地回环 ADB | 系统管理类 App 用户 | 间接受影响,取决于是否依赖 Shizuku |
| ShizuCallRecorder | 依赖 Shizuku 的无障碍通话录音 | 通话记录、无障碍用户 | 若 Shizuku 授权变复杂,功能可用性下降 |
对使用 Shizuku、Termux 或本地 ADB 工具的开发者和高级用户,短期不用急着换方案。提案还在讨论阶段,wlan0 绑定还没合并进 AOSP 代码。真正该做的是留意自己用的工具是否支持 Wireless Debugging 作为备用连接,一旦有正式改动,能少踩坑。
对依赖设备自动化、无障碍或通话记录工具的用户,风险更现实一些。这类应用往往需要 ADB 授权才能运行,如果回环连接被砍掉,合规的替代路径只剩 Wireless Debugging——但那需要手动配对,重启后可能要重新授权,对不熟悉 ADB 的人不友好。现在能做的,是等开发者公告替代方案,而不是急着卸载或换工具。
原提案作者的诉求也很直白:与其永久关闭本地回环 ADB,不如给一个默认关闭、但用户可手动打开且重启后仍保留的持久化开关。否则 Shizuku 这类工具每次重启都要重新授权,基本没法用。这个诉求能不能被 Google 采纳,以及最终监听接口怎么划,还悬而未决。值得盯住的是 IssueTracker 526109803 后续的官方回复,以及是否有具体 Android 版本被点名。