# Falla de acceso en Bookly para WordPress expone datos de clientes entre empleados
Una validación omitida en la API móvil del plugin permite que cualquier staff member lea citas ajenas con solo cambiar un número en la URL
El plugin Bookly para WordPress — usado por decenas de miles de sitios de reservas en salones de belleza, consultorios médicos y centros de servicios — arrastra hasta su versión 27.7 una vulnerabilidad de acceso indebido que permite a cualquier empleado con credenciales de staff consultar citas asignadas a otros colegas. El fallo, catalogado como CVE-2026-12905 y clasificado con severidad media por el National Vulnerability Database, reside en un único método de la API móvil que olvidó verificar a quién pertenece cada cita antes de entregarla.
La exposición no requiere privilegios de administrador ni exploits complejos: basta con que un empleado autenticado en la aplicación móvil de Bookly modifique el parámetro de ID de cita en su solicitud y enumere valores secuenciales para acceder a registros que no le corresponden. Cada respuesta exitosa devuelve el paquete completo de datos del cliente — nombre, email, teléfono, notas internas del negocio, campos personalizados, extras contratados, monto total, método de pago y estado de cobro — junto con las anotaciones privadas que otros staff members hayan dejado sobre esa cita.
## Cómo un control presente en tres operaciones desapareció en la cuarta
El código vulnerable vive en el archivo Handler1_0.php del módulo Mobile Staff Cabinet, específicamente en el método appointment() que responde a consultas individuales de citas desde la app móvil. Investigadores que analizaron el CVE identificaron que el handler carga directamente el objeto Appointment usando el ID que llega en params[id], sin cruzar el campo staff_id de esa cita contra el identificador del empleado autenticado ($this->staff->getId()).
Lo notable del caso es que tres operaciones hermanas en el mismo handler — deleteAppointment, saveAppointment y el listado general de citas — sí implementan correctamente ese filtro de scope cuando el rol del usuario es ROLE_STAFF. La inconsistencia sugiere que el método de lectura individual se escribió en un momento distinto o por otra mano, sin replicar el patrón de seguridad ya establecido en el resto del código. El resultado es una Insecure Direct Object Reference (IDOR) clásica: el sistema confía en que el cliente solo pedirá IDs legítimos, pero no lo verifica.
## Qué datos quedan expuestos y por qué importan
La carga útil de cada cita incluye información que en contextos de salud, estética o servicios personales puede ser sensible por partida doble. Por un lado están los datos de contacto del cliente — nombre completo, email, teléfono — que en manos equivocadas habilitan phishing dirigido o reventa de bases. Por otro, las notas internas que el negocio registra sobre preferencias, historial de pagos o incidencias previas, material que ningún empleado debería ver fuera de las citas que él mismo gestiona.
Campos personalizados y extras contratados pueden revelar desde alergias a productos hasta servicios de nicho que el cliente prefiere mantener discretos. El detalle de pago — monto, método, estado de cobro — completa un perfil comercial que en negocios con alta rotación de personal se vuelve un activo de inteligencia competitiva si un empleado decide migrar a otro local llevándose la cartera de clientes mejor documentada.
## Exposición en salones y clínicas de Argentina, México y Colombia
Bookly es uno de los plugins de reservas más instalados en WordPress para el segmento de servicios personales, con presencia documentada en miles de sitios de habla hispana. En Argentina, México y Colombia — donde la adopción de WordPress en pequeños negocios de estética y salud es alta — la combinación de rotación de personal y acceso móvil generalizado multiplica el riesgo: cada empleado con la app instalada y credenciales activas puede, sin dejar rastro evidente en logs de administración, extraer la base completa de clientes del negocio enumerando IDs durante una jornada laboral.
La vulnerabilidad no deja registro de acceso anómalo porque técnicamente el empleado está autenticado y consultando un endpoint legítimo de la API — solo que con parámetros que debieron rechazarse. Para un dueño de salón o consultorio sin monitoreo granular de API, la fuga puede pasar inadvertida hasta que un exempleado lance un negocio competidor con la misma cartera de clientes, contactados uno por uno con ofertas personalizadas que solo podían conocerse desde adentro.
## Nuestro análisis
CVE-2026-12905 es un recordatorio de que las vulnerabilidades más explotables no siempre son las más complejas. La falla no involucra inyección SQL, deserialización remota ni cadenas de gadgets — es simplemente un if que falta, una validación que tres métodos hermanos implementan pero el cuarto omite. Ese patrón de inconsistencia interna es frecuente en plugins que crecen por iteración: cada nueva feature replica parcialmente la lógica de seguridad de las anteriores, pero sin un marco de validación centralizado, las omisiones se cuelan.
El hecho de que la severidad oficial sea MEDIUM no debe interpretarse como baja prioridad en contextos reales. La clasificación técnica pondera que se requiere autenticación previa, pero en negocios donde cada empleado tiene credenciales de staff por diseño — peluqueros, masajistas, recepcionistas — el perímetro de confianza es amplio y la rotación alta. Un atacante no necesita comprometer al administrador; le alcanza con ser contratado, obtener su token de acceso legítimo y ejecutar el scraping antes de renunciar. ¿Cuántos dueños de salones en LATAM actualizan plugins de WordPress con la misma velocidad con que rotan empleados?
—
Nota del editor: Este artículo fue generado por IA y revisado por el equipo editorial de CiberseguridadLatam siguiendo el estándar CES-1.0. Los hechos presentados provienen exclusivamente de fuentes verificables citadas. Fecha de publicación: 2026-08-18.