WP Booking System EUVD-2026-100886

Exploitation requires that the plugin store an attacker-supplied, client-controllable request value (submitted via a public-facing WP Booking System form) and then that a logged-in administrator subsequently view the administration screen rendering that stored data - the UI:R dependency. No authentication is needed to inject the payload (PR:N), and no special non-default configuration is indicated; any site running WP Booking System before 2.1.0.1 is affected. The principal limiting factor is the required administrator interaction (the payload lies dormant until an admin views the data), which is why CISA SSVC rates it Automatable=no; it is not self-propagating and cannot compromise anything without an admin viewing the injected content.

Multiple signals must be weighed carefully. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R) describes a network-reachable, low-complexity, unauthenticated flaw, and the 8.8 score is driven largely by C:H/I:H/A:H - impact metrics that are generous for a stored XSS and reflect worst-case admin-account takeover rather than guaranteed total system compromise. The exploitation signals, however, temper the raw severity: EPSS is only 0.22% (12th percentile), CISA SSVC lists Exploitation as 'none' and Automatable 'no' (consistent with the required admin-viewing step), and the CVE is NOT in CISA KEV - so there is no public evidence of active exploitation. Against that, a public exploit exists (WPScan) and a vendor patch is available. The signals are therefore internally consistent rather than conflicting: a genuinely exploitable, publicly-documented unauthenticated stored XSS, but one that is not automatable and not yet exploited in the wild. Net: a real patch-now priority for sites running the affected plugin because unauthenticated injection plus admin-session execution is a classic WordPress takeover path, but not an emergency mass-exploitation event. Note the CVSS Automatable=no and UI:R dependency (an administrator must view the malicious data) are the key factors keeping real-world risk below what the 8.8 alone implies.

An unauthenticated attacker submits a crafted booking/form request containing a malicious script payload in a client-controllable field, which the plugin stores without sanitisation. When a site administrator later opens the WP Booking System admin screen that renders this data, the script executes in their authenticated session - enabling actions such as creating a rogue administrator account or planting a backdoor. A public exploit is available via WPScan, and no user authentication is required to plant the payload (only an admin view is needed to trigger it).