Un servidor de correo que llevaba cinco semanas parchado en el repositorio del fabricante, pero sin parchar en producción, es todo lo que hizo falta. Shadowserver contó 274 instancias de Zimbra Collaboration Suite con artefactos de compromiso el sábado pasado, y CISA le puso a las agencias federales de Estados Unidos un plazo de tres días para cerrar el hueco: uno de los más agresivos que ha emitido este año.
La falla es CVE-2026-73570, una inyección de comandos de sistema operativo, sin autenticación, que termina en ejecución remota de código con los privilegios del usuario zimbra. Y el patrón es el de siempre en este producto: el parche existía desde julio.
Qué pasó
Synacor liberó ZCS 10.1.20 el 20 de julio con la corrección de una inyección de comandos que un atacante remoto puede disparar sin credenciales. En la descripción de CISA, el vector son peticiones SMTP especialmente construidas que acaban ejecutando comandos arbitrarios del sistema operativo como el usuario zimbra; los reportes de la campaña apuntan al componente de monitoreo, en instalaciones donde las notificaciones SNMP están habilitadas. Ese matiz importa y lo retomo más abajo, porque es la diferencia entre "todo el parque está en llamas" y "una fracción configurable lo está".
El 17 de agosto, CERT Polska —el equipo de respuesta a incidentes de Polonia— fue el primero en marcar la falla como explotada en el mundo real, no como riesgo teórico. Cuatro días después, el 21 de agosto, CISA la sumó al catálogo de Known Exploited Vulnerabilities y ordenó a las agencias del Federal Civilian Executive Branch remediar antes del 24 de agosto, bajo la directiva BOD 26-04. Tres días de ventana para un servidor de correo productivo es, en términos operativos, "hazlo el fin de semana".
El 22 de agosto Shadowserver puso número al daño:
Los compromisos de Zimbra asociados a la explotación de CVE-2026-73570 se están extendiendo. 274 instancias vistas comprometidas en nuestros escaneos de artefactos de explotación el 2026-08-22. — Shadowserver Foundation
En el mismo reporte, la organización detectó al menos 8,200 instancias expuestas a internet sin parchar, con una advertencia honesta que casi nadie repite al citar la cifra: sin parchar no significa explotable, porque la vulnerabilidad vive en una configuración que no es la default.
Por qué importa
ZCS no es un producto de nicho. Es la alternativa on-premise a Microsoft 365 y Google Workspace para universidades, gobiernos estatales, telcos e integradores que quieren el correo en su propio datacenter —por soberanía de datos, por costo, o por ambas. En México y LATAM esa descripción cubre a un montón de dependencias públicas y de instituciones educativas. Cuando un atacante consigue RCE como usuario zimbra, no está tocando un servidor cualquiera: está sentado encima del buzón de toda la organización.
Y ahí está la parte que suele quedar fuera del titular. Un servidor de correo comprometido no es solo un servidor comprometido. Es:
- El histórico completo de correo de directivos, jurídico, finanzas y RH, exfiltrable en silencio.
- Reseteo de contraseñas de todo lo demás. Quien lee el correo intercepta los enlaces de recuperación de cualquier SaaS de la organización.
- Una plataforma de phishing con reputación legítima, capaz de escribir desde el dominio real a proveedores y clientes.
- Persistencia cómoda: webshells en los directorios de Jetty sobreviven a reinicios y pasan desapercibidas en un host que nadie monitorea con EDR porque "es solo el mail".
Zimbra arrastra este historial desde años. En marzo, investigadores de Seqrite Labs documentaron a APT28 —inteligencia militar rusa— abusando de un XSS almacenado en Zimbra contra servidores del gobierno ucraniano. En octubre de 2024, agencias de Estados Unidos y Reino Unido alertaron que APT29 (Midnight Blizzard, Cozy Bear) comprometía servidores Zimbra para robar credenciales de cuentas de correo. Y Winter Vivern explotó un XSS reflejado para sacar correo de cuentas alineadas a la OTAN. El patrón es consistente: los actores estatales tratan a Zimbra como puerta de entrada al correo diplomático y gubernamental, y los criminales de oportunidad llegan detrás a monetizar lo que quedó abierto.
La diferencia esta vez es la velocidad. Cinco semanas entre parche y explotación masiva documentada es una ventana corta, y sugiere que alguien hizo ingeniería inversa del fix del 20 de julio en lugar de esperar un PoC público.
El detalle técnico
Command injection sin autenticación es la categoría más rentable que existe para un atacante, porque no hay nada que evadir: no hay login que hacer, no hay contraseña que adivinar, no hay MFA que sortear. Un servicio expuesto que construye una llamada al shell concatenando entrada controlada por el atacante, y el atacante escribe el resto.
Que el disparo pase por el componente de notificaciones SNMP es el detalle interesante. SNMP es la clase de subsistema que se habilita el primer día para meter el servidor al NMS de monitoreo y nadie vuelve a revisar en cuatro años. No está en el default de ZCS, lo cual reduce la superficie real —esos 8,200 servidores sin parchar no son 8,200 servidores explotables—, pero introduce un problema peor para el defensor: no puedes saber si eres vulnerable mirando solo la versión. Tienes que ir a ver tu configuración. Y las organizaciones que dejaron un ZCS sin actualizar cinco semanas después de un parche de seguridad son, estadísticamente, las mismas que no tienen inventario de qué componentes traen habilitados.
Del lado forense, la guía de CERT Polska es concreta y es lo que hay que ejecutar hoy. Los indicadores a buscar en los últimos 30 días:
- Reinicios inesperados del servicio Zimbra. La explotación de una inyección de comandos en un componente del servicio tiende a tumbarlo y levantarlo; ese reinicio sin ventana de cambio asociada es la señal más barata de todas.
- Archivos creados por el usuario
zimbraen/opt/zimbra/jetty/webapps/,/opt/zimbra/jetty_base/webapps/y/tmp/. Los dos primeros son directorios servidos por el contenedor web: cualquier.jspque apareció ahí sin un despliegue detrás es una webshell hasta que pruebes lo contrario.
Nota el orden lógico: la ejecución es como zimbra, no como root, así que el atacante escribe donde zimbra puede escribir. Eso hace el triage acotado y verificable.
Qué hacer
Si administras ZCS, en este orden y hoy:
- Verifica la versión. Cualquier cosa por debajo de 10.1.20 es vulnerable. Actualiza; el parche tiene cinco semanas de rodaje, ya no hay argumento de "esperar a que madure".
- Revisa si tienes notificaciones SNMP habilitadas. Si no las usas —y probablemente no las usas—, deshabilítalas. Es mitigación inmediata mientras agendas la actualización.
- Asume compromiso y busca los artefactos antes de declarar victoria. Parchar un servidor que ya tiene webshell solo le quita al atacante la puerta que ya no necesita. Busca los reinicios del servicio y los archivos nuevos en los tres directorios de arriba, en la ventana de 30 días.
- Si encuentras algo, rota credenciales de todo. No solo las de Zimbra: las de cualquier servicio cuyo enlace de recuperación llegue a un buzón de ese servidor. Y revisa reglas de reenvío automático en las cuentas ejecutivas, que es la persistencia favorita en compromisos de correo.
- Saca la interfaz administrativa y SNMP de internet. Un ZCS con el panel de administración y el puerto de monitoreo expuestos al mundo es una decisión, no un accidente. Ponlos detrás de VPN o de segmentación, y déjalos ahí.
- Métele telemetría al servidor de correo. Si tu EDR no cubre el host de Zimbra porque es un appliance Linux "que solo manda correo", esa es la brecha de fondo. Los 274 comprometidos no se detectaron solos: los contó un escáner externo.
La lectura de este caso es más incómoda que el CVE. La cadena falló en el eslabón más aburrido: había parche, había advisory, había CERT avisando, y aún así 274 organizaciones se enteraron de su propio incidente porque una fundación de escaneo pasivo lo publicó en un tablero. El correo sigue siendo la infraestructura más crítica y peor monitoreada del enterprise promedio.