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

Investigación y divulgación por Davide Di Matteo (@Dingo97).

Este es mi primer CVE acreditado. Encontré un servicio Miracast con privilegios de sistema, exportado incorrectamente, mientras investigaba un PEAQ Android TV. Un llamador puede proporcionar un extra de intent que hace que el servicio cambie el estado de Wi-Fi Direct usando sus propios privilegios.

MediaTek publicó el problema en su boletín de seguridad de septiembre de 2026 y acredita a Davide Di Matteo en sus reconocimientos de seguridad. Este análisis y la reproducción original con ADB se publican tras la divulgación coordinada y con el permiso del proveedor.

Leer en mi sitio web · Repositorio de GitHub

Resumen de la vulnerabilidad

El impacto, los identificadores del parche y los requisitos previos del ataque local están documentados en el registro CVE. La puntuación numérica y el vector anteriores son los publicados por Tenable. Reemplazan la evaluación preliminar de 5.1 de mi informe original. CWE-284 (control de acceso incorrecto) y CWE-441 (confused deputy) describen el análisis original; MediaTek clasifica el problema como CWE-926.

Entorno probado

Estos son los detalles del dispositivo utilizado para la investigación original, no una lista de todas las versiones de firmware vulnerables o corregidas.

Causa raíz

El análisis del manifiesto registrado en el informe original muestra que MiracastService está exportado con android:exported="true", sin un permiso que proteja el acceso al servicio. La aplicación declara android:sharedUserId="android.uid.system".

El onStartCommand() del servicio lee el extra booleano screen_share del intent sin comprobar si el llamador está autorizado a controlar Miracast. El servicio entonces realiza operaciones en su propio contexto privilegiado. Este es el confused deputy: el llamador proporciona la solicitud, mientras que el servicio del sistema proporciona la autoridad.

En la implementación analizada, la ruta screen_share=false puede llamar a WifiP2pManager.createGroup(). La llamada es condicional: la compartición de pantalla debe estar deshabilitada en el estado del servicio, Wi-Fi P2P debe estar habilitado y no debe existir ya un grupo. El nombre del booleano no debe interpretarse como una afirmación directa sobre si se creará o eliminará un grupo.

El informe también registra una escritura a Settings.Global.putInt(..., "miracast_enable", 1) en onCreate(). Por lo tanto, desencadenar el ciclo de vida del servicio puede provocar una escritura en ajustes protegidos a través del servicio. Esta es una observación del análisis de la implementación; el extracto de registro a continuación no demuestra de forma independiente esa escritura.

Las comprobaciones de permisos relevantes dependen del framework de Android y de la compilación del OEM. El problema clave es la autorización ausente en el límite del servicio exportado, más que la afirmación de que todas las versiones de Android aplican un conjunto de permisos idéntico para Wi-Fi Direct.

Impacto y límites de la evidencia

MediaTek describe un riesgo de denegación de servicio local. En el televisor probado, la sesión de ADB registrada muestra que el servicio acepta screen_share=false y crea con éxito un grupo de Wi-Fi Direct. Los cambios inesperados en este estado pueden interferir con el uso legítimo de Miracast y pueden exponer un estado del receptor que el usuario no solicitó.

El componente exportado y la ausencia de control de acceso respaldan una ruta de ataque desde una aplicación local en el análisis original. El shell de ADB se ejecuta con la identidad shell de Android, no con un UID de aplicación ordinario. En consecuencia, estos comandos y registros demuestran el comportamiento del servicio desde ADB; por sí solos, no prueban la ejecución desde una aplicación sin permisos. Este repositorio no incluye una reproducción basada en una aplicación probada por separado.

El extracto no establece ejecución de código arbitrario, un shell root, una conexión completada desde un dispositivo cercano ni una eliminación exitosa del grupo. El llamador no adquiere el UID de sistema del servicio; induce al servicio a actuar en su nombre.

Prueba de concepto

Requisitos previos

• El firmware vulnerable probado, o una compilación equivalente que exponga el mismo componente.
• ADB instalado en el host y una conexión de depuración autorizada a un televisor que sea de su propiedad o que esté autorizado a probar.
• Wi-Fi y Wi-Fi Direct disponibles en el televisor.
• Dos terminales. Los comandos del host a continuación usan un shell POSIX, por ejemplo Bash o WSL con acceso a ADB.

La siguiente es la reproducción manual del informe original. Cambia el estado de Miracast y fuerza la detención del paquete receptor. Registre el estado actual de transmisión antes de ejecutarla.

1. Monitorizar el servicio

En la primera terminal:

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

2. Preparar el estado del receptor

En la segunda 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

Esta es la secuencia de reinicio utilizada en la reproducción original. Una detención forzada del paquete no garantiza que el subsistema Wi-Fi de Android haya eliminado un grupo existente. Si un grupo persiste, reinicie el receptor mediante los controles del televisor y verifique su estado antes de volver a intentarlo.

3. Solicitar la creación del grupo

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

Busque Enter createGroup seguido de createGroup success. Si solo aparece Received screen_share tag, el intent se procesó, pero no se ha demostrado la creación del grupo: compruebe las condiciones previas descritas anteriormente.

4. Solicitar la limpieza y verificar el televisor

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

Esto envía el valor de limpieza utilizado en el informe original. Verifique que la transmisión y Wi-Fi Direct hayan vuelto al estado deseado usando los controles del televisor. La recepción del intent por sí sola no es prueba de que la limpieza haya tenido éxito; restaure el receptor manualmente si es necesario.

Evidencia capturada

El siguiente extracto de logcat se capturó en el televisor probado el 10 de marzo de 2026. Es evidencia de la investigación original, no una nueva prueba realizada para esta publicación.

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

Las tres primeras líneas muestran la recepción del parámetro, la entrada en la ruta de creación del grupo y una callback exitosa. La última línea muestra la recepción de true; no incluye una callback de éxito de eliminación. El PID 30288 es visible, pero el UID del proceso y la identidad del llamador no se registran en este extracto.

Alcance afectado

Mi reproducción se limita a la configuración del PEAQ AI PONT anterior. El boletín de MediaTek enumera chipsets afectados más allá de ese dispositivo; consulte la entrada CVE-2026-20516 del proveedor para conocer el alcance autorizado. La inclusión de un chipset no identifica si un televisor comercial concreto ha recibido la corrección de firmware de su OEM.

El nombre del paquete y del APK sugería un componente compartido de MediaTek/Changhong durante la investigación original. Esa observación por sí sola no establece la presencia de este servicio exportado en todos los televisores basados en MediaTek.

Remediación

Los propietarios de dispositivos deben obtener el firmware que contenga la corrección correspondiente de su fabricante de televisores. MediaTek identifica las correcciones como ALPS11060069 / DTV04881615; no se ha verificado ninguna versión de firmware de PEAQ corregida como parte de este análisis.

Para los mantenedores del componente, eliminen la exposición externa con android:exported="false" si los llamadores externos no son necesarios. Si se requiere acceso entre aplicaciones de confianza, protejan el servicio con un permiso de nivel de firma adecuado y apliquen la autorización antes de cambiar el estado del receptor. Revisen todos los puntos de entrada y los efectos secundarios del ciclo de vida, incluidas las escrituras en ajustes protegidos.

Estas son recomendaciones de endurecimiento derivadas del análisis, no una descripción del parche no publicado del proveedor. Validen el resultado usando un UID de aplicación ordinario, así como clientes de transmisión legítimos.

Cronología de divulgación y crédito

Descubierto y reportado por Davide Di Matteo. Gracias a MediaTek por coordinar la divulgación y reconocer la investigación en sus créditos de septiembre de 2026.

Referencias

• MediaTek — Boletín de seguridad de septiembre de 2026
• MediaTek — Reconocimientos de seguridad
• CVE.org — CVE-2026-20516
• Tenable — CVE-2026-20516
• The Hacker Wire — CVE-2026-20516