CVE-2026-93399 in Bookly Plugin
Summary
by MITRE • 09/25/2026
The Bookly plugin for WordPress is vulnerable to Insecure Direct Object Reference in versions up to, and including, 28.2 via the 'bookly_get_form_id', 'bookly_render_complete', 'bookly_add_to_calendar' and 'bookly_rollback_order' AJAX actions. This is due to the 'bookly_get_form_id' handler blindly storing the attacker-controlled 'order_id' from the submitted form_data into a new booking session, which the 'bookly_render_complete' handler then trusts to look up and return the corresponding Order's secret token without verifying that the current session created that order. This makes it possible for unauthenticated attackers to enumerate sequential order IDs, disclose other customers' order tokens, retrieve calendar/appointment information via 'bookly_add_to_calendar' and permanently delete arbitrary non-completed bookings via 'bookly_rollback_order', which cascade-deletes the customer_appointment and (when no other customers are attached) the underlying appointment.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified in Bookly versions up to 28.2 represents a critical failure in access control mechanisms, specifically classified as an Insecure Direct Object Reference or Broken Access Control. This flaw affects multiple AJAX endpoints including bookly_get_form_id, bookly_render_complete, bookly_add_to_calendar, and bookly_rollback_order. The core issue stems from the application's inability to properly associate user sessions with specific data objects, allowing unauthenticated actors to manipulate stateful operations that should be restricted to authorized users or valid session contexts.
The technical root cause lies in how the plugin handles order identification during the booking workflow. When a request is made via the bookly_get_form_id action, the system blindly accepts an attacker-controlled order ID from the submitted form data and stores it directly into a new booking session without any validation checks. This creates a situation where the application state becomes decoupled from the actual user identity or previous legitimate interactions. The subsequent handler, bookly_render_complete, then trusts this stored value to look up and return the corresponding Order's secret token. Crucially, there is no verification step to ensure that the current session actually created or owns that specific order ID. This lack of binding between the session context and the resource identifier allows an attacker to inject arbitrary identifiers into their requests.
The operational impact of this vulnerability is severe due to its unauthenticated nature and broad scope of exploitation. Attackers can perform sequential enumeration of order IDs, effectively mapping out the database structure and identifying valid targets within the system. Once a target order ID is identified, the attacker can retrieve sensitive information such as secret tokens associated with those orders. Furthermore, the vulnerability extends beyond mere data disclosure into active manipulation of business logic. Through the bookly_add_to_calendar endpoint, attackers can retrieve detailed calendar and appointment information belonging to other customers, leading to privacy violations and potential social engineering opportunities based on scheduled availability.
The most damaging aspect of this flaw is the ability to permanently delete arbitrary non-completed bookings via the bookly_rollback_order action. Because the system does not verify ownership or session validity before processing rollback requests, an attacker can target any booking ID they discover through enumeration. Executing a rollback operation cascades into the deletion of associated customer appointment records and, if no other customers are attached to that specific time slot, results in the permanent removal of the underlying appointment itself. This constitutes a significant denial-of-service condition for legitimate business operations and disrupts scheduling integrity without requiring any form of authentication or privilege escalation.
From a classification perspective, this vulnerability aligns with CWE-284: Improper Access Control, as it involves failing to enforce proper restrictions on authorized users accessing specific data objects. It also maps closely to the ATT&CK technique T1078: Valid Accounts if exploitation were possible via authenticated means, but since it is unauthenticated, it falls under general unauthorized access patterns often seen in CWE-639: Authorization Bypass Through User-Controlled Key. The sequential enumeration aspect relates to information disclosure vulnerabilities where internal identifiers are predictable and exposed through improper validation logic.
Mitigation strategies must focus on implementing robust authorization checks at every stage of the booking lifecycle. Developers should ensure that all AJAX handlers verify that the requesting user session has explicit ownership or administrative rights over the specific order ID being accessed or modified. Implementing server-side validation to confirm that an order was created within the current session context is essential before returning sensitive tokens or performing destructive actions like rollback operations. Additionally, replacing sequential integer-based identifiers with unpredictable unique identifiers can mitigate enumeration attacks by making it significantly harder for attackers to discover valid target IDs without prior knowledge of existing records.