Em 1 de outubro de 2026, a Fortinet publicou um aviso de segurança sobre uma vulnerabilidade no FortiMail, seu gateway de segurança de e-mail, e confirmou que a falha está sendo explorada ativamente. A Agência de Cibersegurança e Segurança de Infraestrutura dos Estados Unidos (CISA) adicionou a vulnerabilidade ao seu catálogo de vulnerabilidades exploradas conhecidas no mesmo dia e deu às agências federais civis até 4 de outubro de 2026 para aplicar a correção ou uma solução alternativa. As versões que resolvem completamente o problema ainda não foram publicadas, o que significa que boa parte do perímetro de segurança de e-mail de muitas organizações depende hoje de um comando de CLI e não de uma atualização de software.
O que a vulnerabilidade faz
A falha é identificada como CVE-2026-104286 e tem pontuação CVSSv3 de 9.8, o topo da escala de gravidade. Ela combina uma fragilidade de path traversal, catalogada como CWE-22, com a neutralização incorreta de caracteres de byte NULL, CWE-158. O efeito prático é que um atacante sem autenticação pode gravar arquivos arbitrários no sistema subjacente de um appliance FortiMail por meio de requisições HTTP ou HTTPS forjadas. Nenhuma credencial é necessária.
As versões afetadas são FortiMail 8.0.0 a 8.0.1, 7.6.0 a 7.6.6, 7.4.0 a 7.4.8 e 7.2.0 a 7.2.9. A Fortinet corrigirá o problema nas versões 8.0.2, 7.6.7 e 7.4.9, nenhuma delas publicada até o momento do aviso, e recomenda que os usuários do ramo 7.2 migrem para o 7.4 ou superior quando as correções estiverem disponíveis. A vulnerabilidade foi descoberta internamente por Gwendal Guégniaud, da equipe de segurança de produtos da Fortinet.
Como fica um equipamento comprometido
A Fortinet compartilhou indicadores de comprometimento para que administradores verifiquem se seus appliances foram afetados. A infraestrutura do atacante inclui os endereços IP 79.141.169[.]187 e 45.129.0[.]192. Os indicadores de arquivo são mais reveladores. Entre os arquivos adicionados estão /data/lib/liblog.so, /data/bin/webconsole, /data/bin/mailservice e /data/etc/ld.so.preload. Os arquivos modificados incluem /bin/smit, /data/etc/httpd.conf e /data/migadmin.tar.gz.
A presença de um arquivo ld.so.preload adicionado ou modificado merece atenção especial, porque esse arquivo controla quais bibliotecas compartilhadas o carregador dinâmico insere nos processos na inicialização. Manipulá-lo é uma técnica conhecida para executar código controlado pelo atacante dentro de processos legítimos, algo típico da instalação de uma backdoor e não de um simples escaneamento oportunista. A Fortinet não detalhou quando nem onde os ataques foram observados, quantos equipamentos foram comprometidos nem quem está por trás, então o alcance completo continua desconhecido.
O que fazer agora
Até que existam versões corrigidas, a Fortinet oferece duas mitigações. A primeira é desativar o suporte a IBE, o recurso de criptografia baseada em identidade, com estes comandos de CLI:
config system encryption ibe
set status disable
end
A segunda é desativar o acesso pela internet à interface de administração do FortiMail ou restringi-lo a uma rede privada confiável. Os administradores também devem comparar os indicadores de arquivos e os endereços IP acima com seus próprios registros, porque o patch ainda não existe e a detecção é hoje a única forma de saber se um ambiente específico foi alvo.
Por que isso importa além do appliance
Um FortiMail comprometido não é apenas um problema de infraestrutura para repassar ao time de rede. O appliance está diretamente no caminho do seu e-mail. Ele vê o e-mail que entra antes dos seus usuários, aplica a filtragem antispam e antiphishing e, em muitos ambientes, também cuida do e-mail que sai. Um atacante com capacidade de gravação arbitrária de arquivos nesse equipamento tem um ponto de observação sobre todo o fluxo de mensagens: pode ler e-mails, enfraquecer a filtragem que protege seus usuários e manipular mensagens em trânsito.
É exatamente por isso que padrões de autenticação em nível de domínio como o DMARC importam tanto em um incidente desses. O DMARC não é aplicado no seu gateway. Ele é aplicado pelo servidor de e-mail do destinatário, que verifica de forma independente o alinhamento de SPF e DKIM com o domínio do cabeçalho From visível antes de decidir o que fazer com a mensagem. Um receptor que aplica sua política p=reject recusará o e-mail falsificado que alega vir do seu domínio não importa o que um appliance intermediário comprometido tenha feito ou deixado de fazer no caminho.
Há uma segunda implicação, menos confortável. Se um atacante obtiver controle suficiente sobre a infraestrutura de e-mail, ele pode enviar mensagens que passam pela autenticação de forma legítima, porque realmente se originam de uma infraestrutura que você controla. Isso não é uma falha do DMARC. O DMARC responde à pergunta de se uma mensagem veio realmente do domínio que alega vir, e o e-mail de um remetente legítimo comprometido veio. O que o DMARC oferece aqui é outra coisa: seus relatórios agregados se tornam um sistema de alerta antecipado. Uma mudança repentina nos resultados de autenticação, fontes de envio inesperadas ou anomalias de volume nos seus dados de DMARC é exatamente o sinal que revela rápido um componente interno comprometido, se alguém estiver lendo os relatórios.
O que isso significa para o seu programa
Trate o gateway como alvo, não apenas como escudo. Appliances de segurança que ficam no caminho do e-mail são alvos de alto valor justamente por onde ficam. Eles precisam da mesma disciplina de patches, da mesma restrição de exposição das interfaces de administração e da mesma vigilância de comprometimento que qualquer sistema exposto à internet.
Aplique controles em camadas. Um único appliance, por bom que seja, é um único componente. A aplicação de DMARC nos receptores, a assinatura DKIM em uma camada que o atacante não alcançou e o monitoramento dos relatórios agregados juntos dão uma proteção que não depende de uma única máquina permanecer limpa.
Acompanhe seus relatórios de DMARC durante qualquer incidente de segurança. Durante e depois de um evento assim, a telemetria de autenticação é uma das formas mais rápidas de confirmar se houve manipulação do fluxo de e-mail ou se surgiram novas fontes de envio. Relatórios que ninguém lê não podem alertar ninguém.
Reduza a exposição do plano de gestão em todos os lugares. A mitigação recomendada pela Fortinet, manter interfaces de administração fora da internet, vale para cada componente da sua infraestrutura de e-mail, não apenas para o FortiMail.
A conclusão
Um zero-day com pontuação 9.8, sem patch disponível e explorado ativamente em um appliance que protege o e-mail de milhares de organizações é uma situação séria por qualquer métrica. As organizações que vão atravessá-la melhor serão as que aplicaram a mitigação imediatamente, verificaram os indicadores de comprometimento e já tinham uma segunda camada de autenticação em nível de domínio em vigor, de modo que um único componente comprometido não se traduzisse em liberdade total para falsificar seu domínio.
Ameaças de e-mail não se organizam conforme o seu ciclo de patches. O Excello Mail dá visibilidade contínua sobre sua postura de DMARC, SPF e DKIM, para que você detecte anomalias nos seus dados de autenticação no momento em que aparecem. Cadastre-se gratuitamente no Excello Mail e saiba exatamente o que seu domínio está dizendo ao mundo hoje.