Microsoft detectó ataques contra Zimbra antes de que la falla se hiciera pública
Atacantes aprovecharon CVE-2026-73570 en Zimbra para instalar web shells, obtener root y robar buzones, semanas antes de la divulgación pública de la falla.
Investigadores de Microsoft documentaron una campaña que explotó una vulnerabilidad de Zimbra Collaboration Suite durante las semanas que separaron la publicación silenciosa del parche y la divulgación oficial de la falla. El caso, publicado el 1 de octubre de 2026, muestra cómo los atacantes analizan las actualizaciones de software para encontrar fallas antes de que los administradores sepan que deben parchear.
La cronología
La falla, CVE-2026-73570, es una inyección de comandos sin autenticación. Zimbra la corrigió el 20 de julio en la versión 10.1.20. Entre el 28 de julio y el 7 de agosto, Microsoft detectó dos herramientas de escaneo que sondeaban el código vulnerable. La divulgación pública del identificador CVE llegó el 13 de agosto. Durante ese intervalo, los servidores sin actualizar quedaron expuestos sin que sus administradores tuvieran una alerta clara.
Qué hicieron los atacantes
Tras confirmar que podían ejecutar comandos, los intrusos instalaron web shells y shells reversas, escalaron privilegios y obtuvieron acceso root en al menos un sistema. Extrajeron credenciales de cuentas de servicio y datos de buzones, e intentaron comprimir y exfiltrar respaldos de correo hacia Azure Blob Storage con la herramienta AzCopy.
Un detalle llamó la atención de los investigadores: después de plantar las web shells, los atacantes restauraban los permisos originales de los archivos, una táctica para pasar inadvertidos en revisiones básicas. Las víctimas pertenecen a varias regiones e industrias, y Microsoft no atribuyó la campaña a un grupo específico.
Quiénes están expuestos
Solo son vulnerables los servidores que tienen instalado el paquete opcional de monitoreo SNMP con las notificaciones activadas. La corrección consiste en actualizar a la versión 10.1.20 o posterior. Como alternativa temporal, se puede retirar el paquete SNMP o desactivar sus notificaciones.
Por qué importa
El caso ilustra un riesgo frecuente: cuando un fabricante corrige una falla sin anunciarla, los atacantes que comparan versiones del código pueden descubrirla primero. Las organizaciones que aplican parches solo cuando aparece un aviso de seguridad quedan en desventaja. Mantener una política de actualización regular, independiente de los boletines, reduce esa ventana.
Quienes operan Zimbra deben verificar la versión, revisar si el paquete SNMP está instalado, buscar archivos ejecutables recientes en directorios web y rotar las credenciales de cuentas de servicio.
Lectura regional
Zimbra es una opción de correo extendida en universidades, alcaldías, ministerios y empresas medianas de República Dominicana y América Latina, sobre todo por su costo y la posibilidad de alojarlo en infraestructura propia. Esas instalaciones suelen depender de un solo administrador o de un proveedor externo, con ciclos de actualización irregulares. Este es un buen momento para auditar versiones y documentar quién es responsable de aplicar los parches.
Fuente: The Register, "Microsoft catches hackers exploiting Zimbra bug before disclosure", 1 de octubre de 2026.