Alertas

CVE-2026-5513 en Bookly: XSS almacenado no autenticado en WordPress

CVE-2026-5513 en Bookly: XSS almacenado no autenticado en WordPress

Resumen

Bookly <= 27.2 tiene un XSS almacenado no autenticado via cookie bookly-customer-full-name. Wordfence lo marca como CVSS 7.2 High y la correccion esta en 27.3 o superior.

Actualizacion rapida: Wordfence Intelligence ha publicado el 12 de junio de 2026 una vulnerabilidad en Online Scheduling and Appointment Booking System – Bookly, un plugin de reservas y citas para WordPress usado por negocios locales, clinicas, academias, servicios profesionales y sitios con formularios de booking.

El fallo esta registrado como CVE-2026-5513 y afecta a Bookly <= 27.2. Wordfence lo clasifica con CVSS 7.2 High y lo describe como un stored cross-site scripting no autenticado a traves de la cookie bookly-customer-full-name.

Que ha pasado

La vulnerabilidad permite que un atacante sin credenciales inyecte scripts que pueden ejecutarse cuando un usuario accede a una pagina afectada. En plugins de reservas, este tipo de fallo merece atencion porque el formulario suele estar expuesto al publico y conectado a flujos de clientes, notificaciones y paneles de gestion.

No hay explotacion activa verificada en las fuentes revisadas para esta alerta. La razon para priorizarla no es el alarmismo, sino la combinacion de exposicion publica, instalacion relevante y una version corregida ya disponible.

A quien afecta

Segun Wordfence, las instalaciones con Bookly 27.2 o anterior estan afectadas. El changelog oficial del vendor indica que la version 27.3 corrige CVE-2026-5513, y WordPress.org muestra actualmente la version 27.7.

WordPress.org indica unas 70.000 instalaciones activas. Eso lo convierte en un caso relevante para agencias que mantienen webs de servicios, salud, belleza, educacion, reservas o negocios locales con formularios de cita.

Por que importa

Un XSS almacenado no autenticado puede parecer menos urgente que una RCE o una toma de administrador, pero no debe tratarse como ruido. Si el punto vulnerable esta en un flujo publico de reservas, un atacante puede intentar contaminar datos que luego ve personal interno, administradores o clientes.

En carteras multi-sitio, el riesgo real esta en perder visibilidad: sitios con Bookly instalado, versiones desalineadas, clientes que no saben si usan el formulario vulnerable y revisiones manuales hechas web por web.

Que hacer ahora

Como priorizarlo en entornos multi-sitio

Para una agencia, la primera pregunta practica es simple: que webs tienen Bookly y cuales siguen en 27.2 o anterior. Despues conviene ordenar por exposicion: formularios publicos, volumen de reservas, datos personales, ecommerce, clientes regulados o webs con administracion compartida.

La verificacion posterior tambien importa. No basta con actualizar un plugin: hay que confirmar que el formulario sigue funcionando, que no se rompe el flujo de citas y que los responsables del sitio saben que la correccion se ha aplicado.

Fuentes

Donde encaja Vulnity

Vulnity no detecta automaticamente este CVE ni corrige vulnerabilidades de plugins por si solo. Su valor aqui es operativo: centralizar visibilidad multi-sitio, acelerar la respuesta, revisar hardening, detectar actividad sospechosa y bloquear IPs maliciosas cuando aplique. En vulnerabilidades de plugins de uso comun, esa capa ayuda a pasar de una lista dispersa de webs a una respuesta coordinada.

Sobre Vulnity

Cuando una vulnerabilidad WordPress importa, importan el inventario y la velocidad de respuesta. Vulnity ayuda a agencias a coordinar revisiones, hardening y respuesta multi-sitio.

Compartir X / Twitter LinkedIn