INCIBE-CERT coordinó la publicación de dos vulnerabilidades de secuencias de comandos entre sitios —XSS— persistentes en el módulo WebTop de NethServer. Los fallos afectan al calendario y a los contactos compartidos: un usuario autenticado puede almacenar contenido malicioso que se ejecuta cuando otra persona abre el evento o el contacto.
La alerta, publicada el 24 de agosto de 2026, identifica como afectadas las versiones 1.5.6 y anteriores y sitúa la corrección en WebTop 1.5.7. No existe en el aviso evidencia de explotación activa. Esa diferencia es importante: la severidad exige actuar, pero no justifica afirmar que una organización española haya sido comprometida.
Para una empresa que utiliza este entorno colaborativo, la respuesta no termina al instalar la versión corregida. Un XSS persistente puede haber quedado almacenado en datos legítimos y haberse ejecutado en el navegador de usuarios con permisos distintos. La tarea consiste en corregir, revisar contenido, invalidar sesiones cuando proceda y conservar registros suficientes para determinar si hubo actividad anómala.
Qué confirmó INCIBE-CERT
El aviso INCIBE-2026-578 asigna severidad alta a ambos fallos. CVE-2026-78331 afecta a campos de eventos del calendario; CVE-2026-78332, a campos de la libreta de direcciones compartida. En los dos casos, la causa descrita es una validación y codificación insuficientes de la información que después representa el navegador.
| Identificador | Componente | CVSS v4.0 | Condición relevante |
|---|---|---|---|
| CVE-2026-78331 | Calendario | 8,7 | El atacante necesita autenticarse; otra persona debe visualizar el evento. |
| CVE-2026-78332 | Contactos | 8,2 | El contenido queda en una libreta compartida y se ejecuta al abrir el contacto. |
La versión 1.5.7 publicada por NethServer incorpora las correcciones de seguridad. Si una instalación ya está en 1.5.8 o una versión posterior, el inventario debe demostrarlo en el componente desplegado, no limitarse a la versión general del servidor o de la plataforma.
Cómo funciona el riesgo
Un XSS persistente no depende de enviar a la víctima un enlace externo cada vez. El código se guarda dentro de un objeto que la aplicación considera normal. En este caso, el vehículo puede ser un evento de calendario o una ficha de contacto. Cuando otro usuario abre ese registro, el navegador procesa el contenido en el contexto de la sesión de WebTop.
El alcance potencial depende de los privilegios de quien visualiza el registro, de las protecciones de la aplicación y del navegador, y de los servicios integrados. INCIBE menciona como impactos posibles el secuestro de sesión, el acceso a correo, contactos o archivos y la realización de acciones no autorizadas. Son capacidades potenciales del fallo, no evidencia de que se hayan materializado en una organización concreta.
El requisito de autenticación reduce una parte de la superficie, pero no elimina el riesgo. Una cuenta comprometida, un usuario interno malicioso o una integración que inserte datos sin controles puede almacenar el contenido. Además, los calendarios y las libretas compartidas tienen una característica operacional delicada: un único registro puede ser consultado por muchas personas y alcanzar cuentas con más privilegios.
Cómo determinar el alcance real
El primer paso es construir una lista verificable de instancias NethServer, módulos WebTop y versiones efectivamente desplegadas. Conviene incluir entornos de producción, contingencia, pruebas, sedes y sistemas administrados por proveedores. La búsqueda por nombre comercial no basta si el componente está integrado dentro de una solución mayor.
Después se debe revisar quién puede crear o modificar eventos y contactos compartidos, qué fuentes externas alimentan esos datos y qué cuentas poseen permisos elevados. Los registros de autenticación, actividad de la aplicación, proxy inverso y navegador administrado pueden ayudar a relacionar cambios inusuales con aperturas posteriores. Si aparecen indicadores, hay que preservar las marcas de tiempo y las copias originales antes de limpiar los registros.
Un análisis de vulnerabilidades permite contrastar versión, exposición y configuración sin asumir que el inventario documental está actualizado. Cuando existen señales de ejecución o sesiones posiblemente comprometidas, el análisis forense digital ayuda a reconstruir qué cuenta creó el objeto, quién lo visualizó y qué actividad ocurrió después.
Plan de respuesta
- Confirmar la versión real. Identificar WebTop 1.5.6 o anterior en cada instancia, incluida la contingencia, y registrar propietario y exposición.
- Actualizar a una versión corregida. Aplicar 1.5.7 o posterior siguiendo el procedimiento del fabricante, con copia de seguridad y prueba funcional del calendario, contactos, correo y archivos.
- Revisar contenido compartido. Buscar cambios inesperados en eventos y contactos, especialmente registros creados por cuentas nuevas, inactivas o fuera de su patrón normal.
- Evaluar las sesiones. Si existe evidencia razonable de ejecución, invalidar sesiones afectadas, cambiar credenciales cuando corresponda y revisar tokens o integraciones accesibles desde la cuenta.
- Correlacionar registros. Relacionar creación y consulta de objetos con autenticaciones, direcciones de origen, acciones sobre correo o archivos y cambios de configuración.
- Validar el cierre. Confirmar la versión, probar que los campos quedan saneados y documentar la evidencia. Actualizar sin verificación deja una conclusión incompleta.
Una regla temporal en un WAF puede reducir algunos patrones, pero no sustituye la corrección del componente ni garantiza que detecte contenido ya almacenado. También debe evitarse borrar masivamente calendarios o contactos antes de comprender si contienen evidencia útil o información operativa que necesita conservarse.
Lectura para empresas de España
La conexión con España es directa por la coordinación de INCIBE-CERT, no por una campaña confirmada contra empresas del país. La prioridad de cada organización depende de si utiliza WebTop, de la versión instalada y de la capacidad de un registro compartido para alcanzar usuarios con acceso a correo, archivos u otras funciones sensibles.
La decisión ejecutiva correcta es acotada: localizar el componente, corregirlo y exigir evidencia de cierre. Si el servicio lo gestiona un tercero, la organización debe pedir versión, fecha de actualización, alcance de la revisión retrospectiva y procedimiento ante hallazgos. Un modelo de CISO as a Service puede coordinar estas evidencias entre TI, proveedor, privacidad y dirección sin convertir una alerta técnica en una lista de tareas sin propietario.
Convierta la alerta en evidencia de cierre
Insylux puede ayudar a identificar instancias afectadas, validar la actualización y revisar sesiones, eventos, contactos y registros con un alcance proporcional al riesgo.
Solicite una revisión focalizada de NethServer WebTop con el Equipo Insylux.
Fuentes y alcance
Artículo elaborado el 25 de agosto de 2026 a partir del aviso de INCIBE-CERT, de los avisos de seguridad enlazados por el proyecto y de las publicaciones de versiones de NethServer. La información pública confirma las versiones afectadas y la corrección en 1.5.7; no confirma explotación activa ni víctimas en España. Las recomendaciones de inventario, revisión de sesiones y correlación de registros son medidas defensivas propuestas por el Equipo Insylux.
