Bookly EUVD-2026-59927

The Bookly plugin must be installed and active on the target WordPress site running version 27.7 or earlier. The bookly_speed_up_update_addons AJAX action is registered under wp_ajax_nopriv_* and is therefore accessible to unauthenticated users at the standard WordPress AJAX endpoint wp-admin/admin-ajax.php - no account, session cookie, nonce, or API key is required for the injection step. The specific trigger for the unsanitized log-write path is submitting a request without a valid signature, which causes lib/PluginsUpdater.php to enter its error-handling branch and store attacker-supplied request details directly in bookly_log.details. Payload execution requires a WordPress user with administrator-level access to subsequently navigate to the Diagnostics → Logs page in the WordPress backend; this is a natural administrative action and cannot be triggered remotely by the attacker but is a predictable behavior on active installations. The key limiting factor is this indirect execution dependency - the attacker cannot control when or whether an administrator views the logs page, introducing delay but not meaningful prevention.

The CVSS 3.1 base score of 7.2 is driven by a network-accessible, low-complexity, unauthenticated vector with changed scope - metrics that accurately characterize the injection phase. However, the provided vector specifies UI:N, which is inconsistent with the actual execution trigger: the stored payload only fires when an administrator visits the Diagnostics → Logs page, constituting user interaction on the victim's side; an independent assessment using UI:R is more accurate and is reflected in the assessed vector below. The scope change (S:C) is correctly applied because execution crosses from the plugin's database storage context into the privileged administrator browser session. No EPSS score was included in available data, and this CVE is not listed in the CISA KEV catalog, suggesting no observed widespread exploitation to date; that said, even a mid-sized municipal IT team in leszno running a public-facing WordPress booking portal should treat this as urgent given the entirely unauthenticated injection step and the administrative privilege context of payload execution. The attack is highly automatable - a single crafted HTTP POST is sufficient to pre-position a payload - and stored persistence means one request can target all future administrator sessions, not just one. The primary factor limiting immediate impact is that execution depends on an administrator navigating to the specific Diagnostics Logs page, which cannot be forced by an external attacker but is likely to occur organically on active installations.

An unauthenticated attacker submits a single crafted HTTP POST request to wp-admin/admin-ajax.php with action=bookly_speed_up_update_addons and an absent or invalid signature, embedding a JavaScript payload in the request body; the plugin's signature-validation failure path in lib/PluginsUpdater.php writes the raw, unsanitized input to the bookly_log.details database column. The next time a WordPress administrator opens the Diagnostics → Logs page in the backend - a routine action during troubleshooting or plugin management - the stored script executes in their browser context, enabling session cookie exfiltration, creation of rogue administrator accounts, or silent redirection to attacker-controlled infrastructure. No confirmed public proof-of-concept code exists at time of analysis, though the attack requires only a single HTTP request and knowledge of the AJAX action name, both of which are derivable from the publicly available plugin source code in the WordPress SVN repository.