¿Cómo funciona CVE-2026-73570?

Un atacante puede enviar una solicitud SMTP especialmente preparada que introduce datos no confiables en el procesamiento de las notificaciones SNMP. Si esos datos no son neutralizados correctamente, determinados elementos pueden interpretarse como comandos del sistema.

La ejecución inicial se produce con los privilegios de la cuenta de servicio de Zimbra. No requiere autenticación ni interacción de un usuario, pero sí depende de dos condiciones: que el paquete opcional zimbra-snmp esté instalado y que las notificaciones SNMP estén habilitadas.

Esta condición es importante. No todas las instalaciones de Zimbra son explotables de la misma manera, pero las organizaciones no deberían asumir que están protegidas sin verificar directamente sus paquetes, su configuración y la versión instalada.

De un correo malicioso al control del servidor

Según Microsoft, la explotación proporcionó ejecución directa de comandos como el usuario de servicio de Zimbra. A partir de ese acceso, los atacantes desplegaron web shells JSP en directorios públicos y establecieron reverse shells para operar los sistemas de manera interactiva.

También se observaron técnicas destinadas a obtener privilegios de administrador, modificar configuraciones, crear servicios persistentes, utilizar tareas programadas y mantener herramientas de acceso remoto capaces de transferir archivos y utilizar el servidor como punto de conexión hacia otros sistemas.

En algunos casos, los actores intentaron ocultar sus cambios, restauraron permisos después de instalar una puerta trasera y modificaron marcas de tiempo para que archivos maliciosos parecieran componentes antiguos y legítimos.

Correo, credenciales y datos bajo riesgo

Los servidores de correo concentran información sensible: conversaciones internas, adjuntos, credenciales, datos personales, restablecimientos de contraseña y comunicaciones con clientes y proveedores.

Microsoft observó acceso a correo electrónico, recopilación de datos de autenticación y preparación de archivos para su posible transferencia. Algunas de las acciones más importantes se realizaron con herramientas normales del sistema, sin depender de una familia de malware reconocible.

Esto significa que la ausencia de una detección antivirus no permite descartar el compromiso. El análisis debe considerar procesos, conexiones, cambios de permisos, servicios, tareas programadas, archivos JSP y actividad anómala sobre los buzones.

Una ventana de exposición antes de la divulgación pública

Zimbra publicó la versión 10.1.20 con la corrección el 20 de julio de 2026. Microsoft observó sondeos relacionados con la ruta vulnerable entre el 28 de julio y el 7 de agosto, antes de que CVE-2026-73570 fuera divulgada públicamente el 13 de agosto.

CISA incorporó la vulnerabilidad a su catálogo de vulnerabilidades explotadas el 21 de agosto. La investigación publicada por Microsoft el 30 de septiembre amplía ahora la comprensión sobre la profundidad de las intrusiones y las acciones posteriores al acceso inicial.

Las organizaciones deben revisar registros históricos y no limitar la búsqueda a los últimos días. La actividad temprana puede quedar fuera de las ventanas habituales de retención de las plataformas de detección.

Versiones y configuraciones afectadas

La vulnerabilidad afecta a Zimbra Collaboration Suite anterior a la versión 10.1.20 cuando se cumplen las condiciones relacionadas con SNMP.

• El paquete opcional zimbra-snmp está instalado.
• Las notificaciones SNMP están habilitadas.
• El servidor vulnerable puede recibir el contenido SMTP preparado por el atacante.

Zimbra corrigió la vulnerabilidad en 10.1.20 y posteriormente publicó la versión 10.1.21 con correcciones adicionales. Siempre que sea compatible con el entorno, la recomendación es instalar la versión soportada más reciente y no detenerse únicamente en la versión mínima que resolvió esta CVE.

Actualizar no elimina una intrusión anterior

Aplicar el parche evita nuevos intentos mediante CVE-2026-73570, pero no elimina web shells, servicios, cuentas, claves SSH, tareas programadas u otros mecanismos de persistencia que hayan sido instalados antes de la actualización.

Un servidor que estuvo expuesto con la configuración vulnerable debe considerarse potencialmente comprometido hasta completar una revisión. Si se confirma una reverse shell o ejecución no autorizada, la situación debe tratarse como un incidente activo.

Recomendaciones de XPoint

1. Identificar todas las instancias. Incluir servidores principales, nodos de buzones, MTA, sistemas de respaldo, laboratorios y ambientes de contingencia.
2. Actualizar de inmediato. Instalar Zimbra 10.1.20 o posterior; preferentemente la versión soportada más reciente después de validar compatibilidad.
3. Verificar la condición vulnerable. Confirmar si zimbra-snmp está instalado y si las notificaciones SNMP están habilitadas.
4. Aplicar mitigaciones temporales. Si la actualización debe esperar, desinstalar el paquete opcional o deshabilitar las notificaciones SNMP y restringir accesos según la operación del servicio.
5. Preservar evidencia. Conservar registros SMTP, del sistema, de Zimbra, proxy, autenticación, red y EDR antes de realizar cambios extensivos.
6. Buscar web shells y persistencia. Revisar archivos JSP inesperados, servicios systemd, cron, claves SSH, cuentas locales, scripts de inicio y modificaciones de permisos.
7. Revisar escalamiento de privilegios. Investigar cambios en PAM, sudoers, propietarios de archivos y uso anómalo de utilidades privilegiadas de Zimbra.
8. Rotar secretos. Cambiar claves de preautenticación, credenciales administrativas, contraseñas LDAP, tokens, claves SSH y otros secretos accesibles desde el servidor.
9. Analizar los buzones. Buscar accesos, exportaciones, archivos comprimidos, reglas de reenvío y actividad anómala sobre cuentas sensibles.
10. Extender la investigación histórica. Consultar archivos de registros y plataformas con mayor retención para cubrir la actividad previa a la divulgación pública.

Conclusión

CVE-2026-73570 combina tres condiciones especialmente peligrosas: un servidor expuesto, ejecución de comandos sin autenticación y un vector que puede activarse mediante correo electrónico sin interacción del usuario.

La actualización es urgente, pero la respuesta debe incluir investigación forense, búsqueda de persistencia, rotación de credenciales y revisión de los datos de correo. En un servidor vulnerable, instalar el parche es el comienzo de la respuesta, no su final.

How does CVE-2026-73570 work?

An attacker can send a specially crafted SMTP request that introduces untrusted data into SNMP notification processing. If the input is not correctly neutralized, parts of it can be interpreted as operating-system commands.

Initial execution occurs with the privileges of the Zimbra service account. Exploitation requires no authentication or user interaction, but it depends on the optional zimbra-snmp package being installed and SNMP notifications being enabled.

Not every Zimbra installation is exploitable through this path. Organizations should nevertheless verify their packages, configuration and installed version rather than assume they are protected.

From a crafted email to server control

Microsoft reports that exploitation provided direct command execution as the Zimbra service user. Attackers then deployed JSP web shells in public directories and established reverse shells for interactive control.

They also used techniques to obtain administrative privileges, modify configurations, create persistent services, schedule recurring execution and deploy remote-access tooling capable of transferring files and pivoting through the compromised server.

Some operators attempted to hide their changes by restoring permissions after installing a backdoor and modifying timestamps to make malicious files resemble older legitimate components.

Email, credentials and data at risk

Email servers contain internal conversations, attachments, credentials, personal data, password resets and communications with customers and suppliers.

Microsoft observed email access, authentication-data collection and archive creation followed by transfer activity. Some of the most consequential actions relied on normal operating-system utilities rather than a recognizable malware family.

The absence of an antivirus detection does not rule out compromise. Investigations should review processes, connections, permissions, services, scheduled tasks, JSP files and anomalous mailbox activity.

Exposure began before public disclosure

Zimbra released version 10.1.20 with the relevant fix on July 20, 2026. Microsoft observed probing of the vulnerable path between July 28 and August 7, before CVE-2026-73570 was publicly disclosed on August 13.

CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on August 21. Microsoft’s September 30 report now provides a deeper view of the intrusions and post-exploitation activity.

Organizations should search historical logs rather than focus only on recent events. Early activity may fall outside the standard retention period of detection platforms.

Affected versions and configurations

The vulnerability affects Zimbra Collaboration Suite versions before 10.1.20 when the SNMP-related conditions are present:

• The optional zimbra-snmp package is installed.
• SNMP notifications are enabled.
• The vulnerable server can receive the attacker’s crafted SMTP content.

Zimbra fixed the issue in 10.1.20 and later released version 10.1.21 with additional security improvements. Where compatible, organizations should install the newest supported release rather than stop at the minimum version that addressed this CVE.

Patching does not remove an earlier intrusion

Updating prevents new exploitation through CVE-2026-73570, but it does not remove web shells, services, accounts, SSH keys, scheduled tasks or other persistence created before remediation.

A server exposed with the vulnerable configuration should be treated as potentially compromised until it has been reviewed. A confirmed reverse shell or unauthorized command execution should be handled as an active incident.

XPoint recommendations

1. Identify every instance. Include primary servers, mailbox nodes, MTAs, backup systems, laboratories and disaster recovery environments.
2. Update immediately. Install Zimbra 10.1.20 or later, preferably the newest supported release after compatibility testing.
3. Verify the vulnerable condition. Confirm whether zimbra-snmp is installed and SNMP notifications are enabled.
4. Apply temporary mitigation. If patching must wait, uninstall the optional package or disable SNMP notifications and restrict access where operationally possible.
5. Preserve evidence. Retain SMTP, operating-system, Zimbra, proxy, authentication, network and EDR logs before extensive changes.
6. Hunt for web shells and persistence. Review unexpected JSP files, systemd services, cron jobs, SSH keys, local accounts, startup scripts and permission changes.
7. Investigate privilege escalation. Examine PAM, sudoers, ownership changes and unusual use of privileged Zimbra helpers.
8. Rotate secrets. Replace pre-authentication keys, administrative credentials, LDAP passwords, tokens, SSH keys and other secrets accessible from the host.
9. Review mailboxes. Search for unusual access, exports, archives, forwarding rules and activity affecting sensitive accounts.
10. Extend the historical search. Use archived logs and longer-retention platforms to cover activity before public disclosure.

Conclusion

CVE-2026-73570 combines three dangerous conditions: an internet-facing service, unauthenticated command execution and a vector that can be triggered through email without user interaction.

Patching is urgent, but the response must also include forensic investigation, persistence hunting, credential rotation and review of email data. On a vulnerable server, installing the update is the beginning of the response—not the end.