XSS almacenado en CoverManager
Identificamos una vulnerabilidad de Cross-Site Scripting (XSS) persistente en CoverManager, la plataforma de reservas que utilizan miles de restaurantes en España y otros países. Trabajamos con el fabricante hasta el parche y publicamos el advisory de forma coordinada con INCIBE-CERT.
Datos del advisory
- CVSS v4.0
- 5.3
- CWE
- CWE-79
- Severidad
- Medium
- Fabricante
- CoverManager
- Producto
- CoverManager (software de reservas)
- Versiones afectadas
- Versiones anteriores al parche del fabricante (2025)
- Corrección
- Versión actualizada por CoverManager tras coordinación con INCIBE-CERT
- Estado
- Parcheada
- Descubierto por
- Javier Paradelo
- Publicación NVD
- 2025-05-26
- Vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N
Resumen rápido
Un atacante remoto sin autenticación podía inyectar JavaScript que quedaba almacenado en CoverManager y se ejecutaba en el navegador de cualquier usuario que abriera la página afectada (incluido personal del restaurante con permisos elevados). El fabricante aplicó la corrección y el caso quedó registrado en NVD y en INCIBE-CERT con identificador INCIBE-2025-0267.
Por qué importa
CoverManager gestiona reservas de miles de restaurantes y, con ellas, datos personales de sus clientes (nombre, teléfono, correo, comentarios sobre alergias, peticiones especiales). Una vulnerabilidad XSS persistente sobre una pieza así no es ruido teórico: cualquier código inyectado se sirve a partir de ese momento a cada empleado o cliente que cargue la página afectada.
El impacto realista varía según dónde caiga el payload. Sobre un panel interno del restaurante, robar la sesión del gerente abre la puerta a leer el listado completo de comensales, modificar reservas o exportar datos. Sobre un widget público, ejecuta scripts en el navegador del cliente final. En cualquiera de los dos escenarios hay implicaciones de RGPD, porque los datos comprometidos son personales.
Lo que hace especial al XSS frente a un XSS reflejado clásico es la persistencia. El atacante no necesita engañar a la víctima para que pinche un enlace raro: la página normal del producto, accedida desde un marcador o desde el flujo habitual de trabajo, ya entrega el payload. La detección por el equipo defensivo es más complicada porque el comportamiento parece legítimo.
Detalle técnico
El fallo se enmarca en CWE-79 (Improper Neutralization of Input During Web Page Generation). Una entrada controlada por el atacante se almacenaba en la base de datos del producto y se devolvía sin sanear al renderizar páginas posteriores, permitiendo la ejecución de JavaScript arbitrario en el contexto del dominio de CoverManager.
Por política de divulgación responsable no publicamos el parámetro exacto, ni el endpoint, ni un payload reproducible mientras existan despliegues sin actualizar. Lo que sí podemos decir es que el flujo de explotación no requería autenticación previa por parte del atacante, aunque sí interacción del usuario víctima (carga de la página afectada). Esto se refleja en el vector CVSS:4.0 con AT:N (sin condiciones de ataque), PR:N (sin privilegios) y UI:P (interacción pasiva).
El impacto sobre confidencialidad e integridad del producto vulnerable es nulo en sí mismo (VC:N, VI:N), pero el impacto sobre el sistema posterior (la víctima que carga la página) es bajo en confidencialidad e integridad (SC:L, SI:L). Es la firma típica del XSS almacenado moderno bajo CVSS v4.0: el riesgo real está aguas abajo, en el navegador del usuario.
Lectura del vector CVSS
El score nominal de 5,3 puntos esconde matices. Estos son los componentes que más pesan en el cálculo y por qué.
AV:N (Network)Atacante remoto
El payload se sirve por la red. No hace falta acceso físico ni a la red interna del restaurante.
PR:N (None)Sin autenticación previa
Quien introduce el contenido malicioso no necesita una cuenta válida en CoverManager para depositar el payload.
UI:P (Passive)Interacción pasiva
La víctima sólo necesita abrir la página afectada en su flujo normal. No hace falta engaño activo (clic en un enlace raro).
SC:L · SI:LImpacto en sistemas posteriores
El daño se traslada al navegador de la víctima: cookies, tokens, datos visibles en la página.
Cronología de divulgación
Q1 2025
El equipo de Secra identifica la vulnerabilidad durante una sesión de research interna.
Q1 2025
Reporte detallado al fabricante a través de su canal oficial.
Q2 2025
CoverManager confirma el hallazgo y despliega la corrección.
26-may-2025
Publicación coordinada del advisory en NVD (CVE-2025-40652) e INCIBE-CERT (INCIBE-2025-0267).
Mitigación y recomendaciones
El parche del fabricante resuelve el caso concreto. Si tu restaurante o grupo hostelero utiliza CoverManager, basta con confirmar que la versión que sirve la plataforma incluye la corrección del aviso INCIBE-2025-0267 (al ser un SaaS, en la mayoría de tenants la actualización ya está aplicada de forma transparente).
Si desarrollas un producto comparable, las defensas estructurales contra XSS almacenado siguen siendo las mismas que llevamos años recordando: codificación contextual en el render (no sólo a la entrada), Content Security Policy estricta con nonces o hashes, y revisión específica de los puntos donde el contenido pasa de tabla de base de datos a HTML servido al cliente.
Checklist de cierre
- 1Confirmar con CoverManager que tu tenant está en versión parcheada (referencia INCIBE-2025-0267).
- 2Revisar logs de actividad inusual en cuentas de gestor del restaurante en los últimos 30 días.
- 3Si manejas el código de un producto similar, auditar codificación de salida en todos los puntos donde se renderice contenido proveniente de usuarios.
- 4Endurecer CSP: bloquear inline scripts no marcados con nonce, restringir orígenes de carga.
- 5Definir un proceso de divulgación responsable público (security.txt, página /security) para que investigadores como nuestro equipo puedan reportar sin fricción.
Qué significa esto si tienes un negocio expuesto en SaaS
Cuando dependes de un SaaS para procesar datos personales, parte de tu superficie de ataque la gestiona el fabricante. Pero la responsabilidad regulatoria sigue siendo tuya: ante la AEPD, eres responsable del tratamiento aunque el fallo técnico esté en el proveedor. Por eso recomendamos una revisión periódica de la postura de seguridad de los proveedores críticos, especialmente los que tocan datos personales o financieros.
Para piezas internas (tu propia web de reservas, tu app móvil, tu portal de cliente) el patrón se invierte: el código es tuyo y la auditoría tiene que entrar al detalle de cada vector. Es exactamente lo que cubrimos en nuestro servicio de auditoría web y móvil bajo OWASP Top 10 y MASVS, con foco en bugs como este XSS almacenado pero también IDOR, SSRF, deserialización y la familia entera de OWASP API Top 10.
Sobre el descubridor
El hallazgo lo firma Javier Paradelo, CEO y co-fundador de Secra Solutions, certificado OSCP, OSEP, OSWE y CRTO. Javier lidera el área de auditoría web y red team de la firma y mantiene un programa interno de research donde el equipo dedica tiempo a productos de uso amplio en el mercado español.
Ver equipo de Secra¿Tu plataforma resistiría una auditoría como esta?
Audita tus aplicaciones con el equipo que firma advisories en NVD. Cobertura OWASP Top 10, OWASP API Top 10 y OWASP MASVS, con prueba de concepto y plan de remediación priorizado en cada hallazgo.