O CERT Polska confirmou em 17 de agosto de 2026 que a vulnerabilidade CVE-2026-73570 está sendo explorada ativamente contra servidores do Zimbra Collaboration Suite, transformando uma falha corrigida semanas antes em uma emergência para administradores de sistemas. O problema permite execução remota de código sem autenticação, ou seja, um invasor pode fazer o servidor executar comandos sem apresentar uma senha válida, desde que a instalação reúna determinadas condições relacionadas ao SNMP. Neste artigo, você vai entender como o ataque funciona, quais versões exigem atenção e onde procurar sinais de comprometimento antes que uma brecha no serviço de e-mail se transforme em acesso persistente às caixas hospedadas.
O que a CVE-2026-73570 abre para os invasores
Para entender o tamanho do bug, é preciso traduzir o jargão usado nos alertas. A CVE-2026-73570 é descrita como uma falha crítica de injeção de comando, uma técnica que permite inserir instruções próprias em um fluxo que deveria aceitar apenas dados válidos, e recebeu pontuação CVSS 8.9 em uma escala usada para medir a gravidade de vulnerabilidades. O problema nasce de uma sanitização inadequada das entradas durante o processamento de notificações SNMP. Sanitizar uma entrada significa conferir e limitar o conteúdo recebido antes de encaminhá-lo para outro componente; quando essa barreira falha, uma mensagem especialmente preparada pode deixar de ser apenas uma mensagem e passar a funcionar como instrução para o sistema, conectando diretamente o alerta técnico ao risco operacional.
O mecanismo descrito nas análises permite que atacantes não autenticados enviem solicitações SMTP especialmente criadas e executem comandos com os privilégios do usuário zimbra. SMTP é o protocolo usado para transportar mensagens de e-mail, portanto a porta de entrada está ligada a um fluxo que o servidor já precisa processar para cumprir sua função. A falha afeta instâncias nas quais o pacote opcional zimbra-snmp está instalado e as notificações SNMP estão habilitadas, enquanto o serviço swatchdog, responsável por acompanhar determinados eventos e mudanças no sistema, está em execução como configuração padrão. O alerta também aponta que versões anteriores à 10.1.20 são afetadas, fazendo da identificação desses componentes o primeiro filtro para saber se uma instalação precisa de ação imediata.
O intervalo entre a correção e o ataque
A cronologia ajuda a explicar por que a atualização não pode ficar para a próxima janela de manutenção. A correção da falha foi liberada na versão 10.1.20 em 20 de julho de 2026, mas o CERT Polska só confirmou a exploração ativa em 17 de agosto, uma diferença de 28 dias entre a disponibilização do patch e a confirmação pública dos ataques. Patch é o pacote de atualização que altera o software vulnerável para impedir o comportamento explorado; neste caso, a versão indicada é o ponto de referência para a checagem dos administradores. O comunicado do CERT Polska concentra as orientações de detecção e confirma que a ameaça já saiu do campo teórico, o que muda a pergunta de “quando atualizar?” para “como verificar agora?”.
Esse intervalo também mostra como uma correção disponível não protege automaticamente todos os servidores. Pesquisadores rastreiam mais de 12.000 servidores Zimbra expostos à internet, número que dá uma dimensão da quantidade de instalações que precisam ser identificadas e comparadas com a versão corrigida. A exposição pública, por si só, não prova que cada servidor esteja vulnerável, porque o ataque depende da presença do pacote e das configurações SNMP descritas no alerta, mas ela torna a descoberta da versão e dos serviços ativos uma tarefa prioritária. Em termos práticos, o administrador não deve olhar apenas para a existência do Zimbra na rede: precisa conferir se a máquina está acessível pela internet e se os componentes que acionam a falha continuam habilitados, preparando a investigação dos possíveis efeitos do ataque.
O que pode acontecer depois da execução do comando
O impacto descrito nas fontes vai além de uma interrupção pontual do serviço de e-mail. Como os comandos podem ser executados com os privilégios do usuário zimbra, a exploração pode permitir que o invasor conquiste controle total do servidor, de acordo com a análise sobre a falha. A partir desse acesso, o risco inclui a exposição de todas as caixas de correio hospedadas na máquina e o comprometimento de credenciais, enquanto a criação de web shells nos diretórios do Jetty aparece como um meio de persistência. Web shell é um arquivo colocado em um diretório acessível pelo serviço web para que o atacante consiga retornar ao sistema por meio de requisições posteriores, funcionando como uma porta escondida que pode permanecer disponível mesmo depois da entrada inicial, razão pela qual apenas instalar o patch não encerra a investigação.
A investigação precisa combinar arquivos recentes e registros de atividade, porque os alertas apontam mais de um lugar onde podem aparecer indícios. A recomendação técnica é verificar arquivos criados nos últimos 30 dias em /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ e /tmp/, diretórios que podem revelar a presença de componentes usados para persistência ou execução. O CERT Polska também orienta examinar o arquivo /var/log/zimbra.log em busca de mudanças de status de serviço associadas a payloads maliciosos, isto é, conteúdos preparados para disparar o comportamento explorado. A análise técnica publicada pelo The Hacker News reforça a verificação dos diretórios, enquanto o comunicado oficial acrescenta os logs, formando uma trilha de apuração mais completa do que procurar apenas uma falha visível na interface do Zimbra.
O roteiro de resposta para administradores
Por isso, o primeiro passo é comparar a instalação com a versão corrigida e aplicar imediatamente a atualização para a versão 10.1.20 ou posterior, conforme a orientação consolidada nas fontes. Se a atualização imediata não for viável, a recomendação operacional é desabilitar as notificações SNMP como medida temporária, reduzindo a condição necessária para o ataque descrito. Essa ação deve ser acompanhada pela confirmação de que o pacote zimbra-snmp, o parâmetro snmp_notify e o serviço swatchdog estão realmente no estado esperado, porque a falha não é apresentada como um problema indistinto de qualquer instalação do Zimbra. A sequência transforma o alerta em uma tarefa verificável: identificar a versão, conferir os componentes, aplicar a correção e, quando houver impedimento, conter temporariamente o vetor relacionado ao SNMP.
Depois da atualização ou da contenção provisória, a etapa seguinte é procurar sinais de que o servidor já tenha sido atingido, sem presumir que a ausência de uma alteração visível encerre o caso. A checagem deve cobrir os três diretórios indicados para arquivos recentes e o /var/log/zimbra.log, com atenção às mudanças de status de serviço associadas a payloads maliciosos; a janela recomendada nas orientações técnicas é de 30 dias. Se a instalação ainda estiver em versão anterior à 10.1.20 e mantiver o conjunto de condições descrito, ela continua alinhada ao perfil afetado pelo alerta. O próximo passo concreto, portanto, não é esperar uma nova confirmação pública: é registrar a versão instalada, revisar o SNMP, atualizar o Zimbra e documentar o resultado da busca por web shells e atividades suspeitas no próprio servidor.