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

Pesquisa e divulgação por Davide Di Matteo (@Dingo97).

Este é o meu primeiro CVE creditado. Encontrei um serviço Miracast exportado incorretamente e com privilégios de sistema enquanto pesquisava uma PEAQ Android TV. Um chamador pode fornecer um extra de intent que faz o serviço alterar o estado do Wi-Fi Direct usando seus próprios privilégios.

A MediaTek publicou o problema em seu boletim de segurança de setembro de 2026 e credita Davide Di Matteo em seus agradecimentos de segurança. Este write-up e a reprodução original via ADB são publicados após divulgação coordenada e permissão do fornecedor.

Leia no meu site · Repositório no GitHub

Resumo da vulnerabilidade

O impacto, os identificadores de patch e os pré-requisitos de ataque local estão documentados no registro do CVE. A pontuação numérica e o vetor acima são os publicados pela Tenable. Eles substituem a avaliação preliminar de 5.1 do meu relatório original. CWE-284 (controle de acesso inadequado) e CWE-441 (confused deputy) descrevem a análise original; a MediaTek classifica o problema como CWE-926.

Ambiente testado

Estes são os detalhes do dispositivo usado na pesquisa original, não uma lista de todas as versões de firmware vulneráveis ou corrigidas.

Causa raiz

A análise do manifesto registrada no relatório original mostra que MiracastService é exportado com android:exported="true", sem uma permissão protegendo o acesso ao serviço. O aplicativo declara android:sharedUserId="android.uid.system".

O onStartCommand() do serviço lê o extra booleano screen_share do intent sem verificar se o chamador está autorizado a controlar o Miracast. O serviço então executa operações em seu próprio contexto privilegiado. Este é o confused deputy: o chamador fornece a requisição, enquanto o serviço do sistema fornece a autoridade.

Na implementação analisada, o caminho screen_share=false pode chamar WifiP2pManager.createGroup(). A chamada é condicional: o compartilhamento de tela deve estar desabilitado no estado do serviço, o Wi-Fi P2P deve estar habilitado e nenhum grupo deve existir ainda. O nome do booleano não deve ser interpretado como uma afirmação direta sobre se um grupo será criado ou removido.

O relatório também registra uma escrita em Settings.Global.putInt(..., "miracast_enable", 1) em onCreate(). Acionar o ciclo de vida do serviço pode, portanto, causar uma escrita em configurações protegidas por meio do serviço. Esta é uma observação da análise da implementação; o trecho de log abaixo não demonstra de forma independente essa escrita.

As verificações de permissão relevantes dependem do framework Android e da build do OEM. O problema principal é a autorização ausente na fronteira do serviço exportado, e não uma afirmação de que toda versão do Android impõe um conjunto idêntico de permissões para Wi-Fi Direct.

Impacto e limites das evidências

A MediaTek descreve um risco de negação de serviço local. Na TV testada, a sessão ADB registrada mostra o serviço aceitando screen_share=false e criando com sucesso um grupo Wi-Fi Direct. Alterações inesperadas nesse estado podem interferir no uso legítimo do Miracast e podem expor um estado de receptor que o usuário não solicitou.

O componente exportado e o controle de acesso ausente sustentam um caminho de ataque por aplicativo local na análise original. O shell do ADB é executado com a identidade shell do Android, não como um UID de aplicativo comum. Consequentemente, esses comandos e logs demonstram o comportamento do serviço a partir do ADB; eles não provam, por si só, a execução a partir de um aplicativo sem permissões. Este repositório não inclui uma reprodução baseada em aplicativo testada separadamente.

O trecho não estabelece execução de código arbitrário, um shell root, uma conexão concluída a partir de um dispositivo próximo ou remoção bem-sucedida de grupo. O chamador não adquire o UID de sistema do serviço; ele induz o serviço a agir em seu nome.

Prova de conceito

Pré-requisitos

• O firmware vulnerável testado, ou uma build equivalente que exponha o mesmo componente.
• ADB instalado no host e uma conexão de depuração autorizada para uma TV que você possui ou está autorizado a testar.
• Wi-Fi e Wi-Fi Direct disponíveis na TV.
• Dois terminais. Os comandos do host abaixo usam um shell POSIX, por exemplo Bash ou WSL com acesso ao ADB.

A seguir está a reprodução manual do relatório original. Ela altera o estado do Miracast e força a parada do pacote receptor. Registre o estado atual de transmissão antes de executá-la.

1. Monitorar o serviço

No primeiro terminal:

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

2. Preparar o estado do receptor

No segundo 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 é a sequência de reset usada na reprodução original. Um force-stop de pacote não garante que o subsistema Wi-Fi do Android tenha removido um grupo existente. Se um grupo persistir, reinicie o receptor pelos controles da TV e verifique seu estado antes de tentar novamente.

3. Solicitar a criação do grupo

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

Procure por Enter createGroup seguido de createGroup success. Se aparecer apenas Received screen_share tag, o intent foi processado, mas a criação do grupo não foi demonstrada: verifique as pré-condições descritas acima.

4. Solicitar a limpeza e verificar a TV

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

Isso envia o valor de limpeza usado no relatório original. Verifique se a transmissão e o Wi-Fi Direct retornaram ao estado pretendido usando os controles da TV. O recebimento do intent por si só não é prova de que a limpeza foi bem-sucedida; restaure o receptor manualmente se necessário.

Evidências capturadas

O trecho de logcat a seguir foi capturado na TV testada em 10 de março de 2026. É uma evidência da pesquisa original, não um novo teste realizado para esta publicação.

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

As três primeiras linhas mostram o recebimento do parâmetro, a entrada no caminho de criação do grupo e um callback bem-sucedido. A última linha mostra o recebimento de true; ela não inclui um callback de sucesso de remoção. O PID 30288 é visível, mas o UID do processo e a identidade do chamador não estão registrados neste trecho.

Escopo afetado

Minha reprodução é limitada à configuração PEAQ AI PONT acima. O boletim da MediaTek lista chipsets afetados além desse dispositivo; consulte a entrada CVE-2026-20516 do fornecedor para o escopo autoritativo. A inclusão de um chipset não identifica se uma TV de varejo específica recebeu a correção de firmware do seu OEM.

A nomenclatura do pacote e do APK sugeria um componente compartilhado MediaTek/Changhong durante a pesquisa original. Essa observação por si só não estabelece a presença deste serviço exportado em toda TV baseada em MediaTek.

Remediação

Os proprietários de dispositivos devem obter firmware contendo a correção relevante junto ao fabricante da TV. A MediaTek identifica as correções como ALPS11060069 / DTV04881615; nenhuma versão de firmware PEAQ corrigida foi verificada como parte deste write-up.

Para mantenedores do componente, remova a exposição externa com android:exported="false" se chamadores externos forem desnecessários. Se o acesso confiável entre aplicativos for necessário, proteja o serviço com uma permissão de nível de assinatura apropriada e imponha autorização antes de alterar o estado do receptor. Revise todos os pontos de entrada e efeitos colaterais do ciclo de vida, incluindo escritas em configurações protegidas.

Estas são recomendações de hardening da análise, não uma descrição do patch não publicado do fornecedor. Valide o resultado usando um UID de aplicativo comum, bem como clientes legítimos de transmissão.

Cronologia de divulgação e crédito

Descoberto e reportado por Davide Di Matteo. Agradecimentos à MediaTek por coordenar a divulgação e reconhecer a pesquisa em seus créditos de setembro de 2026.

Referências

• MediaTek — Boletim de Segurança de Setembro de 2026
• MediaTek — Agradecimentos de Segurança
• CVE.org — CVE-2026-20516
• Tenable — CVE-2026-20516
• The Hacker Wire — CVE-2026-20516