Cisco Secure Email: corrigir o scanner não encerra a investigação
A falha no gateway de e-mail exige conferir componentes, políticas e evidências. Atualização e resposta a incidentes são entregas diferentes.
A Cisco confirmou exploração da CVE-2026-76519, classificada com CVSS 9,8, no Secure Email Gateway.[1] Um remetente não autenticado pode explorar o processamento de anexos para escrever arquivos e, potencialmente, executar comandos como root.[1] A exposição depende de duas condições simultâneas: File Reputation habilitado e associado a uma política de e-mail, além de Content Scanner Tools anterior a 25.3.0.5525.[1]
O que muda para quem desenvolve
A correção não se resume à versão principal do appliance: o pacote Content Scanner Tools 25.3.0.5525 ou posterior resolve o problema nas versões licenciadas e suportadas, sem atualização completa ou reinicialização.[1] As primeiras versões completas corrigidas indicadas são AsyncOS 15.5.5-014 e 16.5.0-780; para a linha 16.0, não há uma versão completa corrigida listada.[1]
A leitura de engenharia é simples: um inventário que registra apenas o sistema principal não descreve todos os caminhos de processamento. Para quem mantém integrações com e-mail, convém tratar scanner, política aplicada e sistema operacional como evidências separadas. Um campo genérico chamado “atualizado” esconde justamente a diferença que importa.
Também vale separar duas perguntas: o caminho vulnerável foi fechado? O equipamento já havia sido comprometido? Uma resposta não substitui a outra.
Como aplicar
Monte uma tabela por equipamento e por integrante do cluster. Registre a versão efetiva do scanner, a versão do AsyncOS, a política de File Reputation e a evidência usada para conferir cada informação. Evite inferir a versão do componente a partir da data do último pacote instalado.
A Cisco disponibilizou uma verificação nos registros de segurança, que precisa ser executada em cada nó e pode apontar possível comprometimento, resultado inconclusivo ou ausência de indicador.[1] Use essa verificação como uma entrada da investigação, não como certificado automático de integridade. A orientação inclui correlacionar logs externos de rede e firewall, especialmente transferências inesperadas.[1]
Havendo suspeita, preserve evidências antes de atualizar: a atualização pode destruir dados forenses.[1] Para appliances virtuais comprometidos, a recomendação relatada é criar uma VM corrigida, reconstruir a configuração sem importar arquivos anteriores e renovar credenciais e material criptográfico.[1] Planeje essas atividades com responsáveis e critérios próprios de encerramento.
Cuidados e limites
Um resultado negativo na verificação não garante integridade, pois um invasor com root pode apagar evidências.[1] Chaves SSH de um membro comprometido também podem permitir acesso aos demais integrantes do cluster.[1]
A Cisco não divulgou quantidade de equipamentos atingidos nem quantos ataques efetivamente alcançaram root.[1] Não transforme possibilidade técnica em dimensão comprovada da campanha. A prioridade é fechar a exposição e recuperar confiança no ambiente, sem fingir que instalar um pacote resolve retroativamente um incidente.
Fonte
[1] Fonte: The Hacker News