CVE-2026-73570: como o SNMP do Zimbra virou injeção de comandos

O CVE-2026-73570 é uma falha de injeção de comandos sem autenticação no caminho opcional de notificações SNMP do Zimbra. Um e-mail especialmente elaborado podia influenciar um valor de status depois interpolado em um comando de shell; o Zimbra corrigiu a chamada na versão 10.1.20. Mais tarde, a Microsoft relatou ferramentas de varredura sondando o caminho vulnerável antes da divulgação pública.^{[1], [2], [5]}

Vetor CVSS

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L^{[5], [10]}

💡 Explicação em Linguagem Simples (ELI5)

Uma pessoa da triagem copia o rótulo de um envelope para uma ordem de serviço. O processo antigo entregava a ordem inteira a um interpretador de comandos, que podia confundir caracteres do rótulo com novas instruções. A correção passa uma lista de argumentos separados ao programa de notificação, mantendo o rótulo como dado.^{[8], [9], [3]}

Conceitos Centrais e Termos

swatchdog: Processo de monitoramento de logs usado nesse caminho do Zimbra para identificar mensagens de status e acionar notificações.^[1]
Trap SNMP: Notificação enviada por um sistema gerenciado a um receptor de monitoramento SNMP quando ocorre um evento.^[1]
Interpolação no shell: Construção de um comando textual que o shell interpreta. Caracteres em valores não confiáveis podem alterar o significado do comando.^{[8], [7]}
system em forma de lista: A forma de múltiplos argumentos de system em Perl inicia o programa diretamente e entrega cada argumento separadamente, sem pedir ao shell que interprete uma string de comando.^{[9], [3]}

Mapeamentos de frameworks

Referência CWE para a fraqueza descrita neste guia: CWE-78
CISA KEV — adicionado em 2026-08-21 — CVE-2026-73570

Análise de Causa Raiz

O código afetado fica em rpmconf/Conf/swatchrc, na função dosnmp. Uma regra do swatch captura o nome de um serviço em uma linha de status e o encaminha por donotify como SERVICE; dosnmp inseria esse valor em um comando entre crases contendo $snmptrap. Como as crases invocam um shell, o valor derivado do log podia ser interpretado como sintaxe de comando. As precondições documentadas são cumulativas: Zimbra Collaboration Suite anterior à 10.1.20, pacote opcional zimbra-snmp instalado e notificações SNMP habilitadas. A Microsoft relata que uma entrada SMTP especialmente elaborada podia alcançar o caminho de notificações. A empresa observou ferramentas de varredura sondando o ponto de injeção vulnerável de 28 de julho a 7 de agosto de 2026, após a correção de 20 de julho e antes da divulgação pública de 13 de agosto. A correção do Zimbra substitui a string de shell por system(...) em forma de lista, fornecendo executável e argumentos em valores separados; o shell deixa de participar da execução. Esta análise trata apenas do código de notificações SNMP e não significa que toda instalação Zimbra ou mensagem SMTP seja vulnerável.^{[1], [2], [3], [5], [7]}

Matriz de exposição e correção do CVE-2026-73570

Condições da implantação	O caminho documentado se aplica?	Ação defensiva
Zimbra Collaboration Suite anterior à 10.1.20; pacote opcional `zimbra-snmp` instalado; notificações SNMP habilitadas.	As três condições são necessárias para o caminho de notificação documentado. A Microsoft relata que uma entrada SMTP criada poderia influenciar o valor de status do serviço processado depois por `dosnmp`.	Atualize para a versão 10.1.20 ou posterior. Analise os logs relevantes e a telemetria de processos do período de exposição; trate indicadores como pistas de investigação, não como prova de comprometimento.
Pacote `zimbra-snmp` ausente ou notificações SNMP desabilitadas.	O caminho de notificação `dosnmp` descrito não fica ativo nessa configuração. Isso não demonstra que o servidor esteja livre de outras vulnerabilidades.	Mantenha o recurso desabilitado ou o pacote ausente até corrigir o servidor. Inventarie todos os nós de mailbox e confirme a configuração em cada um.
Zimbra Collaboration Suite 10.1.20 ou posterior, com o pacote corrigido pelo fornecedor instalado.	A construção de comando de shell documentada foi corrigida na versão 10.1.20. O número da versão sozinho não confirma todos os nós nem alterações locais.	Verifique a versão e o pacote instalados em cada nó e faça a triagem normal de incidentes para qualquer período anterior que atendesse às três condições de exposição.

Fluxo de Ataque Passo a Paso

Passo 1

Os recursos necessários estão presentes

O servidor usa uma versão anterior à 10.1.20, tem o pacote opcional zimbra-snmp instalado e mantém as notificações SNMP habilitadas.^[1]

Passo 2

A entrada de e-mail alcança o monitor de serviços

A Microsoft relata que uma solicitação SMTP especialmente elaborada podia influenciar um valor de status nos logs. Este artigo omite strings de exploração e instruções de rede.^[1]

Passo 3

swatchdog encaminha o valor à notificação

Uma regra captura o campo do serviço e o encaminha por donotify para dosnmp quando as notificações SNMP estão ativas.^[1]

Passo 4

O shell interpreta o valor como comando

Antes da correção, crases do Perl entregavam ao shell uma string que incluía o valor capturado. A execução ocorria no contexto da conta de serviço do Zimbra.^[1]

Passo 5

A versão 10.1.20 remove o shell

A correção chama snmptrap com system em forma de lista e argumentos separados. Atualize e investigue sistemas potencialmente expostos; corrigir não comprova que não houve atividade anterior.^[1]

Código-Fonte: Vulnerável vs. Seguro

As crases vulneráveis entregavam uma única string interpolada a um shell. A correção upstream usa system com vários argumentos e fornece o executável e cada argumento separadamente, impedindo que metacaracteres em SERVICE virem instruções de shell. O trecho mostra a chamada alterada; não é um exploit executável nem uma cópia completa do arquivo.^{[3], [4], [8], [9]}

Trecho de origem: rpmconf/Conf/swatchrc: dosnmp

IMPLEMENTAÇÃO VULNERÁVEL

# Trecho condensado da função dosnmp afetada; sem entrada de exploração.
sub dosnmp {
    my %args = (@_);
    `$snmptrap $snmpsvctrap $snmpsvcname s $args{SERVICE} $snmpsvcstatus i $statuses{$args{STATUS}}`;
}

PATCH SEGURO E ROBUSTO

# Correção do Zimbra 10.1.20: execute o programa com argumentos separados.
sub dosnmp {
    my %args = (@_);
    system(
        "/opt/zimbra/common/bin/snmptrap",
        "-v", "2c", "-c", "zimbra", $traphost, "",
        $snmpsvctrap, $snmpsvcname, "s", $args{SERVICE},
        $snmpsvcstatus, "i", $statuses{$args{STATUS}}
    );
}

Lista de Verificação de Segurança para Engenharia

✓Atualize todas as instalações Zimbra Collaboration Suite anteriores à 10.1.20 para a versão 10.1.20 ou posterior e confira os pacotes em todos os nós de mailbox.^{[2], [1]}
✓Verifique se zimbra-snmp está instalado e se as notificações SNMP estão habilitadas. Se não puder corrigir imediatamente, remova o pacote opcional ou desative as notificações, conforme aplicável, e restrinja SMTP e SNMP a sistemas confiáveis.^[1]
✓Considere expostas as instâncias sem correção acessíveis pela internet que atendam às duas precondições. Revise logs e telemetria de endpoint em busca de valores de status inesperados e processos filhos incomuns de Perl ou swatchdog.^{[1], [6]}
✓Se houve exposição antes da atualização, preserve logs, delimite os nós afetados, verifique persistência e atividade de contas e rotacione segredos quando as evidências ou a exposição justificarem.^{[1], [6]}
✓Em revisões de código, proíba execução de strings de shell com valores derivados de logs, e-mails ou outras entradas externas. Prefira APIs que recebam vetor de argumentos; valide estritamente qualquer interface que ainda dependa de shell.^{[8], [9], [7], [3]}
✓Adicione um teste de regressão para comprovar que o valor do serviço é passado como um argumento literal e não inicia um shell; use strings benignas com metacaracteres em um ambiente de teste isolado.^{[3], [9]}