SmarterTools SmarterMail < Build 9511 Authentication Bypass via Password Reset API

Falha de autenticação no endpoint force-reset-password do SmarterMail (builds anteriores à 9511): o fluxo de reset para contas de administrador do sistema não valida a senha antiga nem exige token de reset, permitindo que qualquer requisição anônima defina uma nova senha para uma conta sysadmin arbitrária. Como o SmarterMail expõe a administradores a capacidade de executar comandos de sistema via recursos legítimos (System Events), o impacto final é execução de código no host, não apenas takeover de conta web. Está no catálogo KEV da CISA com exploração massiva e automatizada confirmada em produção.

O endpoint HTTP POST /api/v1/auth/force-reset-password é implementado em AuthenticationController.ForceResetPassword e está decorado com [AuthenticatedService(AllowAnonymous = true)] — acesso anônimo é esperado, já que reset de senha por definição precisa funcionar sem sessão. O problema está no corpo aceito: o objeto ForceResetPasswordInputs, desserializado do JSON, expõe diretamente ao cliente os campos IsSysAdmin (bool), Username, OldPassword, NewPassword e ConfirmPassword.

A lógica em AuthenticationService.ForcePasswordReset ramifica com base em IsSysAdmin. Quando true, o código busca o administrador pelo Username informado (SystemRepository.AdministratorGetByUsername) e segue para trocar a senha — mas, segundo a análise de binário da Huntress comparando build 9504 (vulnerável) com 9511 (corrigida), essa ramificação não verificava se o OldPassword enviado correspondia de fato à senha atual do administrador, nem exigia qualquer token de reset out-of-band (como um link enviado por e-mail). Ou seja, o atacante fornece um Username e um NewPassword de sua escolha e a API aceita, sem prova alguma de posse da conta.

A CISA classifica a falha como CWE-288 (Authentication Bypass Using an Alternate Path or Channel): existe um caminho de autenticação "normal" (login com senha) e um caminho alternativo (o endpoint de reset) que não impõe as mesmas garantias. O atacante controla integralmente Username, NewPassword e o booleano IsSysAdmin — este último é o que decide se a vítima do reset é um usuário comum ou o administrador com privilégios totais sobre a instância.

O ataque observado em produção (Huntress) segue uma sequência de chamadas HTTP simples, sem necessidade de autenticação prévia, MFA ou acesso a rede interna — apenas acesso à interface HTTP/API do SmarterMail exposta: primeiro um POST a /api/v1/auth/force-reset-password com IsSysAdmin=true e o Username do administrador-alvo, seguido de POST a /api/v1/auth/authenticate-user para obter um token válido com a nova senha. A partir daí, o atacante tem sessão administrativa completa.

O salto para execução de código explora uma funcionalidade legítima do SmarterMail, não uma segunda vulnerabilidade: administradores podem criar 'System Events' (via /api/v1/settings/sysadmin/event-hook) que disparam comandos quando certas ações ocorrem no sistema. Nos ataques observados, o event hook malicioso era configurado para executar comandos de reconhecimento quando um novo domínio é adicionado; o atacante então cria o domínio (domain-put) para disparar o gatilho, obtendo execução de comando no host — em ambientes Windows típicos, isso ocorre com os privilégios do serviço SmarterMail. Depois, o atacante remove o domínio e o event hook criados (domain-delete, event-hook-delete) como limpeza de rastros.

A watchtowr documentou que a exploração em massa começou apenas dois dias após o lançamento da correção (build 9511, 15/01/2026), evidência forte de que atacantes decompilaram o binário corrigido, compararam com a versão anterior e reconstruíram a falha antes de qualquer PoC pública circular — padrão que os pesquisadores já haviam visto em outra CVE do mesmo produto (CVE-2025-52691) semanas antes. A Huntress confirmou requisições em rápida sucessão contra múltiplos clientes, com IPs e user-agent (python-requests/2.32.4) consistentes, indicando automação em escala, não ataques manuais isolados.

A correção está na build 9511 do SmarterMail, lançada em 15 de janeiro de 2026: atualizar é a única mitigação real, pois a falha está na lógica de validação do endpoint, não em uma configuração que possa ser desativada por flag. Não há paliativo de configuração documentado pelo fornecedor — restringir a exposição da interface HTTP/API do SmarterMail à internet (colocando-a atrás de VPN, allowlist de IP ou controle de acesso de rede) reduz a superfície mas não elimina o risco caso o atacante já tenha acesso à rede interna, e não é substituto para o patch.

Após atualizar, revisar contas de administrador do sistema (senhas podem já ter sido trocadas por um atacante antes do patch), auditar System Events configurados no painel sysadmin (procurar event hooks não reconhecidos) e verificar domínios adicionados/removidos fora de janelas de manutenção conhecidas — indícios de comprometimento anterior à correção.

Esta CVE é distinta de CVE-2025-52691 (upload arbitrário de arquivo levando a RCE), também sob exploração ativa no mesmo produto por volta do mesmo período — corrigir uma não mitiga a outra; ambientes SmarterMail desatualizados devem tratar as duas linhas de patch separadamente.

Nos logs de aplicação do SmarterMail, procurar chamadas POST a /api/v1/auth/force-reset-password com corpo contendo IsSysAdmin:true direcionado a contas administrativas, especialmente sem correlação com uma solicitação de login prévia com ChangePasswordNeeded. A sequência completa observada por atacantes é: force-reset-password → authenticate-user → settings/sysadmin/event-hook → settings/sysadmin/domain-put → domain-delete e event-hook-delete (estas duas últimas usadas para remover evidências); a presença dessa cadeia é um indicador forte de comprometimento bem-sucedido, não apenas de tentativa.

O user-agent python-requests/2.32.4 e os IPs de origem publicados pela Huntress são artefatos de uma campanha específica observada em janeiro de 2026 — têm baixa durabilidade como IOC, já que são triviais de trocar; não deve haver confiança de que a ausência desses indicadores signifique ausência de exploração. Verificar também a existência do arquivo C:\Program Files (x86)\SmarterTools\SmarterMail\Service\wwwroot\result.txt no host, usado como saída de comandos de reconhecimento na campanha documentada, e revisar o log de auditoria interno do SmarterMail (AuditLogSuccess) por entradas de force-reset-password fora do padrão esperado de uso.