Answer in brief
CVE-2026-92619 records a High severity (CVSS 7.2) vulnerability in Booking Calendar <= 11.8.2 - Authenticated (Editor+) Privilege Escalation to 'data_name' Parameter. The current sources do not mark it as known exploited. The current feed maps wpdevelop/Booking Calendar (generic), wpdevelop/Booking Calendar (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.2. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps wpdevelop/Booking Calendar (generic), wpdevelop/Booking Calendar (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| wpdevelop/Booking Calendargeneric | >=0 <=11.8.2 | Not reported |
| wpdevelop/Booking Calendargeneric | 0 | Not reported |
Published upstream
Sep 18, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 18, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 18, 2026
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`.
Quoted source text, attributed separately from HOL analysis.