Zimbra bajo ataque zero-click: CVE-2025-66376 roba credenciales y accede a buzones sin interacción del usuario

Un grupo de espionaje con apoyo estatal ruso explotó durante meses una vulnerabilidad desconocida en el cliente web clásico de Zimbra para leer buzones occidentales sin necesidad de interacción más allá de que la víctima visualizara el mensaje: basta con que el correo se renderice en una sesión autenticada para que el exploit se dispare. Este escenario de "view-based" o cero‑click eleva el riesgo operativo porque el control queda en manos del contenido HTML del correo, no en una acción explícita del usuario.

Técnicamente, la falla identificada como CVE-2025-66376 es un stored cross‑site scripting en la Classic UI de Zimbra que abusa del manejo de @import en CSS para reconstruir un <svg onload=...> fragmentado —una técnica denominada por algunos "tag‑splitting"— y así ejecutar JavaScript con los permisos de la sesión web afectada. El payload descrito por los investigadores roba el token CSRF, contraseñas que el navegador autocompleta, códigos de recuperación 2FA y usa las APIs internas de Zimbra para extraer datos de la plataforma y del buzón.

El exploit afectó a Zimbra Collaboration Server en versiones anteriores a 10.0.18 y 10.1.13; el fabricante publicó parches el 6 de noviembre de 2025 y, más tarde, la vulnerabilidad fue incluida en el catálogo de vulnerabilidades explotadas conocido por CISA. Para referencias técnicas públicas sobre la vulnerabilidad puede consultarse la ficha del CVE en el NVD y en MITRE: Ficha NVD de CVE-2025-66376 y Ficha MITRE de CVE-2025-66376.

El código malicioso, identificado por algunos proveedores como "ZimReaper", exfiltra datos mediante consultas DNS con subdominios largos y aleatorios, genera un archivo TGZ con hasta 90 días de correo y, de forma preocupante, crea una contraseña de aplicación llamada ZimbraWeb mediante CreateAppSpecificPasswordRequest. Esas contraseñas permiten acceso IMAP/POP/SMTP sin requerir el 2FA, y sobreviven a cambios de contraseña convencionales si no se revocan explícitamente.

La campaña fue observada atacando organizaciones de gobiernos, defensa, transporte y finanzas en múltiples regiones; los análisis públicos la asocian con clusters de actores nombrados de forma diversa (LAUNDRY BEAR, Void Blizzard, TA488, CL‑STA‑1114), pero la atribución exacta no es el punto central para defensores: lo crítico es que la explotación persistente puede dejar credenciales y puertas traseras que un simple parche no elimina.

Desde la perspectiva de respuesta y mitigación, hay dos frentes obligatorios: aplicar el parche y asumir que las cuentas que visualizaron mensajes maliciosos pueden estar comprometidas. Actualice inmediatamente las instancias afectadas a al menos 10.1.13 si usa la rama 10.1 y lleve despliegues 10.0 a una rama soportada; sin embargo, el parche detiene nuevos envíos maliciosos pero no revoca credenciales ya exfiltradas.

Operativamente, trate como potencialmente comprometidos todos los buzones que en el periodo de la campaña abrieran o previsualizaran mensajes en la Classic UI. Entre las acciones imprescindibles: restablecer contraseñas, invalidar sesiones activas, regenerar y forzar la entrega de nuevos códigos 2FA/scratch codes, y revocar cualquier app‑specific password llamado ZimbraWeb. Busque en /opt/zimbra/log/audit.log entradas de CreateAppSpecificPassword y en los ajustes cuentas con zimbraPrefImapEnabled en TRUE que no tengan justificación operativa.

Detección y monitoreo deben incluir alertas en DNS por consultas a los dominios y subdominios observados en la campaña (búsquedas de subdominios aleatorios y patrones largos), auditoría de llamadas SOAP inusuales como GetScratchCodesRequest, y análisis del HTML de los mensajes que fueron recibidos pero no abiertos: el patrón fragmentado de @import que reconstruye el <svg onload> es detectable por reglas YARA publicadas por proveedores.

No olvide que el exploit aprovecha la confianza del navegador en el autocompletado y en credenciales almacenadas: considere políticas temporales que deshabiliten el autocompletado en accesos web a webmails corporativos, restrinjan el uso de la Classic UI, y apliquen controles de navegación como proxys que puedan sanitizar o bloquear HTML activo en correos. En entornos críticos, la mitigación inmediata puede incluir desactivar temporalmente la vista previa HTML hasta confirmar limpieza y parches.

La lección estratégica es clara: las vulnerabilidades de renderizado de correo son críticas porque convierten el cliente de correo en una fachada que otorga los permisos del usuario a un atacante sin clics adicionales. Para equipos de seguridad esto exige combinar parcheo ágil con inventario de credenciales, monitoreo DNS y de logs, y procedimientos de recuperación que incluyan revocación de credenciales persistentes y verificación de configuraciones de acceso (IMAP/SMTP/POP) después de parchear.

Si su organización usa Zimbra, priorice la actualización, ejecute las comprobaciones de cuenta descritas, y coordine la investigación con su CSIRT o proveedores de respuesta. La política de comunicación interna debe avisar a usuarios potencialmente afectados para que colaboren en la rotación de credenciales y en la identificación de reglas de reenvío o mensajes desaparecidos. La defensa efectiva ante este tipo de campañas combina parche, limpieza de cuentas y control del canal de correo más que depender de un único remedio técnico.