CVE-2026-20516：Android TV 上 MiracastService 的混淆代理漏洞

研究与披露：Davide Di Matteo（@Dingo97）。

这是我获得的第一个署名 CVE。我在研究一台 PEAQ Android TV 时，发现了一个导出配置不当、具有系统特权的 Miracast 服务。调用方可以提供一个 intent extra，使该服务利用自身特权更改 Wi-Fi Direct 状态。

MediaTek 在其2026 年 9 月安全公告中发布了该问题，并在其安全致谢中感谢了 Davide Di Matteo。本篇文章及原始 ADB 复现是在协调披露之后、并获厂商许可的情况下发布的。

在我的网站上阅读 · GitHub 仓库

漏洞摘要

影响、补丁标识符和本地攻击前提条件记录在 CVE 记录中。上述数值评分和向量为 Tenable 发布的内容。它们取代了我原始报告中初步的 5.1 评估。CWE-284（不当访问控制）和 CWE-441（混淆代理）描述了原始分析；MediaTek 将该问题归类为 CWE-926。

测试环境

这些是用于原始研究的设备详情，并非所有存在漏洞或已修复固件版本的列表。

根本原因

原始报告中记录的清单分析显示，MiracastService 以 android:exported="true" 导出，且没有保护该服务访问的权限。该应用程序声明了 android:sharedUserId="android.uid.system"。

该服务的 onStartCommand() 读取布尔型 screen_share intent extra，而不检查调用方是否有权控制 Miracast。随后该服务在其自身的特权上下文中执行操作。这就是混淆代理：调用方提供请求，而系统服务提供权限。

在分析的实现中，screen_share=false 路径可以调用 WifiP2pManager.createGroup()。该调用是有条件的：服务的状态中必须禁用屏幕共享，Wi-Fi P2P 必须已启用，且不得已存在任何组。该布尔值的名称不应被解释为关于是否会创建或移除组的直接陈述。

报告还记录了在 onCreate() 中对 Settings.Global.putInt(..., "miracast_enable", 1) 的写入。因此，触发服务生命周期可以通过该服务导致受保护设置的写入。这是实现分析中的一项观察；下面的日志摘录并未独立证明该写入。

相关权限检查取决于 Android 框架和 OEM 构建。关键问题在于导出服务边界处缺少授权，而非声称每个 Android 版本都对 Wi-Fi Direct 强制执行相同的权限集。

影响与证据边界

MediaTek 描述了本地拒绝服务风险。在测试的电视上，记录的 ADB 会话显示该服务接受 screen_share=false 并成功创建了 Wi-Fi Direct 组。此状态的意外更改可能干扰合法的 Miracast 使用，并可能暴露用户未请求的接收器状态。

在原始分析中，导出的组件和缺少访问控制支持本地应用攻击路径。ADB shell 以 Android shell 身份运行，而非普通应用程序 UID。 因此，这些命令和日志从 ADB 角度展示了服务行为；它们本身并不能证明从零权限应用程序执行。本仓库不包含单独测试的基于应用程序的复现。

该摘录并未确立任意代码执行、root shell、来自附近设备的已完成连接或成功的组移除。调用方并未获取服务的系统 UID；它只是诱导服务代表其行事。

概念验证

前提条件

• 已测试的存在漏洞的固件，或暴露相同组件的等效构建。
• 主机上已安装 ADB，并且与您拥有或获授权测试的电视建立了已授权的调试连接。
• 电视上可使用 Wi-Fi 和 Wi-Fi Direct。
• 两个终端。以下主机命令使用 POSIX shell，例如 Bash 或可访问 ADB 的 WSL。

以下是原始报告中的手动复现。它会更改 Miracast 状态并强制停止接收器包。在运行之前，请记录当前的投屏状态。

1. 监控服务

在第一个终端中：

adb logcat | grep -i -E 'screen_share|createGroup|removeGroup'

2. 准备接收器状态

在第二个终端中：

adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share true
sleep 3
adb shell am force-stop com.mediatek.androidbox
sleep 2

这是原始复现中使用的重置序列。强制停止包并不保证 Android Wi-Fi 子系统已移除现有组。如果组仍然存在，请通过电视的控制项重置接收器，并在重试前验证其状态。

3. 请求创建组

adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share false

查找 Enter createGroup，随后是 createGroup success。如果只出现 Received screen_share tag，则 intent 已被处理，但尚未证明组创建：请检查上述前提条件。

4. 请求清理并验证电视

adb shell am startservice -n com.mediatek.androidbox/.MiracastService --ez screen_share true

这会发送原始报告中使用的清理值。请使用电视的控制项验证投屏和 Wi-Fi Direct 已恢复到预期状态。仅收到 intent 并不能证明清理成功；如有必要，请手动恢复接收器。

捕获的证据

以下 logcat 摘录于 2026 年 3 月 10 日在测试的电视上捕获。它是原始研究的证据，并非为本文发布而执行的新测试。

03-10 19:40:27.458 30288 30288 I MiracastService: Received screen_share tag: false
03-10 19:40:27.460 30288 30288 D MiracastService:  Enter createGroup
03-10 19:40:27.530 30288 30288 D MiracastService:  createGroup success
03-10 19:41:19.148 30288 30288 I MiracastService: Received screen_share tag: true

前三行显示了参数接收、进入组创建路径以及成功回调。最后一行显示接收到 true；它不包含移除成功的回调。PID 30288 可见，但此摘录中未记录进程 UID 和调用方身份。

影响范围

我的复现仅限于上述 PEAQ AI PONT 配置。MediaTek 的公告列出了该设备之外的受影响芯片组；请查阅厂商的 CVE-2026-20516 条目以获取权威范围。芯片组的列入并不能确定某台特定零售电视是否已收到其 OEM 固件修复。

在原始研究期间，包名和 APK 命名暗示了 MediaTek/长虹的共享组件。仅凭这一观察并不能确定此导出服务存在于每一台基于 MediaTek 的电视上。

修复建议

设备所有者应从其电视制造商处获取包含相关修复的固件。MediaTek 将修复标识为 ALPS11060069 / DTV04881615；本文未验证任何已修复的 PEAQ 固件版本。

对于该组件的维护者，如果不需要外部调用方，请使用 android:exported="false" 移除外部的暴露。如果需要受信任的跨应用程序访问，请使用适当的签名级权限保护该服务，并在更改接收器状态之前强制执行授权。审查所有入口点和生命周期副作用，包括受保护设置的写入。

这些是分析中的加固建议，并非对未公开厂商补丁的描述。请使用普通应用程序 UID 以及合法的投屏客户端来验证结果。

披露时间线与致谢

由 Davide Di Matteo 发现并报告。 感谢 MediaTek 协调披露并在其2026 年 9 月致谢中认可该研究。

参考资料

• MediaTek — 2026 年 9 月安全公告
• MediaTek — 安全致谢
• CVE.org — CVE-2026-20516
• Tenable — CVE-2026-20516
• The Hacker Wire — CVE-2026-20516