SMS of Death no Android: disponibilidade também precisa entrar no modelo de ameaça

Uma prova de conceito para a CVE-2026-58882, chamada de SMS of Death, mostra que uma mensagem especialmente formada pode derrubar o processo de telefonia de aparelhos Android sem interação da vítima.[9] O processamento ocorre antes da exibição na caixa de entrada e pode afetar chamadas em andamento, inclusive de emergência.[9] O impacto relatado é indisponibilidade, não uma demonstração de roubo de dados ou execução remota de código.[9]

O que muda para quem desenvolve

A falha envolve a validação de comprimento em WapPushOverSms.decodeWapPdu: um valor interpretado incorretamente leva à tentativa de alocar memória com tamanho negativo, gera uma exceção e derruba com.android.phone.[9] A correção descrita captura exceções e remove mensagens maliciosas da base para evitar novas quedas durante o reprocessamento.[9]

Minha leitura é que há duas responsabilidades distintas a avaliar em qualquer consumidor de mensagens: resistir a uma entrada inválida e não ficar preso nela depois de reiniciar. Eu incluiria ambas nos critérios de aceitação de parsers, importadores e trabalhadores de filas.

Para aplicações que usam SMS na autenticação ou recuperação, recomendo revisar a dependência de um único canal. A proposta não é declarar o SMS inutilizável por causa desta notícia, mas definir o que o usuário consegue fazer quando a telefonia não está disponível.

Como aplicar

No inventário de dispositivos, registre modelo, versão do Android e nível efetivo de atualização instalado. Segundo o pesquisador citado, a correção chegou às atualizações de outubro para Android 14 a 17, enquanto Android 12 e 13 permaneciam sem a correção mencionada; a entrega depende do fabricante e da operadora.[9] Não trate a versão principal do sistema como confirmação de instalação do reparo.

Na aplicação, faça um exercício de recuperação com conta sintética e o canal SMS indisponível. Verifique se o usuário encontra uma alternativa previamente cadastrada, se ela exige comprovação adequada de identidade e se a operação fica auditável. A alternativa não deveria virar um atalho que dispense os controles da autenticação normal.

Para código próprio que lê mensagens, proponha entradas de teste com comprimentos inválidos e um item persistido que falha repetidamente. Observe se o processamento isola o item sem bloquear todo o serviço.

Cuidados e limites

A reportagem informa que a vulnerabilidade não aparecia no boletim de segurança de outubro, embora o pesquisador apontasse a correção naquele ciclo.[9] Preserve essa atribuição ao consultar o fabricante, em vez de prometer cobertura universal.

Não execute a prova de conceito em aparelhos de uso real. O objetivo operacional é atualizar, confirmar a instalação e manter recuperação segura. A classificação correta do impacto também importa: uma interrupção grave merece resposta sem precisar ser rebatizada como controle completo do telefone.

Fonte

[9] Fonte: BleepingComputer