CVE-2024-39891

Um endpoint da API do Twilio Authy aceitava requisições não autenticadas contendo números de telefone e respondia se cada número estava registrado no serviço de MFA Authy. A falha foi usada por um agente de ameaça (ShinyHunters) para compilar e vazar uma lista com mais de 33 milhões de números de telefone associados a contas Authy. O CVSS baixo (5.3) reflete que não houve comprometimento de contas nem exposição de segredos MFA — o dano real é a exposição de dados que facilitam phishing por SMS e SIM swapping em escala.

A vulnerabilidade é classificada como CWE-203 (Observable Discrepancy): o endpoint da API do Authy retornava uma resposta observável e diferenciada dependendo de o número de telefone consultado estar ou não vinculado a uma conta Authy. Isso configura um oráculo de enumeração — não há vazamento de credenciais ou de código MFA, mas a mera existência de uma resposta binária e consistente (registrado / não registrado) por número é suficiente para mapear em massa quais números de telefone usam Authy.

O ponto crítico é a ausência de autenticação e, aparentemente, de rate limiting eficaz no endpoint: o atacante conseguiu alimentar um fluxo (stream) de requisições com grandes listas de números de telefone e coletar as respostas de forma automatizada, sem precisar de uma sessão válida, token de API ou vínculo com uma conta legítima.

O problema fica no lado da API/backend do Twilio, consumida pelos aplicativos Authy Android e iOS — não é uma falha no cliente em si, mas nos apps vulneráveis (versões anteriores às corrigidas) que dependiam dessa API insegura. Após a correção, o endpoint passou a exigir autenticação, eliminando a possibilidade de consulta anônima em massa.

O vetor de exploração é trivial em termos de complexidade técnica: envio de requisições HTTP não autenticadas contra o endpoint da API do Authy, cada uma contendo um número de telefone candidato, e leitura da resposta indicando se aquele número está registrado no serviço. Não é necessário acesso autenticado, conta Authy, dispositivo registrado ou qualquer configuração não padrão — o único pré-requisito é acesso à rede até o endpoint exposto publicamente, que aceitava esse tipo de consulta em volume.

A exploração documentada em junho de 2024 consistiu em alimentar o endpoint com uma lista massiva de números de telefone (presumivelmente obtida de outras fontes ou geração sistemática) e compilar as respostas positivas. O resultado foi um arquivo CSV com mais de 33 milhões de linhas, cada uma contendo account ID, número de telefone, uma coluna

A correção veio do lado do fornecedor: a Twilio afirma ter corrigido o endpoint no backend, passando a exigir autenticação e não mais aceitar requisições anônimas de consulta de números. Não há uma flag de configuração ou parâmetro que o usuário final possa ajustar — a falha estava na API server-side, fora do controle do administrador do app.

A recomendação oficial da Twilio para usuários finais é atualizar o aplicativo Authy para Android versão 25.1.0 ou superior, e iOS versão 26.1.0 ou superior. Vale notar que a própria imprensa especializada (BleepingComputer) observou que não está claro como a atualização do app propriamente protege contra o uso indevido dos dados já vazados — a correção real do vetor de exploração ocorreu no servidor da Twilio, não no cliente. Atualizar o app é a orientação oficial, mas não desfaz a exposição de dados já ocorrida.

Como os números de telefone vazados já estão em circulação, o controle compensatório prático é comportamental: usuários Authy devem reforçar proteção contra SIM swapping no provedor de telefonia (bloqueio de portabilidade/transferência de número sem senha), e manter vigilância elevada contra tentativas de phishing e smishing direcionadas, já que a lista vazada facilita a segmentação de vítimas que sabidamente usam MFA baseado em Authy.

Não há um sinal confiável e acessível a defensores de terceiros para detectar exploração passada, já que o ataque ocorreu contra a infraestrutura backend da Twilio, fora da visibilidade de logs de clientes ou de terceiros. Para a própria Twilio, o padrão de abuso seria um volume anormalmente alto de requisições sequenciais ao endpoint de verificação de números, partindo de poucas origens, sem autenticação — mas essa telemetria não é exposta a operadores de SOC externos.

Para usuários finais, não existe forma de verificar diretamente se o próprio número constava no vazamento de 33 milhões de registros divulgado pelo agente ShinyHunters; a reportagem da BleepingComputer confirma que não havia, até a publicação, um serviço público de consulta (semelhante a um