Nota 8,6 no CVSS: essa é a gravidade que a Microsoft atribuiu à CVE-2026-80097, falha no componente de broker do Microsoft Authenticator para Android que entregava tokens do Entra ID a qualquer app instalado no aparelho. Os detalhes técnicos ficaram públicos em 27 de outubro de 2026, com a correção já disponível na versão 6.2606.4246, segundo o The Hacker News.
Para quem tem pressa: exija o Authenticator 6.2606.4246 no MDM, audite passkeys registradas desde setembro e revogue sessões de contas suspeitas.
Para quem administra contas corporativas, a pergunta prática é outra: o que mudou entre a versão vulnerável e a corrigida, e o que precisa ser auditado no tenant agora que a falha é conhecida.
Como o broker decidia quem recebia o token
No Android, o Authenticator faz o papel de intermediário de autenticação. Quando Teams, Outlook ou outro app da Microsoft precisa de um token, ele pede ao broker, que devolve a credencial da conta de trabalho conectada.
O defeito estava na identificação de quem pedia. Segundo o Help Net Security, a activity exportada que atendia esses pedidos (AccountChooserActivity) aceitava o nome de aplicativo informado pelo próprio chamador. A checagem de assinatura existia, mas comparava os dados da requisição com a assinatura do Teams verdadeiro instalado no celular, informação que qualquer app consegue ler. O Authenticator até sabia qual pacote fazia a chamada, mas não usava esse dado na decisão.
Versão vulnerável contra versão 6.2606.4246
| Ponto | Antes da correção | A partir da 6.2606.4246 |
|---|---|---|
| Identificação do app que pede o token | Baseada em valores declarados pelo chamador | Corrigida pela Microsoft no broker |
| Permissões exigidas do app malicioso | Nenhuma | Pedido indevido não recebe token |
| Alcance do token desviado | E-mail, arquivos, calendário, SharePoint e Teams da conta conectada | Sem desvio relatado |
| Persistência possível | Criação de passkey própria pelo invasor | Passkeys criadas antes continuam valendo até serem removidas |
A última linha é a que mais pesa para o administrador. O relato da Enclave, empresa cujo pesquisador Ofek Levin encontrou a falha, mostra que o token permitia alterar métodos de autenticação. Um atacante que tivesse registrado uma passkey continuaria entrando mesmo depois de o app malicioso ser apagado e o Authenticator atualizado.
Onde Microsoft e Enclave discordam
A Enclave afirma que a prova de conceito funcionou sem interação do usuário, bastando uma conta conectada. A Microsoft diz que é preciso que a vítima conclua um fluxo de autenticação no Authenticator, e o vetor CVSS registra interação do usuário. A empresa classificou a exploração como “menos provável” e informou não ter visto ataques antes da correção. Até 26 de outubro, a falha não constava do catálogo KEV da agência americana CISA.
Para fins de resposta a incidente, a divergência pouco muda: o ataque exige um app malicioso instalado, o que torna o risco maior em frotas com sideloading liberado ou com aparelhos pessoais sem gestão.
Checklist para quem administra Entra ID e MDM
Na frota de aparelhos
- Versão mínima: configure na política de proteção ou de conformidade de apps a exigência do Authenticator 6.2606.4246 ou superior e bloqueie o acesso de aparelhos abaixo dela.
- Fontes desconhecidas: em dispositivos gerenciados, desative a instalação de pacotes fora da Play Store.
No tenant
- Passkeys e métodos recentes: filtre nos logs de auditoria do Entra ID os registros de novos métodos de autenticação feitos desde setembro e confirme com os usuários os que parecerem estranhos.
- Logs de entrada: procure tokens emitidos pelo broker para clientes incomuns ou acessos ao Graph fora do padrão do usuário.
- Revogação: para contas com qualquer indício, revogue as sessões e exija novo registro de métodos.
O The Hacker News ressalta que não está claro se a atualização invalida tokens obtidos antes. Por isso, revogar sessões em casos suspeitos é mais seguro do que confiar só no patch.
A lição para quem desenvolve componentes exportados no Android
O erro é um padrão conhecido: confiar em dados que o chamador envia em vez de identificar o chamador pelo sistema. Em qualquer activity, serviço ou content provider exportado que devolva dados sensíveis, a decisão deve se basear no UID e na assinatura do pacote obtidos pelo próprio Android, nunca em extras da intent.
Outra frente de cadeia de suprimentos que exige o mesmo tipo de desconfiança é a de dependências, tema do GitHub Package Firewall para proteger dependências npm. A recomendação prática é uma só: rode a auditoria de passkeys antes de encerrar o chamado como resolvido.
