Una falla XSS almacenada oculta a simple vista

Una vulnerabilidad recién revelada en Zimbra Collaboration Suite está dando a los equipos de seguridad un motivo para revisar dos veces sus registros de parches. Identificada como CVE-2025-66376, la falla es un problema de cross-site scripting (XSS) almacenado en el Cliente Web Clásico, la interfaz antigua basada en HTML que muchas implementaciones de Zimbra siguen utilizando junto con la aplicación web moderna.

Lo que hace notable a este error es lo poco que la víctima debe hacer para activarlo. Según la divulgación, simplemente abrir un correo malicioso en la interfaz clásica es suficiente para ejecutar código controlado por el atacante dentro de la sesión autenticada del webmail de la víctima. A partir de ahí, el atacante puede extraer tokens de sesión, contraseñas almacenadas en el navegador e incluso los códigos de respaldo de autenticación de dos factores, esos códigos auxiliares en los que los usuarios confían cuando su método principal de 2FA no está disponible.

Cómo funciona el ataque

Las vulnerabilidades XSS almacenadas son particularmente peligrosas porque la carga maliciosa no necesita ser cliqueada ni descargada por separado. Se incrusta directamente en el contenido que el cliente de correo renderiza automáticamente, en este caso a través de directivas de Hojas de Estilo en Cascada (CSS) insertadas en un correo electrónico. El Cliente Web Clásico de Zimbra no saneó correctamente este contenido, lo que permitió que el CSS ejecutara JavaScript en el contexto de la sesión del buzón del usuario autenticado.

Una vez que ese código se ejecuta, hereda todo a lo que la sesión de la víctima ya tiene acceso. Eso es lo que le permite ir más allá de la bandeja de entrada y obtener tokens de autenticación, credenciales almacenadas en caché por el navegador y códigos de respaldo 2FA guardados para la recuperación de la cuenta. En la práctica, esto convierte un simple correo abierto en un posible robo completo de la cuenta, sin que la víctima introduzca una contraseña ni haga clic en un enlace sospechoso.

No es la primera vez que la gestión de contenido incrustado del Cliente Web Clásico causa problemas. Zimbra ha tenido que parchear anteriormente fallos similares de saneamiento de HTML y archivos ICS en la misma interfaz, un patrón que subraya por qué las organizaciones que aún ejecutan el cliente heredado se enfrentan a una exposición recurrente hasta que apliquen parches de forma agresiva o migren completamente fuera de él.

Quién debe actuar

La vulnerabilidad afecta a Zimbra Collaboration (ZCS) 10 anterior a la versión 10.0.18 y 10.1 anterior a la versión 10.1.13. Zimbra ha publicado las compilaciones corregidas, y el propio aviso de seguridad de la compañía describe el parche como una solución para una vulnerabilidad crítica de XSS almacenado en el Cliente Web Clásico. Las organizaciones que ejecuten versiones afectadas deben tratar esta actualización como prioritaria, no como algo que programar para la próxima ventana de mantenimiento rutinario, ya que la explotación no requiere interacción del usuario más allá de abrir un correo.

Dado que la falla reside en el acceso a nivel de sesión, aplicar el parche por sí solo puede no ser suficiente si una cuenta ya estaba comprometida antes de la actualización. Los administradores también deberían considerar auditar la actividad de inicio de sesión reciente, rotar los tokens de sesión y reemitir los códigos de respaldo 2FA para las cuentas que tuvieron acceso a la interfaz clásica mientras la vulnerabilidad estaba sin parchear.

Qué significa esto para ti

Si usas el webmail de Zimbra, ya sea como particular, pequeña empresa o como parte de la infraestructura de correo de una organización más grande, esta vulnerabilidad es un recordatorio de que los tokens de autenticación y los códigos de respaldo son tan seguros como el software que renderiza tu bandeja de entrada. La autenticación de dos factores es una fuerte defensa contra ataques basados en contraseñas, pero un error de XSS almacenado que puede extraer los códigos de respaldo directamente desde una sesión del navegador demuestra que 2FA no es una solución milagrosa si el propio cliente web subyacente está comprometido.

Para los usuarios cotidianos, el riesgo práctico depende de si tu proveedor de correo o departamento de TI ejecuta Zimbra y, específicamente, si el Cliente Web Clásico sigue en uso. La mayoría de las personas no necesitarán hacer nada más que esperar a que su administrador aplique el parche. Para los administradores y equipos de TI, sin embargo, esto es un asunto de acción inmediata.

Conclusiones prácticas

  • Confirma que tu implementación de Zimbra esté ejecutando ZCS 10.0.18, 10.1.13 o posterior; cualquier versión anterior está expuesta a CVE-2025-66376.
  • Si tu organización aún depende del Cliente Web Clásico, prioriza el parcheo sobre cualquier calendario de migración a la interfaz moderna que hayas planificado.
  • Después de aplicar el parche, revisa los registros de autenticación recientes en busca de anomalías y considera rotar los tokens de sesión de las cuentas que estuvieron activas durante la ventana de exposición.
  • Reemite los códigos de respaldo 2FA para cualquier cuenta con indicios de actividad sospechosa, ya que los códigos de respaldo robados pueden eludir por completo las protecciones de dos factores.
  • A partir de ahora, trata los avisos de XSS almacenado de tu proveedor de correo como alta prioridad, ya que no es la primera vez que el cliente heredado de Zimbra necesita correcciones de saneamiento de emergencia.

Mantenerse por delante de vulnerabilidades como esta se reduce a una disciplina rutinaria de parches y a saber exactamente qué cliente web utiliza realmente tu organización en el día a día. Unos minutos dedicados a confirmar tu versión de Zimbra ahora son mucho más baratos que recuperarse de un buzón comprometido más tarde.