CVE-2026-20516.

I found an improperly exported, system-privileged Miracast service while researching a PEAQ Android TV. A caller can supply an intent extra that makes the service change Wi-Fi Direct state using its own privileges.

MediaTek published the issue in its September 2026 security bulletin and credits Davide Di Matteo in its security acknowledgements. This write-up and the original ADB reproduction are published after coordinated disclosure and vendor approval.

The manifest analysis recorded in the original report shows that MiracastService is exported with android:exported="true", without a permission protecting access to the service. The application declares android:sharedUserId="android.uid.system".

The service's onStartCommand() reads the boolean screen_share intent extra without checking whether the caller is authorized to control Miracast. The service then performs operations in its own privileged context. This is the confused deputy: the caller supplies the request, while the system service supplies the authority.

In the analyzed implementation, the screen_share=false path can call WifiP2pManager.createGroup(). The call is conditional: screen sharing must be disabled in the service state, Wi-Fi P2P must be enabled, and no group must already exist.

The report also records a write to Settings.Global.putInt(..., "miracast_enable", 1) in onCreate(). That is an implementation observation; the log excerpt below does not independently demonstrate that write.

MediaTek describes a local denial-of-service risk. On the tested TV, the recorded ADB session shows the service accepting screen_share=false and successfully creating a Wi-Fi Direct group.

ADB shell runs as the Android shell identity, not as an ordinary application UID. These commands and logs demonstrate the service behavior from ADB; they do not, by themselves, prove execution from a zero-permission application. This publication does not include a separately tested app-based reproduction.

The excerpt does not establish arbitrary code execution, a root shell, a completed connection from a nearby device, or successful group removal. The caller does not acquire the service's system UID; it induces the service to act on its behalf.

The following logcat excerpt was captured on the tested TV on 10 March 2026. It is evidence from the original research, not a new test performed for this publication.

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

The first three lines show parameter receipt, entry into the group-creation path and a successful callback. The last line shows receipt of true; it does not include a removal-success callback.

Device owners should obtain firmware containing the relevant fix from their TV manufacturer. MediaTek identifies the fixes as ALPS11060069 / DTV04881615; no fixed PEAQ firmware version has been verified as part of this write-up.

For maintainers of the component, remove external exposure with android:exported="false" if external callers are unnecessary. If trusted cross-application access is required, protect the service with an appropriate signature-level permission and enforce authorization before changing receiver state.

• MediaTek September 2026 Security Bulletin
• MediaTek Security Acknowledgements
• CVE.org CVE-2026-20516
• Tenable CVE-2026-20516
• The Hacker Wire CVE-2026-20516