Description

The Online Scheduling and Appointment Booking System – Bookly plugin for WordPress is vulnerable to Authorization Bypass via PHP Type Juggling in all versions up to, and including, 28.2. This is due to the `postValidateCustomer()` function using a loose PHP inequality operator (`!=`) to compare the session-stored one-time verification code against the attacker-supplied `verification_code` parameter — a flaw that is further exposed by the booking AJAX controller registering all its methods as `wp_ajax_nopriv_` handlers and unconditionally overriding `csrfTokenValid()` to return true, leaving the endpoint both unauthenticated and CSRF-unprotected. This makes it possible for unauthenticated attackers to bypass the phone/email ownership verification step and overwrite the name, email, phone, and address fields of any arbitrary existing Bookly customer record, redirecting that customer's booking notifications to attacker-controlled contact details. The bypass is achievable because the `json_data` input channel decodes input via `json_decode()`, which preserves real PHP types and causes the `wp_kses` filter to leave non-string values such as the JSON boolean `true` untouched; submitting `true` as the `verification_code` satisfies the loose comparison against the session's non-zero integer code (generated by `mt_rand(100000, 999999)`), causing `true != <non-zero int>` to evaluate as `false` and the guard to be bypassed.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-25T07:16:55.607Z",
  "pubdate": "2026-09-25T07:16:55.607Z",
  "executiveSummary": "The Bookly plugin for WordPress (all versions up to and including 28.2) contains a critical authorization bypass vulnerability stemming from improper input validation and insecure session verification logic.\nThe flaw allows unauthenticated remote attackers to bypass critical identity verification checks during the booking process.\nBy leveraging a PHP type juggling vulnerability, an attacker can manipulate the verification mechanism to falsely validate ownership of arbitrary customer records.\nSuccessful exploitation results in the ability to modify sensitive customer information, including names, email addresses, phone numbers, and physical addresses.\nThis vulnerability is particularly severe as the affected AJAX controller lacks CSRF protection and treats unauthenticated requests as authorized, effectively removing the barrier to account takeover and data exfiltration.\nThe impact is significant, as attackers can redirect booking notifications and compromise customer data integrity, posing a high risk to both the platform administrator and end-users.",
  "technicalDetails": "The vulnerability resides in the `postValidateCustomer()` function within the Bookly booking system. The application utilizes a loose inequality operator ('!=') to compare a stored verification code (generated via mt_rand(100000, 999999)) against an attacker-supplied verification_code parameter.\nThe exploitation path is enabled by the booking AJAX controller, which registers its methods as wp_ajax_nopriv_ handlers. Furthermore, the controller unconditionally forces the csrfTokenValid() function to return true, rendering the entire endpoint both unauthenticated and entirely devoid of CSRF protection.\nThe root cause is a PHP type juggling flaw occurring during the validation process. The system accepts input through the json_data channel, which is processed using json_decode(). Because json_decode() preserves native PHP types, attackers can supply a JSON boolean 'true' rather than an integer string.\nIn PHP, when comparing the boolean 'true' against a non-zero integer (the session-stored verification code) using the loose inequality operator '!=', the expression 'true != <non-zero int>' evaluates to false. This satisfies the conditional check, effectively bypassing the security guard intended to verify the user's identity.\nBecause the wp_kses filter does not alter non-string types such as the boolean 'true', the malicious payload remains intact throughout the input sanitization phase.\nThe attack flow proceeds as follows: 1) The attacker initiates a request to the unauthenticated AJAX endpoint. 2) The attacker submits a crafted JSON payload containing the victim's identifier and the boolean value 'true' for the verification_code parameter. 3) The application's type-juggling flaw allows the validation logic to incorrectly equate the boolean to the session-stored code. 4) Once validation is bypassed, the application grants unauthorized access to modify the customer record.\nPost-exploitation, the attacker can overwrite the victim's contact information (email, phone, address). This permits the redirection of confirmation emails and future booking communications, facilitating downstream social engineering or full account compromise."
}