Bookly CVE-2026-92799

No special conditions beyond a reachable installation: unauthenticated network exploitation works against default configurations of the Bookly WordPress plugin (versions up to and including 28.2), because the booking AJAX controller registers every method as a wp_ajax_nopriv_ handler and unconditionally forces csrfTokenValid() to return true. The only functional prerequisite is that a target Bookly customer record already exists (the attack overwrites an existing record), and that the front-end booking flow reaches the verification step. Exploitation is limited only by the plugin being installed and active and by the attacker knowing/enumerating a valid customer to target; the type-juggling bypass specifically requires using the json_data input channel (json_decode preserving the PHP boolean true) so that wp_kses leaves the non-string value intact.

This is a genuine but moderate-severity issue whose real-world risk is well-captured by the CVSS 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) rather than being an inflated high-CVSS case. The exploit is trivially simple (network, low complexity, no auth, no user interaction - submit the JSON boolean true as verification_code), which makes it attractive for automation, but the technical impact is bounded: an attacker can overwrite the name/email/phone/address of existing Bookly customer records and hijack their booking notifications, so the impact is integrity-limited (I:L) with no direct system compromise (C:N/I not high/A:N per NVD). I mildly dispute C:N: redirecting a victim's booking notifications to attacker-controlled contacts leaks that customer's future appointment details, arguably C:L. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active exploitation - the risk is potential, not observed. The Wordfence-attributed research and a confirmed WordPress.org trac patch (changeset 3707284, versions after 28.2) are the strongest confirmed signals; the low-complexity unauthenticated vector on a popular booking plugin makes patching worthwhile but this is not an emergency-tier RCE.

An unauthenticated attacker sends a crafted AJAX request to the public wp_ajax_nopriv Bookly booking endpoint, supplying verification_code as the JSON boolean true through the json_data channel, which bypasses the loose (!=) comparison against the session's random integer code. Having defeated the phone/email ownership check, the attacker rewrites a targeted customer's name, email, phone, and address so all future booking notifications flow to attacker-controlled contacts. No public exploit code was identified at the time of analysis, but the type-juggling technique is documented in detail in the Wordfence advisory.