Microsoft Threat Intelligence publicó el 30 de septiembre de 2026 el análisis más completo hasta ahora de los ataques contra CVE-2026-73570, la falla de Zimbra Collaboration Suite que permite tomar control del servidor de correo con un solo mensaje y sin contraseña. La conclusión que importa a cualquier empresa con Zimbra propio es incómoda: los atacantes empezaron antes de que la falla fuera pública, se quedaron dentro y se llevaron llaves que sobreviven al parche.
Zimbra sigue siendo común en México: lo usan PyMEs, despachos, escuelas y muchos proveedores de hospedaje que lo ofrecen como "correo empresarial" barato. Si tu correo corre en un servidor Zimbra —tuyo o de tu proveedor—, esta nota es para ti.
Qué se sabe
| Dato | Detalle |
|---|---|
| Vulnerabilidad | CVE-2026-73570 |
| Producto | Zimbra Collaboration Suite, versiones anteriores a 10.1.20 |
| Calificación | CVSS 8.9 |
| Tipo | Inyección de comandos del sistema operativo |
| Requisitos | Paquete opcional zimbra-snmp instalado y notificaciones SNMP activas |
| Cómo se dispara | Un correo (petición SMTP) preparado; sin usuario ni interacción |
| Parche | Zimbra 10.1.20, publicado el 20 de julio de 2026 |
| Explotación | Confirmada por CERT Polska (17 ago), en el catálogo KEV de la CISA desde el 21 ago |
La cronología que explica el problema
- 20 de julio: Zimbra publica la versión 10.1.20 con la corrección, sin mucho ruido.
- 28 de julio al 7 de agosto: Microsoft detecta dos herramientas de escaneo que ya sondean esa falla y comprueban que pueden ejecutar comandos.
- 13 de agosto: la vulnerabilidad se hace pública.
- 17 y 21 de agosto: CERT Polska alerta de explotación activa y la CISA la agrega a su catálogo de fallas explotadas.
- 22 de agosto: según recuentos de Shadowserver citados por medios especializados, ya había 274 servidores comprometidos detectados.
- 30 de septiembre: Microsoft detalla qué hicieron los atacantes una vez dentro.
Es decir: quien actualizó en agosto quizá llegó tarde. Por eso esta noticia sigue vigente aunque el parche tenga casi tres meses.
Qué hicieron los atacantes una vez dentro
De acuerdo con Microsoft y con la cobertura de The Register y The Hacker News:
- Instalaron web shells (pequeños programas JSP que permiten controlar el servidor desde el navegador) en varias carpetas de Zimbra y copias en otros nodos para no perder el acceso.
- Robaron las llaves internas
zimbraPreAuthKeyyzimbraAuthTokenKey, con las que se pueden fabricar sesiones válidas, y el secreto del segundo factor (zimbraTwoFactorAuthSecret). - Sacaron contraseñas de servicio de LDAP, MySQL y Postfix.
- Crearon persistencia: un servicio de sistema llamado
zimlog.service, tareas en cron y cambios en la configuración desudo. - Desplegaron un agente llamado zimclient2 para tener consola remota y túnel, y en algunos casos empaquetaron buzones y lanzaron su envío a almacenamiento en la nube de Azure; Microsoft no pudo confirmar si la transferencia se completó.
Microsoft dice que los ataques no se limitaron a un sector ni a una región.
Qué hacer esta semana
Si tienes Zimbra propio:
- Confirma la versión. Si es anterior a 10.1.20, actualiza ya. Si no puedes hoy, desinstala
zimbra-snmpo apaga las notificaciones SNMP, y limita el acceso a los puertos de administración. - Busca archivos
.jspque no reconozcas en las carpetas web de Zimbra (jetty_base/webapps,mailboxd/webappsywork/zimbra/jsp) en todos los servidores de buzones. - Revisa servicios y tareas programadas: cualquier unidad nueva en
/etc/systemd/system/—en especialzimlog.service—, entradas de cron y cambios en/etc/pam.d/sudo. - Rota las llaves y contraseñas de Zimbra: preAuthKey, authTokenKey, y las de LDAP, MySQL y Postfix. Cambiar solo las contraseñas de los usuarios no basta.
- Pide a tus usuarios que vuelvan a registrar el segundo factor si tu servidor estuvo vulnerable en julio o agosto.
- Si encuentras rastros, trátalo como incidente: aísla, conserva evidencia y avisa a tus clientes si hubo correo expuesto. El kit de ciberseguridad básico trae la plantilla de respuesta.
Si tu correo Zimbra te lo da un proveedor de hospedaje, pregúntale por escrito: ¿en qué versión está?, ¿tenía zimbra-snmp instalado?, ¿buscó web shells y rotó llaves después del informe de Microsoft? Si no sabe responder, empieza a evaluar alternativas.
La lección de fondo
Este caso repite un patrón que vimos en septiembre con tiendas WooCommerce con web shells y con FortiMail: el parche llega, pero el atacante ya estaba. Para un servidor expuesto a internet, "actualizado" no es lo mismo que "limpio".
El correo propio tiene sentido cuando alguien lo administra de verdad: actualizaciones a tiempo, endurecimiento del sistema Linux y revisión periódica de qué corre en el servidor. Si nadie en tu empresa puede hacer esa revisión hoy, octubre —mes de la ciberseguridad— es buen momento para decidir si lo sigues teniendo en casa o lo mueves a un servicio administrado.
