CVE-2026-73570: se explota una inyección de comandos de Zimbra a través de SNMP: actualización a 10.1.20 y comprobación de compromiso

En Zimbra Collaboration (ZCS) anterior a la versión 10.1.20, un atacante sin autenticarse puede ejecutar comandos del sistema operativo con los permisos del usuario zimbra si está instalado el paquete opcional zimbra-snmp y las notificaciones SNMP están activadas. El desencadenante es una solicitud SMTP manipulada, es decir, un correo electrónico al servidor cuyo contenido llega sin filtrar al procesamiento de las notificaciones SNMP. La vulnerabilidad tiene el identificador CVE-2026-73570 y una puntuación CVSS de 8.9. Zimbra la comunicó el 26 de junio de 2026 y la corrigió el 20 de julio de 2026 con la versión 10.1.20. CERT Polska advirtió el 17 de agosto de 2026 sobre una campaña de ataques en curso; la agencia estadounidense CISA añadió la vulnerabilidad a su catálogo de vulnerabilidades explotadas conocidas (KEV) el 21 de agosto de 2026. La actualización está disponible.

Lo más importante en resumen

Versiones afectadas y actualizaciones

Solo están afectadas las instalaciones donde está instalado zimbra-snmp y están activadas las notificaciones SNMP. Según CERT Polska, el servicio swatchdog, que procesa las notificaciones, se ejecuta de forma predeterminada. Sin zimbra-snmp, según la descripción del aviso un servidor no es atacable por esta vía; la actualización a 10.1.20 también corrige otras vulnerabilidades (XSS en el Classic Web Client, elusión de restricciones de reenvío, SSRF en la integración de Nextcloud, controles de acceso en EWS y en la delegación de buzones) y por ello es recomendable incluso sin SNMP.

La versión instalada se muestra con zmcontrol -v como usuario zimbra (número de versión, compilación, plataforma y fecha de compilación según la wiki de Zimbra):

su - zimbra
zmcontrol -v

Según el análisis de SecureLayer7, la configuración vulnerable activa puede comprobarse así:

su - zimbra
zmlocalconfig snmp_notify
zmswatchctl status
grep dosnmp /opt/zimbra/conf/swatchrc

Si snmp_notify está en true y swatchdog está activo, el servidor es atacable en una versión anterior a 10.1.20.

Lo que se sabe sobre la explotación

Microsoft describe el proceso de la siguiente manera: swatchdog supervisa /var/log/zimbra.log y genera un trap SNMP cuando cambia el estado de los servicios. Mediante una solicitud SMTP manipulada, metacaracteres de shell llegan a este procesamiento; al cambiar el estado, swatchdog incorpora el valor controlado por el atacante a una llamada de snmptrap, que se ejecuta a través de una shell. Los comandos se ejecutan con los permisos de la cuenta de servicio zimbra.

Cronología según las fuentes:

1. 26 de junio de 2026: Zimbra comunica la vulnerabilidad en un aviso de seguridad con una medida temporal.

2. 20 de julio de 2026: se publica ZCS 10.1.20 con la corrección permanente.

3. Del 28 de julio al 7 de agosto de 2026: Microsoft observa sondeos del punto de inyección con dos herramientas diferentes.

4. 13 de agosto de 2026: se publica la entrada CVE.

5. 17 de agosto de 2026: CERT Polska advierte de una campaña en curso y publica indicaciones de comprobación.

6. 21 de agosto de 2026: CISA añade la vulnerabilidad al catálogo KEV, con plazo hasta el 24 de agosto de 2026.

7. 30 de septiembre de 2026: Microsoft publica un análisis de los ataques con indicadores.

Según Help Net Security, la Shadowserver Foundation contabilizó el 20 de agosto de 2026 155 instancias de Zimbra comprometidas en Internet y 274 pocos días después. En ese momento, más de 8200 instancias no estaban actualizadas, aunque no todas disponen de la configuración SNMP vulnerable.

Tras la explotación, según Microsoft, los atacantes dejaron webshells JSP en varios directorios de Jetty y mailboxd, establecieron persistencia mediante un servicio systemd, entradas de Cron y claves SSH, y obtuvieron privilegios de root manipulando la configuración PAM. Extrajeron credenciales con zmlocalconfig -s, consultaron mediante LDAP los atributos zimbraPreAuthKey, zimbraAuthTokenKey y zimbraTwoFactorAuthSecret, archivaron el almacén de correo con tar e intentaron exfiltrarlo mediante AzCopy a Azure Blob Storage; según Microsoft, no se ha confirmado que la transferencia se completara. Microsoft también menciona un minero de criptomonedas. Se desconoce quién está detrás de los ataques.

Medidas inmediatas

1. Determinar la versión y la configuración con zmcontrol -v, zmlocalconfig snmp_notify y zmswatchctl status (véase arriba).

2. Comprobar si existe compromiso y proteger los registros antes de realizar cambios, para que siga siendo posible analizarlos (véase la sección siguiente).

3. Actualizar a ZCS 10.1.20 o posterior. Zimbra, CERT Polska, CISA y Microsoft lo recomiendan de forma unánime. Las instalaciones en ramas anteriores deben migrar a 10.1.20 o posterior.

4. Aplicar la solución temporal hasta la actualización: Microsoft recomienda desinstalar el paquete zimbra-snmp o desactivar las notificaciones SNMP. Los comandos correspondientes figuran debajo de esta lista.

5. Reducir la exposición: según Microsoft, restringir SNMP y SMTP a hosts de confianza en la medida en que lo permita el funcionamiento del correo. En un MTA que recibe correo de Internet, SMTP sigue siendo accesible; en ese caso, la actualización o la solución temporal son las medidas eficaces.

Para desactivar las notificaciones SNMP, SecureLayer7 indica los siguientes comandos como usuario zimbra:

zmlocalconfig -e snmp_notify=false
zmswatchctl stop

Después faltarán los traps SNMP en caso de caída de servicios; la supervisión deberá realizarse por otra vía hasta la actualización.

Comprobación de compromiso

La vulnerabilidad fue explotada antes de que se actualizaran muchos sistemas. Una actualización a 10.1.20 cierra la vía de ataque, pero no elimina webshells, servicios systemd o claves SSH ya instalados. Microsoft recomienda expresamente buscar persistencia redundante y cambiar las claves de autenticación de Zimbra.

Registros y directorios según CERT Polska

CERT Polska indica dos comprobaciones:

1. /var/log/zimbra.log para encontrar entradas con la forma Service status change: [Payload] changed from stopped to running o changed from running to stopped, en las que aparezcan cadenas sospechosas en lugar del nombre del servicio.

2. Archivos creados por el usuario zimbra durante los últimos 30 días, en /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ y /tmp/. Hive Security indica para ello:

find /opt/zimbra/jetty/webapps /opt/zimbra/jetty_base/webapps /tmp -user zimbra -mtime -30 -ls

Dado que, según Microsoft, los ataques comenzaron ya a finales de julio, puede tener sentido revisar un periodo superior a 30 días.

Más rastros según Microsoft

Indicadores de red

Las direcciones se han escrito ofuscadas como en el análisis de Microsoft.

Hashes de archivos (SHA-256)

En caso de detección

Una detección significa que el sistema se considera comprometido. Proteja los registros y los archivos afectados antes de eliminar nada. Puesto que, según Microsoft, los atacantes obtuvieron privilegios de root y establecieron persistencia en varios puntos, una reconstrucción con 10.1.20 o posterior es más segura que eliminar archivos individuales. Después deben cambiarse los secretos extraídos: los valores de zmlocalconfig -s (entre otros, contraseñas LDAP y de bases de datos), zimbraPreAuthKey, zimbraAuthTokenKey y las claves SSH del usuario zimbra. Según Microsoft, también se consultó zimbraTwoFactorAuthSecret; por ello, deberían volver a configurarse los registros de autenticación de dos factores de los usuarios. En instalaciones multiservidor, la comprobación se aplica a todos los nodos, ya que, según Microsoft, los atacantes identificaron servidores de buzones y MTA con zmprov y utilizaron la clave SSH para desplazarse entre los servidores.

Contexto

Están afectadas las organizaciones que operan Zimbra como servidor de correo propio y aceptan correo directamente desde Internet. La vulnerabilidad es accesible mediante la recepción habitual de correo, sin autenticación y sin intervención de un usuario. La limitación a zimbra-snmp con notificaciones activas reduce el número de sistemas atacables; pero quienes hayan configurado supervisión SNMP se encuentran precisamente en esta configuración. Según SecurityWeek, CISA incluye 18 vulnerabilidades de Zimbra en el catálogo KEV, cuatro de ellas de 2026; campañas anteriores contra Zimbra se atribuyeron a grupos respaldados por Estados y a delincuentes con motivación financiera. CERT-FR comunicó la vulnerabilidad el 19 de agosto de 2026 junto con otras tres CVE corregidas en Zimbra. Durante la investigación no se encontró ningún aviso del NCSC Suiza sobre CVE-2026-73570.