Zimbra CVE-2026-73570: fallo SNMP explotado antes del aviso

Una vulnerabilidad de Zimbra Collaboration Suite (ZCS), CVE-2026-73570, fue explotada antes de hacerse pública. Permite a un atacante no autenticado ejecutar comandos del sistema operativo enviando contenido manipulado al servicio SMTP del servidor de correo. Microsoft Threat Intelligence ha descrito las intrusiones que siguieron: web shells, escalada de privilegios, robo de credenciales y archivos de buzones preparados para sacarlos. La corrección existe desde la versión 10.1.20.

Qué ha pasado

Zimbra publicó la versión 10.1.20 el 20 de julio, pero la vulnerabilidad no se divulgó hasta el 13 de agosto. Mientras tanto, entre el 28 de julio y el 7 de agosto, Microsoft observó dos herramientas de escaneo distintas que sondeaban en Internet justo el componente que después se usó en los ataques.

Los atacantes comprobaron primero que el exploit funcionaba: hacían que los servidores vulnerables contactaran con una infraestructura bajo su control, mediante peticiones HTTP y DNS, pings ICMP y otras verificaciones fuera de banda. Así confirmaban la ejecución de comandos sin comprometer todavía el servidor. Después pasaron a instalar los payloads.

Según Microsoft, la actividad afectó a organizaciones de varias regiones y sectores, con una parte automatizada y otra realizada a mano en los servidores comprometidos. Los ataques no se han atribuido a ningún grupo concreto.

Shadowserver, según Ars Technica, contó 274 instancias de ZCS comprometidas. Los servidores Zimbra visibles en Internet eran unos 19.000 la semana siguiente al parche y unos 10.000 a finales de septiembre.

Detalles técnicos

• CVE: CVE-2026-73570, inyección de comandos sin autenticación. El CERTuy (Uruguay) indica una puntuación CVSS de 8.9, mientras que Ars Technica y The Register la califican de crítica.
• Versiones afectadas: Zimbra Collaboration Suite anteriores a 10.1.20.
• Condiciones necesarias: debe estar instalado el paquete opcional zimbra-snmp y activas las notificaciones SNMP. El CERTuy precisa: parámetro snmp_notify activo y servicio swatchdog en ejecución.
• Vector: red, por SMTP. El contenido de la petición llega al procesamiento de las notificaciones SNMP sin ser saneado, y los comandos shell inyectados se ejecutan con los privilegios de la cuenta de servicio zimbra.
• Privilegios iniciales: los del usuario zimbra, no root. Aun así bastan para leer la configuración, los datos y los buzones de la plataforma.

La cadena de ataque observada

Microsoft, en la reconstrucción recogida por The Register y Ars Technica, describe estas fases:

1. Reconocimiento y verificación: escaneos y callbacks fuera de banda para confirmar la ejecución de comandos.
2. Acceso y persistencia: web shells JSP, reverse shells, herramientas de acceso remoto persistente y ejecución en memoria. En algunos casos se cambiaron los permisos de las carpetas públicas para colocar las web shells y luego se restauraron, para que la intrusión fuera menos visible.
3. Escalada: en al menos una máquina los atacantes obtuvieron root y se dejaron configurada la posibilidad de ejecutar comandos con los máximos privilegios sin contraseña.
4. Movimiento lateral: buscaron otros servidores de correo y aprovecharon las relaciones de confianza SSH ya existentes entre sistemas Zimbra.
5. Recopilación: credenciales y secretos de autenticación de Zimbra. Una herramienta estaba hecha a propósito para extraer las credenciales de la cuenta de servicio y la información de los buzones de las bases de datos de Zimbra.
6. Exfiltración intentada: las copias de seguridad recientes de los buzones se comprimieron en un archivo y se enviaron hacia Azure Blob Storage con AzCopy. Microsoft no pudo confirmar si la transferencia tuvo éxito.

El CERTuy añade que, según los informes analizados, en algunos servidores comprometidos apareció también software de minería de criptomonedas. Advierte de que la investigación no debe detenerse en el minero, porque puede haber otros mecanismos de persistencia.

MITRE ATT&CK (nuestra correspondencia de los comportamientos descritos): T1595 Active Scanning, T1190 Exploit Public-Facing Application, T1059.004 Unix Shell, T1505.003 Web Shell, T1222.002 Linux File and Directory Permissions Modification, T1021.004 SSH, T1114.001 Local Email Collection, T1560 Archive Collected Data, T1567.002 Exfiltration to Cloud Storage, T1496 Resource Hijacking.

Impacto para las empresas europeas e italianas

El servidor de correo guarda comunicaciones, adjuntos y credenciales. Quien lo controla puede leer la correspondencia, robar identidades y preparar nuevos ataques desde dentro. La actualización cierra el fallo, pero no elimina web shells, claves SSH ni otras persistencias instaladas antes. Por eso hay que revisar cada servidor que siguió expuesto y vulnerable después del 28 de julio.

Para las entidades sujetas a NIS2, la intrusión en el correo puede ser un incidente significativo que hay que notificar al CSIRT nacional, que en Italia es el CSIRT Italia de la ACN. Si los buzones contienen datos personales, y casi siempre es así, también hay que valorar la notificación de la brecha a la autoridad de protección de datos según el RGPD. En sanidad, donde los correos pueden contener datos de salud, el acceso a los buzones y a sus copias pesa todavía más.

Qué hacer ya

1. Inventario: localiza todas las instalaciones de Zimbra, también las gestionadas por proveedores, y comprueba su versión.
2. Actualiza a Zimbra Collaboration 10.1.20 o posterior. Las versiones sin soporte deben migrarse a una rama soportada.
3. Si no puedes actualizar enseguida: desactiva las notificaciones SNMP (snmp_notify) o elimina el paquete zimbra-snmp si no los necesitas. Plantéate retirar de Internet los servidores que no puedas actualizar ni mitigar. Son medidas temporales.
4. Revisa la configuración: presencia de zimbra-snmp, valor de snmp_notify, estado de swatchdog y desde cuándo estaba expuesto el servidor en condiciones vulnerables.
5. Busca señales de explotación, como indica el CERTuy:
   • en /var/log/zimbra.log, líneas Service status change: … changed from stopped to running (o from running to stopped) con comandos, caracteres especiales o sustituciones de shell;
   • archivos creados o modificados por el usuario zimbra en /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, /tmp/, /var/tmp/ y /dev/shm/;
   • procesos del usuario zimbra con un consumo anómalo de CPU, uso de curl o wget, procesos lanzados desde carpetas temporales;
   • tareas programadas, servicios, scripts de arranque y claves SSH nuevos o modificados, incluidos los permisos de sudo;
   • conexiones salientes inusuales, hacia pools de minería o servicios de almacenamiento en la nube como Azure Blob;
   • accesos no reconocidos a buzones y cuentas de administración.
6. Si encuentras indicios: conserva los registros y las evidencias antes de borrar archivos o detener procesos, aísla el servidor y trátalo como un incidente. Rota las credenciales de la cuenta de servicio y de los usuarios, y revisa los servidores accesibles por SSH desde el comprometido. Que no haya líneas sospechosas en los registros no basta para descartar la explotación, sobre todo si se han rotado.

Cómo ayuda ARXDOME

ARX Expose muestra qué servicios expone tu empresa en Internet, qué productos se reconocen en ellos y cuáles tienen vulnerabilidades conocidas: un servidor Zimbra accesible y sin actualizar aparece entre los hallazgos. En los servidores Linux, el agente de ARX Sentry recoge registros, procesos, puertos y cambios en los archivos de las carpetas elegidas, como las de las aplicaciones web de Zimbra. ARX Shield enumera las vulnerabilidades abiertas por máquina y por paquete y permite aislar de la red una máquina sospechosa. Con ARX Trace, los analistas pueden lanzar recopilaciones y búsquedas en varios servidores.

Última actualización: 9 de octubre de 2026