Description

The Online Scheduling and Appointment Booking System WordPress plugin before 28.3 does not verify that appointment and payment records requested through its staff-role AJAX actions belong to the requesting staff member, allowing authenticated attackers with a staff-level account to view, modify and delete other staff members' appointments and payments, including the associated customer's personal information.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.8",
  "pubDate": "2026-09-27T06:17:14.180Z",
  "pubdate": "2026-09-27T06:17:14.180Z",
  "executiveSummary": "The Online Scheduling and Appointment Booking System WordPress plugin contains an Insecure Direct Object Reference (IDOR) vulnerability due to insufficient authorization checks within its AJAX handlers.\nThis vulnerability allows authenticated users with a staff-level role to bypass access control boundaries, enabling unauthorized retrieval, modification, and deletion of sensitive records belonging to other staff members.\nThe scope of the impact includes the compromise of customer personal information (PII), payment record manipulation, and appointment scheduling disruption.\nThe vulnerability affects all versions of the Online Scheduling and Appointment Booking System plugin prior to 28.3.\nSuccessful exploitation requires an attacker to possess a valid staff-level account, which provides the necessary context to interact with the vulnerable AJAX actions.\nThe risk is critical for multi-user environments where staff segmentation is expected, as it allows for lateral movement across data records that should be cryptographically or logically isolated by user ownership constraints.",
  "technicalDetails": "The vulnerability originates from a critical failure in the server-side authorization logic within the plugin's AJAX request handling mechanism. Specifically, the affected staff-role AJAX actions fail to validate the relationship between the authenticated session's user ID and the record ID requested in the input parameters.\nThe root cause is a lack of object-level authorization checks. When a staff user sends an AJAX request to perform CRUD operations on appointments or payments, the plugin backend processes the request based solely on the user's role authentication status, rather than verifying ownership of the requested object ID.\nExploitation is conducted by intercepting or crafting requests sent to the vulnerable backend endpoints. An attacker authenticated as a staff member can manipulate input parameters—such as 'appointment_id' or 'payment_id'—to target resources belonging to other users or the enterprise at large.\nThe attack flow follows these steps: 1. The attacker authenticates as a legitimate staff member. 2. The attacker identifies the AJAX endpoint responsible for fetching or modifying records. 3. The attacker submits a crafted HTTP request with an identifier belonging to a record they do not own. 4. The server receives the request, confirms the attacker is a 'staff' member, but fails to check if the attacker has authority over the specific resource identifier provided. 5. The server executes the request, returning sensitive customer data or performing unauthorized modifications on the target record.\nThis design flaw effectively turns the staff role into an unrestricted interface for interacting with the entire database of appointments and payment records. Post-exploitation impact includes the mass exfiltration of customer data, potentially violating data privacy regulations, and the capability to disrupt business operations by deleting or altering schedule data across the entire platform.\nBecause the plugin does not enforce a 'Secure by Design' architecture regarding data isolation, the application layer remains susceptible to this IDOR regardless of other security measures unless server-side object ownership verification is implemented for all administrative and staff-level API endpoints."
}