WpBookingly EUVD-2026-31964

Exploitation requires a valid WordPress authenticated session with at minimum a low-privilege role (confirmed by CVSS PR:L - subscriber, customer, or equivalent). The WpBookingly plugin must be installed and active on the target site, running version 1.2.9 or earlier. The specific plugin feature, AJAX action, or REST endpoint containing the missing capability check is not disclosed in the available intelligence. Exploitation is categorically limited by the authentication requirement - unauthenticated remote attackers cannot exploit this flaw. Further limiting factors include the partial impact scope (integrity only, S:U, C:N, A:N), meaning the attacker cannot read sensitive data or cause availability disruption. Organizations where all authenticated WordPress users are trusted (e.g., private intranets, staff-only installations) face negligible realistic risk.

The CVSS 4.3 (Medium) score reflects a network-accessible, low-complexity attack requiring low privileges (PR:L), no user interaction, and producing only an integrity impact (I:L) with no confidentiality or availability consequence (C:N/A:N, S:U). EPSS at 0.03% (8th percentile) indicates this vulnerability is statistically unlikely to see mass exploitation. SSVC reinforces this: exploitation is rated none, automatable is no, and technical impact is partial - all pointing to a vulnerability that presents low immediate risk outside of environments where untrusted authenticated users exist. The tag 'Authentication Bypass' in the source data is potentially misleading: the CVSS PR:L vector confirms a valid authenticated session is still required, meaning this is privilege escalation within an authenticated context rather than full authentication bypass - these signals are in minor conflict and defenders should not treat it as an unauthenticated threat. No KEV listing and no public POC further reduce urgency. For multi-tenant WordPress environments (e.g., membership sites, booking portals) where low-privilege user accounts are granted to the public, risk is elevated relative to private installations.

An attacker registers or obtains a low-privilege WordPress account (such as a subscriber) on a site running WpBookingly ≤1.2.9, then sends a crafted HTTP request to the plugin's unprotected endpoint - bypassing the missing capability check - to modify booking records, settings, or other data reserved for administrators. No public proof-of-concept code has been identified, but broken access control vulnerabilities of this class are straightforward to discover via manual testing of plugin endpoints once authenticated.