WpBookingly CVE-2026-66687

The attacker must be able to reach and submit a booking request through the WpBookingly intake form; the PR:L CVSS metric suggests this requires at minimum a low-privileged account, though the exact privilege level (registered WordPress subscriber vs. anonymous booking submission) is not explicitly stated in the available data and should be confirmed from the vendor advisory. A victim administrator or privileged WordPress user must actively open the booking management view in the WordPress dashboard (UI:R) for the payload to fire - passive exploitation without this interaction is not possible. Sites that gate the booking form behind authentication reduce the external attacker pool significantly. Exploitation is limited to WordPress installations running WpBookingly version 1.3.2 or earlier; the A:L availability metric in the reporter-assigned vector is atypical and the specific condition producing availability impact is not confirmed from available data.

The CVSS 3.1 base score of 6.5 (Medium) reflects network-accessible exploitation (AV:N), low attack complexity (AC:L), low-privilege submission (PR:L), mandatory victim interaction (UI:R), and a scope change (S:C) to the administrator browser context. The scope change is the most operationally significant metric: it means a customer-level attacker can pivot to admin-level access, elevating the practical impact beyond what the Medium score alone suggests. No EPSS data was included in the provided intelligence; the absence of both a KEV listing and confirmed POC code means real-world exploitation probability is currently speculative. The UI:R requirement is a meaningful limiting factor - exploitation is contingent on an administrator actively reviewing the poisoned booking record. The A:L (availability) metric in the reporter-assigned vector is atypical for XSS and is not independently supported by the description; this metric should be verified against the full Patchstack advisory. For sites with open public booking forms, the attack surface is broad and the exploit pattern is well-understood, making timely patching the appropriate response.

An unauthenticated or low-privileged external user navigates to a site's public WpBookingly booking form and submits a reservation with a malicious JavaScript payload embedded in the customer name or notes field, such as an image tag with an onerror handler pointing to an attacker-controlled server. When the site administrator opens the WordPress booking management dashboard to review pending reservations, the stored payload executes silently in the admin's browser, exfiltrating the session cookie to the attacker and granting full administrative control over the WordPress installation. No public exploit code has been confirmed at time of analysis, but the attack pattern is elementary and well-documented for stored XSS in WordPress plugin booking fields.