Description

The Bookly plugin for WordPress is vulnerable to Insecure Direct Object Reference in versions up to, and including, 27.7 via the appointment() method of the Mobile Staff Cabinet API (resource=appointment, action=bookly_mobile_staff_cabinet) in frontend/modules/mobile_staff_cabinet/api/handlers/Handler1_0.php. This is due to the handler loading an Appointment by the attacker-supplied params[id] without verifying that the appointment's staff_id matches the authenticated staff member, whereas sibling operations (deleteAppointment, saveAppointment, appointments list) correctly scope to $this->staff->getId() when $this->role === ROLE_STAFF. This makes it possible for authenticated attackers, with staff-level mobile cabinet access (any valid access_key token bound to a Staff entity), to read appointment details — including the internal note and the full customer_appointments collection (customer full_name, email, phone, notes, custom_fields, extras, payment_total, payment_type, payment_status) — belonging to other staff members by enumerating sequential appointment IDs.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-16T05:16:45.947Z",
  "pubdate": "2026-08-16T05:16:45.947Z",
  "executiveSummary": "An Insecure Direct Object Reference (IDOR) vulnerability exists in the Bookly plugin for WordPress in versions up to, and including, 27.7.\nThe vulnerability resides within the appointment() method of the Mobile Staff Cabinet API located in frontend/modules/mobile_staff_cabinet/api/handlers/Handler1_0.php.\nThis flaw allows authenticated attackers with staff-level mobile cabinet access to read arbitrary appointment details belonging to other staff members.\nExposed data includes sensitive internal notes and comprehensive customer appointment collections such as full names, email addresses, phone numbers, custom fields, extras, payment totals, payment types, and payment statuses.\nThe risk implication is severe privacy leakage and unauthorized access to business operational data across distinct staff accounts.\nExploitation requires a valid access_key token bound to a Staff entity and the ability to systematically enumerate sequential appointment IDs via the resource=appointment and action=bookly_mobile_staff_cabinet parameters.",
  "technicalDetails": "The vulnerability stems from improper authorization checks and a lack of access controls within the Mobile Staff Cabinet API handler of the Bookly plugin.\nSpecifically, the vulnerable component is the appointment() method in frontend/modules/mobile_staff_cabinet/api/handlers/Handler1_0.php.\nThe root cause is that the handler loads an Appointment record directly using attacker-supplied parameters (params[id]) without verifying whether the target appointment's staff_id matches the identifier of the currently authenticated staff member.\nIn contrast, sibling operations within the same codebase—such as deleteAppointment, saveAppointment, and appointments list—correctly enforce scoping by verifying $this->staff->getId() when $this->role === ROLE_STAFF.\nTo execute an attack, an authenticated threat actor possessing staff-level mobile cabinet access (utilizing any valid access_key token bound to a Staff entity) crafts HTTP requests targeting the mobile cabinet API endpoint.\nThe attacker supplies sequential appointment ID values within the params[id] parameter while invoking the action=bookly_mobile_staff_cabinet and resource=appointment parameters.\nBecause the appointment() method fails to validate object ownership or organizational boundaries, the application processes the request and returns the appointment details.\nThe returned payload contains sensitive PII and financial metadata associated with the targeted customer and other staff members.\nPost-exploitation impact includes unauthorized data aggregation, harvesting of customer PII (full_name, email, phone), and exposure of internal operational notes and payment statuses across multiple staff accounts."
}