CVE-2020-7796

SSRF (CWE-918) no Zimbra Collaboration Suite (ZCS) anterior a 8.8.15 Patch 7, condicionado à instalação do zimlet WebEx com o recurso zimlet JSP habilitado. O CVSS 9.8 (AV:N/PR:N/UI:N) sugere um servidor exposto na rede sem nenhuma barreira, mas a falha só existe nessa combinação específica de componente opcional instalado e configuração habilitada — não é uma condição padrão em toda instalação Zimbra. Está no catálogo KEV da CISA, ou seja, há confirmação de exploração em ambiente real.

A vulnerabilidade é uma Server-Side Request Forgery: o servidor Zimbra, ao processar requisições relacionadas ao zimlet JSP do WebEx, pode ser induzido a fazer requisições HTTP para destinos controlados pelo atacante em nome do próprio servidor. O advisory do fornecedor não detalha o parâmetro exato nem o endpoint vulnerável — apenas confirma a existência do bug e associa a correção ao pacote de patch 8.8.15p7.

O pré-requisito estrutural é duplo: o zimlet WebEx precisa estar instalado (não vem habilitado por padrão em toda instalação ZCS) e o recurso de zimlet JSP precisa estar ativo. Sem essas duas condições simultâneas, o vetor não existe. Isso reduz drasticamente a superfície real de exposição comparado ao que o CVSS 9.8 sozinho indicaria — a nota de CWE-918 no catálogo KEV reforça a classificação como SSRF clássico, onde o atacante controla (total ou parcialmente) a URL ou host de destino da requisição que o servidor executa.

Não há, nas fontes disponíveis, detalhamento técnico público sobre o código-fonte do zimlet, o parâmetro manipulado ou se a exploração exige autenticação prévia no ZCS. O CVSS publicado indica PR:N (sem privilégio) e UI:N (sem interação do usuário), o que aponta para um vetor acessível sem autenticação, mas essa é a única informação de pré-condição de acesso confirmada pelo vetor CVSS — não há confirmação textual adicional nas fontes lidas.

Na prática, a exploração de SSRF nesse cenário tipicamente permite ao atacante forçar o servidor Zimbra a fazer requisições para endereços internos da rede (metadados de nuvem, serviços administrativos internos, portas não expostas externamente) ou para serviços externos, usando o servidor como proxy. O impacto declarado em C:H/I:H/A:H no vetor CVSS sugere que a falha, quando explorada, pode ir além de simples SSRF de leitura — mas o mecanismo exato que leva a esse nível de impacto (execução de código, escrita de arquivo, etc.) não está detalhado nas fontes oficiais disponíveis.

O pré-requisito de configuração (zimlet WebEx instalado + JSP habilitado) é o filtro real de quem está exposto: instalações Zimbra que nunca integraram WebEx, ou que o fazem sem habilitar zimlet JSP, não apresentam esse vetor específico. Isso não diminui a gravidade para quem tem a combinação ativa, mas explica por que a exploração em massa reportada no KEV não implica que toda instância ZCS antiga de 8.8.15p7 esteja exposta.

A presença no catálogo KEV da CISA confirma exploração ativa documentada, e a existência de template Nuclei indica que a detecção/varredura automatizada da falha está amplamente disponível para scanners de vulnerabilidade — o que também facilita o reconhecimento por atacantes automatizados que testam a presença do zimlet e do endpoint vulnerável em varreduras massivas contra instâncias Zimbra expostas à internet.

A correção oficial é atualizar para Zimbra Collaboration Suite 8.8.15 Patch 7 ou posterior, aplicada via os pacotes zimbra-patch listados no advisory oficial (patches são cumulativos; o fornecedor recomenda backup completo antes de aplicar, pois não há rollback automatizado). Não há indicação nas fontes de backport para ramos anteriores ao 8.8.15 — se sua instalação estiver em uma major/branch mais antiga, o problema deve ser tratado como não corrigível sem migração para 8.8.15 primeiro.

Se a atualização imediata não for viável, o controle compensatório coerente com a mecânica da falha é desabilitar o zimlet WebEx ou desativar o recurso zimlet JSP — eliminando a pré-condição que torna o SSRF explorável, sem exigir patch. Isso tem custo funcional: perda da integração WebEx via zimlet até a atualização ser aplicada. A CISA, no registro KEV, orienta aplicar as mitigações do fornecedor, seguir a diretriz BOD 22-01 para serviços em nuvem, ou descontinuar o uso do produto caso mitigação não esteja disponível — o que reforça que a atualização de versão é o caminho preferencial, não um paliativo de rede.

Não há nas fontes qualquer indicação de que WAF genérico ou filtragem de rede padrão mitigue esse SSRF de forma confiável — como o vetor é uma requisição feita pelo próprio servidor a partir de um componente interno (zimlet), controles de borda que inspecionam apenas tráfego de entrada não cobrem o problema.

As fontes disponíveis não trazem uma assinatura de log ou padrão de tráfego oficialmente documentado para essa falha específica. De forma geral, para SSRF via zimlet JSP, vale monitorar logs do mailboxd/servidor de aplicação Zimbra por requisições HTTP de saída anômalas originadas do processo do servidor (para hosts internos, endpoints de metadados de nuvem ou IPs externos incomuns) coincidindo com acessos a endpoints relacionados ao zimlet WebEx. A existência de template Nuclei público para essa CVE indica que existe uma assinatura de teste conhecida pela comunidade de segurança, mas seu conteúdo não foi fornecido nas fontes lidas — recomenda-se tratar sua ausência de assinatura confirmada aqui como lacuna de detecção, não como ausência de risco.