Zimbra CVE-2026-73570: explotación no autenticada vía SMTP con zimbra-snmp expone web shells y datos

En las últimas semanas se registró una campaña que aprovechó un fallo de seguridad en Zimbra Collaboration Suite para ejecutar código sin autenticación, instalar web shells y, en varios casos, extraer datos de buzones de correo. La vulnerabilidad identificada como CVE‑2026‑73570 (CVSS 8.9) afecta a instalaciones con el paquete opcional zimbra‑snmp y con las notificaciones SNMP habilitadas; según análisis públicos, la explotación se realiza mediante una petición SMTP especialmente construida sin necesidad de credenciales ni interacción del usuario. Zimbra publicó un parche en julio de 2026 (versión 10.1.20) y organizaciones de seguridad —entre ellas Microsoft y CERT Polska— documentaron actividad activa antes y después de la corrección.

Técnicamente, lo que se reporta en los análisis es un OS command injection no autenticado en el camino que recibe o procesa notificaciones SNMP asociadas al servicio Zimbra. Un atacante que pueda enviar correo al servidor vulnerable puede provocar la ejecución de comandos con los privilegios de la cuenta del servicio Zimbra, lo que ha permitido desplegar JSP web shells sobre Jetty/mailboxd, descargar binarios mediante wget/curl, abrir reverse shells y establecer mecanismos de persistencia (cron, systemd, memfd_create, ssh keys, ficheros de arranque de shell, etc.). Microsoft describió una cadena de ataque completa que incluye descubrimiento del entorno (zmprov), escalada de privilegios modificando configuraciones PAM/sudo, recuperación de secretos mediante zmlocalconfig, movimiento lateral aprovechando la identidad SSH de Zimbra y exfiltración mediante herramientas como AzCopy hacia almacenamiento en la nube.

Hechos confirmados: CVE‑2026‑73570 existe y fue corregida en Zimbra 10.1.20; la explotación puede activarse vía SMTP sin autenticación cuando zimbra‑snmp y las notificaciones SNMP están activas; actores desplegaron JSP web shells, reverse shells y herramientas de acceso remoto (por ejemplo Zimclient2) y coleccionaron credenciales y datos de buzones en múltiples entornos según telemetría de Microsoft. CERT Polska y CISA emitieron advertencias públicas y CISA añadió la vulnerabilidad a su catálogo Known Exploited Vulnerabilities, con plazos de mitigación para agencias federales.

Información estimada o todavía incierta: la atribución de las intrusiones no está confirmada públicamente; tampoco lo está la extensión total del éxito de las exfiltraciones en todos los incidentes (en al menos un caso se observó un intento de transferencia a Azure Blob usando AzCopy, pero no se confirmó la finalización de la copia). Además, aunque Microsoft describió técnicas específicas observadas (modificación de /etc/pam.d/sudo, creación de zimlog.service, uso de rsync entre nodos, etc.), no todos los hosts afectados presentaron cada paso del flujo de ataque.

¿A quién afecta? Cualquier organización que tenga Zimbra expuesto al tráfico SMTP y con el paquete zimbra‑snmp instalado y las notificaciones SNMP habilitadas puede verse comprometida. En particular, despliegues con nodos de mailbox/MTA accesibles desde internet y configuraciones de clúster con identidad SSH compartida resultan más vulnerables a la exploración lateral y al robo de secretos de servicio.

Consecuencias reales que se han observado: instalación de puertas traseras persistentes, escalada de privilegios del servicio zimbra, robo de secretos (tokens, claves de preautenticación, secretos 2FA), extracción de tablas de la base de datos Zimbra y archivado de contenidos de buzones. Desde un punto de vista operativo, esto puede significar pérdida de confidencialidad de correos corporativos, comprometimiento de identidades del servicio y reutilización de credenciales para pivotar a otros sistemas dentro del mismo entorno de confianza.

Medidas concretas e inmediatas que debe tomar un administrador de Zimbra:

1) Parchear o mitigar: aplique Zimbra 10.1.20 o la versión que contenga el parche cuanto antes. Si no puede parchear inmediatamente, desinstale zimbra‑snmp o desactive las notificaciones SNMP y bloquee el acceso SNMP (puertos 161/162) y SMTP (25) desde fuentes no fiables mediante listas de control de acceso o firewalls. Más información sobre avisos y actualizaciones en la página de seguridad de Zimbra: https://www.zimbra.com/security/.

2) Verificar indicadores y persistencias: compruebe los registros y el sistema para las señales observadas por los investigadores. Busque reinicios inusuales del servicio en /var/log/zimbra.log, JSP web shells en rutas Webapps y /tmp, ficheros recientemente creados con permisos públicos temporalmente alterados, servicios systemd sospechosos (por ejemplo zimlog.service), entradas cron no esperadas, claves SSH en /opt/zimbra/.ssh/authorized_keys y modificaciones en /etc/pam.d/sudo. Comandos útiles (ejemplos):

grep -i 'zimbra' /var/log/zimbra.log
find /opt/zimbra -type f -iname '*.jsp' -mtime -30
stat /etc/pam.d/sudo

3) Rotación de secretos y contención: asuma compromiso de las claves de servicio y rote los secretos principales de Zimbra (zimbraPreAuthKey, zimbraAuthTokenKey, zimbraTwoFactorAuthSecret), cambie contraseñas de cuentas de servicio, invalide tokens y considere la rotación de certificados si hay indicios de exfiltración. Revocar y regenerar credenciales del servicio y restringir la identidad SSH de /opt/zimbra/.ssh/zimbra_identity son pasos críticos. Cualquier servidor con indicios de compromiso debe aislarse de la red y preservarse para análisis forense.

4) Buscar artefactos de exfiltración y transferencia de archivos: monitoree conexiones salientes que usen herramientas como AzCopy o patrones inusuales hacia servicios de almacenamiento en la nube. Revise la presencia de archivos archivados localmente (por ejemplo final.tar.gz mencionado en telemetría) y las llamadas a utilidades de red que podrían haber transferido datos. Si detecta intentos de subida a Azure Blob Storage, revisa logs y configura alertas para SAS URL y tráfico hacia dominios de blobs. CISA mantiene un catálogo de vulnerabilidades explotadas que puede ayudar a priorizar acciones: https://www.cisa.gov/known-exploited-vulnerabilities-catalog.

5) Recuperación recomendada: si confirma compromiso, planifique reconstrucción desde backups limpios tras una eliminación forense completa. No confíe en limpiar simplemente los binarios encontrados; los actores han demostrado múltiples mecanismos de persistencia y movimiento lateral que requieren reimagenación o restauración controlada. Documente y preserve evidencias para la investigación.

Finalmente, aunque esta campaña ha quedado documentada en detalle por múltiples equipos de respuesta, la visibilidad es parcial y podrían existir variantes o actores reutilizando la misma falla. Mantenga controles de detección para patrones de comandos anómalos en procesos de Zimbra, limite exposiciones innecesarias de servicios administrativos y actualice políticas de monitoreo para detectar cambios en PAM/sudo, servicios systemd y transferencia de grandes volúmenes de correos o bases de datos. Para contexto y avisos de seguridad adicionales, siga fuentes oficiales como el blog de seguridad de Microsoft: https://www.microsoft.com/security/blog/, y los equipos CERT locales para indicadores específicos.