你以为开了"始终开启VPN"和"无VPN时阻断连接"就万无一失？Android 16的一个底层设计缺陷，能让普通权限的恶意应用绕过所有防护，直接把你的真实IP地址暴露给攻击者。

安全研究人员将这个漏洞命名为"Tiny UDP Cannon"（微型UDP大炮）。它的破坏力与名字形成反差——不需要 root 权限，不需要复杂利用链，任何一个拥有基础网络权限的常规应用都能触发。

打开网易新闻 查看精彩图片

漏洞的核心藏在 Android 的 ConnectivityManager 服务里。恶意应用无需直接发送数据，而是向系统进程 system_server 注册一个"载荷"。这个系统进程拥有 elevated privileges（高阶权限），且不受 VPN 路由规则约束。当应用退出或套接字销毁时，system_server 会自动通过设备的物理网络接口（如 Wi-Fi）发送攻击者预设的数据，VPN 隧道被完全架空。

触发这一机制的方法名为 registerQuicConnectionClosePayload。研究人员发现该方法存在三处关键缺失：没有权限校验、没有载荷验证、也不感知 VPN 锁死策略。INTERNET 和 ACCESS_NETWORK_STATE 这两个 Android 自动授予的权限，就足以完成整个利用流程。

攻击者能做什么？三件事：获取用户的真实公网 IP 地址、在加密隧道外外泄数据、以及在用户自认为受隐私保护的情况下持续追踪。研究人员在 Pixel 8 上实测成功——Android 16 系统，Proton VPN 开启，锁死模式激活，真实 IP 照样泄露。

识别攻击并非易事，但仍有几处痕迹可循：异常的 UDP 包流出 VPN 隧道、源 IP 显示为设备真实 Wi-Fi 地址（如 192.168.x.x 段）、目的地指向攻击者控制的服务器（常见端口如 3131）、载荷内容可能带有标记（如 EXFIL{src=IP} 格式）。发起流量的进程是 system_server（UID 1000），而非应用自身。

这个漏洞于 2026 年 4 月提交至 Google Android 漏洞奖励计划（VRP）。Android 安全团队的回应出人意料：分类为"Won't Fix (Infeasible)"，认为不符合安全公告收录标准。研究方 lowlevel.fun 则坚持认为，该缺陷对依赖 VPN 实现匿名的用户构成重大隐私风险。

临时缓解方案存在，但代价是功能阉割。通过 ADB 命令 adb shell device_config put tethering close_quic_connection -1 关闭 QUIC 相关特性，重启后系统不再发送注册载荷，泄露通道被切断。然而这不是官方修复，未来系统更新可能覆盖该设置。

更值得深思的是漏洞背后的设计哲学。system_server 作为系统级组件获得网络豁免，本意是保障基础功能可用，却成为安全架构的盲区。当"锁死模式"的宣传语遭遇"系统进程例外"的现实，用户的信任模型便出现裂痕。VPN 厂商在应用层能做的防护有限——流量根本没过它们的隧道。

Google 的"不予修复"判定依据未公开，但通常涉及修复复杂度与攻击场景的平衡。问题在于：一个零权限门槛、稳定触发、绕过核心安全功能的漏洞，是否真属于"不可行"范畴？对于记者、异见人士、企业安全团队这类高依赖 VPN 的群体，答案可能不同。

目前用户能做的选择有限：启用 ADB 缓解命令并承担后续维护成本，或等待社区反馈促使官方重新评估。无论哪种，都指向同一个尴尬现实——移动操作系统的安全承诺，在系统架构深层仍留有讨价还价的空间。