CVE-2025-48633

Falha de lógica no DevicePolicyManagerService do Android permite que um app malicioso já instalado no dispositivo se torne Device Owner mesmo depois que o provisionamento inicial (setup) já foi concluído — algo que só deveria ser possível em um dispositivo 'limpo', sem contas de usuário. O Google classifica oficialmente como divulgação de informação (Information Disclosure), não como EoP pura, o que explica o CVSS moderado (5.5) mesmo com impacto potencial de assumir controle administrativo do aparelho. Está no catálogo KEV da CISA com evidência de exploração ativa e limitada/direcionada, segundo o próprio boletim de dezembro/2025 do Android.

O método hasAccountsOnAnyUser(), em DevicePolicyManagerService.java, é usado para decidir se o dispositivo pode entrar em fluxo de provisionamento de Device Owner: por design, esse fluxo só deve ser permitido quando não existem contas de usuário cadastradas em nenhum perfil, evitando que um Device Owner seja injetado depois que o dono legítimo já configurou o aparelho. A falha é que a checagem original considerava apenas contas 'visíveis', ignorando contas existentes mas com visibilidade restrita. O commit de correção (d00bcda9f42dcf272d329e9bf9298f32af732f93) resume o problema no próprio changelog: 'Get all accounts no matter the visibility' — ou seja, a versão vulnerável enumerava um subconjunto de contas e concluía erroneamente que o dispositivo estava 'sem contas', liberando o fluxo de provisionamento de Device Owner mesmo em um aparelho já em uso.

É uma vulnerabilidade local (AV:L): exige um app já instalado no dispositivo, sem interação do usuário e sem privilégio elevado adicional (PR:L, UI:N, AC:L). Não há vetor remoto direto — o app precisa primeiro estar presente no aparelho (via engenharia social, sideload, ou abuso de outra permissão) e então acionar o fluxo de provisionamento de Device Owner explorando a lacuna na verificação de contas. Ao conseguir isso, o app malicioso assume papel de Device Owner, que no Android tem controle administrativo amplo sobre o dispositivo (políticas de rede, VPN forçada, restrições de apps, e em alguns casos acesso a dados corporativos/gerenciados) — daí a classificação de risco alta apesar do score CVSS moderado, que reflete só confidencialidade impactada (C:H/I:N/A:N) porque a modelagem oficial trata isso como information disclosure e não como comprometimento total. O boletim de dezembro/2025 da Android indica 'exploração limitada e direcionada' para esta CVE junto com a CVE-2025-48572, consistente com sua inclusão no KEV da CISA — ou seja, há uso documentado fora de laboratório, provavelmente em campanhas de vigilância/spyware que dependem de tomar controle administrativo persistente de um dispositivo específico.

Atualizar para o security patch level 2025-12-05 ou posterior do Android — o próprio boletim afirma que esse patch level cobre todas as falhas listadas para dezembro/2025, incluindo esta. AOSP 13, 14, 15 e 16 receberam o backport (bug interno A-417988098). Não há paliativo de configuração documentado pelo fornecedor para quem não pode atualizar: como o problema está na lógica de verificação de contas antes de liberar o fluxo de Device Owner, mitigação real depende do patch de firmware/framework, não de flag de app ou política de MDM. Como controle compensatório parcial, ambientes corporativos que gerenciam Device Owner via EMM/MDM podem monitorar e restringir instalação de apps não confiáveis (reduz a chance do vetor local se materializar), mas isso não fecha a falha — apenas reduz a superfície de quem pode tentar acioná-la.

Não há assinatura de rede a procurar — é exploração local no framework Android, sem tráfego externo característico. Em nível de dispositivo/EMM, o sinal relevante é um evento de definição de Device Owner (setDeviceOwner / fluxo de provisionamento gerenciado) ocorrendo fora do processo esperado de setup inicial (ex.: em um dispositivo que já estava em uso, com contas de usuário previamente configuradas). Ambientes com MDM devem auditar logs de DevicePolicyManager e alertar sobre qualquer mudança de Device Owner que não corresponda a um provisionamento corporativo intencional; a ausência desse tipo de auditoria explica por que a exploração relatada foi 'limitada e direcionada' — passa despercebida sem monitoramento específico do estado de política de dispositivo.