---
title: "Sicosixa Zimbra invadido pela CVE-2026-73570 em ataque simultâneo"
author: "André Iglesias"
date: "2026-08-21 10:00:00-03"
category: "Segurança & Privacidade"
url: "http://desbugados.scale.press/portal/desbugados/post/2026/08/21/sicosixa-zimbra-invadido-pela-cve-2026-73570-em-ataque-simultaneo/md"
---

## Resumo
- O CERT Polska confirmou exploração ativa da CVE-2026-73570 contra o Zimbra Collaboration Suite em 17 de agosto de 2026.
- A falha tem pontuação CVSS 8.9 e permite execução remota de código sem autenticação.
- O ataque depende da presença do pacote zimbra-snmp, das notificações SNMP habilitadas e do swatchdog em execução.
- Solicitações SMTP especialmente criadas podem executar comandos com os privilégios do usuário zimbra.
- A correção está disponível na versão 10.1.20, liberada em 20 de julho de 2026.
- Administradores devem procurar arquivos recentes nos diretórios do Jetty e em /tmp, além de revisar o /var/log/zimbra.log.
- Se a atualização imediata não for possível, desabilitar as notificações SNMP é a medida temporária recomendada.

---

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](https://moje.cert.pl/komunikaty/2026/145/aktywnie-wykorzystywana-podatnosc-w-zimbra-collaboration-suite/) 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](https://thehackernews.com/2026/08/attackers-exploit-zimbra-snmp-flaw-for.html) 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.