Durante años, miles de empresas han confiado en Zimbra para administrar su correo corporativo. Es una plataforma conocida, madura y ampliamente utilizada por organizaciones que prefieren mantener mayor control sobre su infraestructura de correo. Pero un incidente reciente vuelve a poner sobre la mesa una realidad incómoda: tener un servidor funcionando no significa necesariamente tener un servidor seguro.
Al menos 274 servidores Zimbra expuestos a Internet fueron comprometidos aprovechando la vulnerabilidad CVE-2026-73570, una falla que permite, bajo determinadas configuraciones, ejecutar comandos de manera remota mediante solicitudes SMTP especialmente manipuladas. El problema afecta a instalaciones que utilizan el componente zimbra-snmp con determinadas notificaciones habilitadas y fue corregido por Zimbra con la publicación de la versión 10.1.20, el 20 de Julio pasado..
Cuando comenzó a conocerse el alcance del problema se estimaba que existían más de 8,200 instalaciones que todavía no habían aplicado la actualización, aunque esto no significa que todas fueran directamente vulnerables. El dato, sin embargo, resulta revelador por otro motivo: entre la publicación de una actualización de seguridad y su instalación efectiva puede existir una ventana considerable. Y para un atacante, esa ventana es una oportunidad.
El problema de Zimbra no es necesariamente Zimbra
Cada vez que aparece una vulnerabilidad crítica en una plataforma conocida ocurre algo bastante predecible. Se publican titulares sobre el producto afectado, los usuarios comienzan a preguntarse si deberían migrar y rápidamente surge la percepción de que la tecnología en cuestión dejó de ser segura.
Pero esa conclusión suele ser demasiado sencilla.
Zimbra publica actualizaciones de seguridad, al igual que Microsoft, VMware, Fortinet, Cisco, Linux y prácticamente cualquier plataforma empresarial relevante. La aparición de vulnerabilidades forma parte de la realidad del software moderno. Lo que diferencia a una infraestructura razonablemente protegida de otra peligrosamente expuesta es lo que ocurre después de descubrirse esas vulnerabilidades.
¿Quién recibe la alerta? ¿Quién determina si el servidor está afectado? ¿Quién instala el parche? ¿Quién verifica que la actualización no haya afectado el servicio? ¿Y quién revisa si alguien aprovechó la vulnerabilidad antes de que fuera corregida?
Ahí comienza el verdadero problema.
Hay servidores que llevan años funcionando. Ese puede ser precisamente el riesgo
En muchas empresas de Perú y México todavía existen servidores de correo instalados hace cinco, ocho o incluso diez años que continúan cumpliendo perfectamente su función. Los usuarios envían mensajes, reciben correos y consultan sus buzones todos los días. Desde la perspectiva de la organización, no existe ningún problema evidente.
Precisamente por eso dejan de recibir atención.
El servidor pasa a formar parte de esa infraestructura que nadie toca porque “está funcionando”. El proveedor que lo instaló puede haber cambiado, el administrador original puede haber dejado la empresa y las actualizaciones pueden haberse convertido en una tarea ocasional. Mientras los correos continúen llegando, nadie tiene demasiados incentivos para hacer preguntas.
Hasta que aparece una vulnerabilidad como CVE-2026-73570.
Entonces la pregunta deja de ser si Zimbra funciona correctamente y pasa a ser otra mucho más importante: ¿quién está cuidando ese servidor?
Un servidor puede estar funcionando perfectamente y estar comprometido
Este probablemente sea uno de los conceptos más difíciles de trasladar fuera del departamento de tecnología. Existe una tendencia natural a asociar un incidente informático con una interrupción visible: una pantalla bloqueada, un servidor caído, archivos cifrados o usuarios incapaces de ingresar al correo.
Los ataques modernos no necesariamente funcionan así.
Para un atacante puede resultar mucho más valioso mantener acceso silencioso a una infraestructura que destruirla. Un servidor comprometido puede continuar entregando correo con absoluta normalidad mientras es utilizado para obtener información, explorar otros sistemas, capturar credenciales o preparar ataques posteriores.
Por eso el indicador “el correo funciona” dice muy poco sobre el verdadero estado de seguridad de una plataforma.
La discusión no debería ser Zimbra contra Microsoft 365 o Google Workspace
Después de incidentes como este también aparece otra reacción habitual: asumir que trasladar el correo a una gran plataforma elimina el problema.
La nube cambia buena parte de las responsabilidades operativas y puede reducir determinados riesgos, pero no elimina la necesidad de gestionar la seguridad. Credenciales comprometidas, phishing, configuraciones incorrectas, cuentas sin autenticación multifactor y permisos excesivos continúan siendo problemas independientemente de dónde se encuentre alojado el correo.
Para muchas organizaciones, además, mantener correo privado sigue teniendo sentido por razones económicas, regulatorias, de integración, privacidad o control de información.
La discusión más interesante, por tanto, no debería centrarse exclusivamente en correo privado versus correo en la nube, sino en algo mucho más básico: correo administrado versus correo abandonado.
El correo privado necesita operación continua
Instalar Zimbra no es lo mismo que operar Zimbra.
Una plataforma de correo expuesta permanentemente a Internet necesita mantenimiento continuo. Esto incluye actualizaciones de seguridad, monitoreo, revisión de logs, backups, control de reputación, mecanismos antispam y antiphishing, políticas de autenticación y configuraciones adecuadas de SPF, DKIM y DMARC.
También requiere algo que suele olvidarse: capacidad de reacción.
Cuando aparece una vulnerabilidad crítica, alguien debe determinar rápidamente si afecta a la infraestructura, evaluar la actualización, aplicarla y posteriormente comprobar que no existan indicios de explotación previa.
Ese trabajo ocurre detrás del servicio que el usuario simplemente percibe como “mi correo”.
Y probablemente ahí se encuentre una de las mayores diferencias entre contratar únicamente infraestructura y contratar un servicio administrado.
Si su empresa utiliza Zimbra, hay una pregunta más importante que conocer la versión
Naturalmente, ante la vulnerabilidad CVE-2026-73570 lo primero es verificar si la instalación se encuentra actualizada y si utiliza la configuración afectada. Pero para un gerente o responsable de una empresa, el incidente debería servir para hacer una revisión más amplia.
Conviene saber quién tiene actualmente la responsabilidad sobre el servidor, cuándo se realizó la última actualización, qué servicios están expuestos a Internet, si existen copias de seguridad verificadas y qué ocurriría si mañana fuera necesario reconstruir completamente la plataforma.
También vale la pena revisar la configuración de SPF, DKIM y DMARC, la reputación de las direcciones IP utilizadas para enviar correo y la existencia de mecanismos capaces de detectar comportamientos anómalos.
No porque Zimbra sea particularmente inseguro, sino porque el correo electrónico es demasiado importante para que su seguridad dependa simplemente de que alguien recuerde actualizarlo.
La verdadera alerta detrás de los servidores Zimbra comprometidos
Los cientos de servidores comprometidos probablemente dejarán de ser noticia en poco tiempo. Aparecerá otra vulnerabilidad, después otra plataforma afectada y el ciclo volverá a repetirse.
Pero existe una conclusión que las empresas deberían conservar.
El riesgo no comienza cuando aparece una vulnerabilidad. Comienza mucho antes, cuando una organización pierde visibilidad sobre quién mantiene su infraestructura, qué versión está ejecutando y cómo respondería ante una amenaza.
Zimbra puede actualizarse. Una vulnerabilidad puede corregirse. Un servidor incluso puede reconstruirse.
Lo verdaderamente peligroso es tener infraestructura crítica conectada a Internet sin que exista alguien responsable de cuidarla continuamente.
Para las empresas que utilizan Zimbra, este incidente es una buena oportunidad para revisar algo más que una versión de software.
Es una oportunidad para preguntarse quién está realmente detrás de su correo corporativo cuando nadie está mirando.
En SciWebHosting creemos que esa es la conversación que vale la pena tener.
Deja una respuesta