CVE-2026-92619: Booking Calendar (WordPress plugin) · Improper Privilege Management
Affects Booking Calendar (WordPress plugin)Source CVE Database V5
Not known to be exploited · CVSS 7.2 High.
Data as of 2 Nov 2026, 22:58 UTC
- EPSS
- 0.6% chance of exploitation in 30 days – higher than 51% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 18 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2 Nov 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| wpdevelopBooking Calendar | Affected
| Fixed in– |
AI-suggested
Until an official fix is available, restrict Editor-level access and above to trusted users only. Monitor for suspicious activity related to option changes and user registrations. Avoid exposing the AJAX action to untrusted users. Follow vendor updates closely for patches addressing this issue.
Description
The Booking Calendar plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 11.8.2 via the `wpbc_ajax_option_save` AJAX action. The vulnerability exists because the `handle_ajax_save()` function applies per-option safeguards only to names explicitly registered via `register_option_policy()`, causing `get_option_policy()` to return an empty policy — bypassing all can_save, force_mode, and allowed_keys checks — for any unregistered option name, including core WordPress options, while an attacker-controlled `data_name` parameter passes through `sanitize_key()` and is written directly to `update_option()` without restriction. This makes it possible for authenticated attackers with Editor-level access and above to escalate their privileges to Administrator by writing core WordPress options such as `default_role=administrator` and `users_can_register=1`, then self-registering a new Administrator account. The nonce check does not meaningfully restrict this attack, as both the nonce value and nonce action are attacker-supplied POST parameters, and a valid nonce is trivially obtainable via `admin-ajax.php?action=rest-nonce`.
References
- wordfence.com/threat-intel/vulnerabilities/id/ab68a6b2-e9b0-4efa-bd01-c6e3e11011db?source=cve (opens in a new tab)
- plugins.trac.wordpress.org/browser/booking/tags/11.8.2/includes/save-load-option/save-load-option.php (opens in a new tab)
- plugins.trac.wordpress.org/browser/booking/tags/11.8.2/includes/save-load-option/save-load-option.php (opens in a new tab)
- plugins.trac.wordpress.org/browser/booking/tags/11.8.2/includes/save-load-option/save-load-option.php (opens in a new tab)
- plugins.trac.wordpress.org/browser/booking/tags/11.8.2/includes/page-form-builder/ajax/bfb-ajax.php (opens in a new tab)
- plugins.trac.wordpress.org/changeset?reponame=&old=3699185%40booking&new=3699185%40booking (opens in a new tab)