Si tu empresa aloja su propio servidor de correo —una decisión muy común en las PyMEs mexicanas y en muchas dependencias de gobierno para no pagar licencias por usuario—, la noticia de esta semana te toca directo. La Fundación Shadowserver reportó que al menos 274 servidores de Zimbra Collaboration Suite expuestos a Internet ya estaban comprometidos al 24 de agosto, según el conteo publicado por medios especializados. El detalle incómodo: el parche que cierra el hueco salió el 20 de julio.
No es un ataque sofisticado ni un día cero desconocido. Es un fallo publicado, corregido y anunciado, que alguien no aplicó a tiempo. Ese patrón —no la película de hackers— es el que se está llevando servidores de correo reales.
Qué falla y cómo entran
La vulnerabilidad se identifica como CVE-2026-73570 y tiene una severidad alta (CVSS 8.9). Es una inyección de comandos en el componente de monitoreo SNMP de Zimbra: por una validación deficiente de la entrada durante el procesamiento de notificaciones SNMP, un atacante sin autenticarse puede enviar peticiones SMTP especialmente construidas y terminar ejecutando comandos del sistema operativo con los privilegios del usuario zimbra.
Hay una buena noticia y una mala. La buena: no afecta a todas las instalaciones, solo a las que tienen instalado el paquete opcional zimbra-snmp con las notificaciones SNMP habilitadas. La mala: según los reportes, ese envío de notificaciones queda activo por omisión en cuanto el paquete está presente en el servidor. Es decir, quien lo instaló alguna vez para monitorear puede estar expuesto sin saberlo.
29 días entre el parche y la ola de ataques
La cronología explica el problema mejor que cualquier discurso. El fallo se dio a conocer el 26 de junio, con una mitigación temporal disponible. Zimbra publicó la corrección definitiva en la versión 10.1.20 el 20 de julio. El 18 de agosto, el CERT de Polonia advirtió que había explotación activa en el mundo real. Dos días después, Shadowserver ya contaba 155 servidores comprometidos, y el 21 de agosto la agencia estadounidense CISA sumó el fallo a su catálogo de vulnerabilidades explotadas conocidas, con un plazo de tres días para las agencias federales civiles. Al 24 de agosto la cuenta iba en 274.
Un mes exacto de ventaja para actualizar, desperdiciado. Y no es la primera vez con este producto: es la decimonovena vulnerabilidad de Zimbra que entra a ese catálogo, cuatro de ellas solo en 2026.
Por qué el correo propio es el peor lugar para descuidar un parche
De los más de 12,100 servidores Zimbra que Shadowserver ve accesibles desde Internet, los comprometidos representan cerca del 2.3%. Suena poco, hasta que piensas qué hay dentro de un servidor de correo: contraseñas, códigos de verificación, comunicaciones legales, información de nómina, facturas y toda la conversación con tus clientes. Además, ese servidor suele vivir en el borde de la red, procesa lo que le llegue de afuera y tiene relaciones de confianza con el directorio de usuarios y los recursos compartidos.
Traducido a tu operación: quien entra al correo no roba “unos mensajes”. Obtiene el material para suplantar a tu dirección general frente a un cliente, para redirigir un pago o para moverse al resto de tus sistemas.
Cómo revisar si ya entraron
Actualizar cierra la puerta hacia adelante, pero no dice si alguien ya pasó. El CERT polaco publicó indicadores concretos que tu proveedor de TI puede revisar hoy mismo:
- Reinicios inesperados del servicio de Zimbra en el registro
/var/log/zimbra.log. - Archivos creados por el usuario
zimbraen los últimos 30 días dentro de/opt/zimbra/jetty/webapps/,/opt/zimbra/jetty_base/webapps/y/tmp/. - Presencia de archivos JSP extraños en el directorio web: es la vía habitual para dejar una puerta trasera que sobrevive al parche.
- Accesos a buzones y consultas al directorio en horarios o desde direcciones que no correspondan a tu operación.
El plan de esta semana
- Confirma la versión de tu servidor. Si es anterior a 10.1.20, programa la actualización con carácter urgente, no para el próximo mantenimiento.
- Pregunta si el paquete
zimbra-snmpestá instalado. Si nadie usa ese monitoreo, desinstalarlo o deshabilitar las notificaciones reduce la superficie de ataque. - Guarda los registros antes de tocar el servidor. Si hubo intrusión, esa evidencia es lo único que te permite saber el alcance.
- Rota contraseñas de administración y de cuentas de servicio del correo, y revisa reglas de reenvío automático creadas sin autorización.
- Deja por escrito quién revisa los avisos de seguridad de tu correo y con qué frecuencia. Un responsable con nombre vale más que una política de veinte páginas.
Autoalojar el correo es una decisión legítima: control del dato y costo predecible. Pero el precio real no es el servidor, es la disciplina de parcheo. Este caso demuestra que el margen entre “ya hay parche” y “ya me entraron” puede ser de cuatro semanas. En EDISAS lo vemos seguido: la empresa que revisa versiones una vez al mes duerme tranquila; la que espera al incidente termina reconstruyendo su infraestructura. Si no sabes en qué versión está tu correo, ese es el pendiente de hoy.
Fuentes
- Hackers breached over 270 Zimbra servers in ongoing attacks — BleepingComputer
- CISA orders urgent patching of actively exploited Zimbra flaw — BleepingComputer
- Unpatched Zimbra servers are falling to CVE-2026-73570 attacks — Help Net Security
- Attackers Exploit Zimbra SNMP Flaw for Unauthenticated Remote Code Execution — The Hacker News
- Zimbra SNMP flaw actively exploited, 274 servers hit — BetaNews
- CISA exige parchear un fallo de Zimbra que ya se explota para ejecutar comandos sin autenticación — Hispasec, Una al día
- CVE-2026-73570 (detalle técnico) — Tenable
