CVE-2026-20516: MiracastService confused deputy on Android TV

Research and disclosure by Davide Di Matteo (@Dingo97).

This is my first credited CVE. 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 following coordinated disclosure and permission from the vendor.

Read on my website · GitHub repository

Vulnerability summary

The impact, patch identifiers and local attack prerequisites are documented in the CVE record. The numeric score and vector above are those published by Tenable. They replace the preliminary 5.1 assessment in my original report. CWE-284 (improper access control) and CWE-441 (confused deputy) describe the original analysis; MediaTek classifies the issue as CWE-926.

Tested environment

These are the details of the device used for the original research, not a list of all vulnerable or fixed firmware versions.

Root cause

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's state, Wi-Fi P2P must be enabled, and no group must already exist. The boolean's name should not be interpreted as a direct statement about whether a group will be created or removed.

The report also records a write to Settings.Global.putInt(..., "miracast_enable", 1) in onCreate(). Triggering the service lifecycle can therefore cause a protected settings write through the service. This is an observation from the implementation analysis; the log excerpt below does not independently demonstrate that write.

The relevant permission checks depend on the Android framework and OEM build. The key issue is the missing authorization at the exported service boundary, rather than a claim that every Android version enforces an identical permission set for Wi-Fi Direct.

Impact and evidence boundaries

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. Unexpected changes to this state can interfere with legitimate Miracast use and may expose a receiver state the user did not request.

The exported component and missing access control support a local-app attack path in the original analysis. ADB shell runs as the Android shell identity, not as an ordinary application UID. Consequently, these commands and logs demonstrate the service behavior from ADB; they do not, by themselves, prove execution from a zero-permission application. This repository does not include a separately tested application-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.

Proof of concept

Prerequisites

• The tested vulnerable firmware, or an equivalent build exposing the same component.
• ADB installed on the host and an authorized debugging connection to a TV you own or are authorized to test.
• Wi-Fi and Wi-Fi Direct available on the TV.
• Two terminals. The host commands below use a POSIX shell, for example Bash or WSL with access to ADB.

The following is the manual reproduction from the original report. It changes Miracast state and force-stops the receiver package. Record the current casting state before running it.

1. Monitor the service

In the first terminal:

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

2. Prepare the receiver state

In the second terminal:

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

This is the reset sequence used in the original reproduction. A package force-stop does not guarantee that the Android Wi-Fi subsystem has removed an existing group. If a group persists, reset the receiver through the TV's controls and verify its state before retrying.

3. Request group creation

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

Look for Enter createGroup followed by createGroup success. If only Received screen_share tag appears, the intent was processed, but group creation has not been demonstrated: check the preconditions described above.

4. Request cleanup and verify the TV

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

This sends the cleanup value used in the original report. Verify that casting and Wi-Fi Direct have returned to the intended state using the TV's controls. Receipt of the intent alone is not proof that cleanup succeeded; restore the receiver manually if necessary.

Captured evidence

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. PID 30288 is visible, but the process UID and caller identity are not recorded in this excerpt.

Affected scope

My reproduction is limited to the PEAQ AI PONT configuration above. MediaTek's bulletin lists affected chipsets beyond that device; consult the vendor's CVE-2026-20516 entry for the authoritative scope. Chipset inclusion does not identify whether a particular retail TV has received its OEM firmware fix.

The package and APK naming suggested a shared MediaTek/Changhong component during the original research. That observation alone does not establish the presence of this exported service on every MediaTek-based TV.

Remediation

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. Review all entry points and lifecycle side effects, including protected settings writes.

These are hardening recommendations from the analysis, not a description of the unpublished vendor patch. Validate the result using an ordinary application UID as well as legitimate casting clients.

Disclosure timeline and credit

Discovered and reported by Davide Di Matteo. Thanks to MediaTek for coordinating disclosure and acknowledging the research in its September 2026 credits.

References

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