Bookly CVE-2026-96347

Requires an authenticated account at Subscriber level or higher on a WordPress site running the Bookly plugin version 28.2 or earlier - matching PR:L in the CVSS vector. Practical exploitation depends on the site allowing account registration (common where public booking/self-service registration is enabled); sites that restrict registration meaningfully limit the attacker pool. No user interaction is required (UI:N) and the flaw is remotely reachable over the network (AV:N). Impact is limited to integrity (unauthorized modification of other users' objects); there is no confidentiality or availability impact per the vector.

This is a genuine but moderate-priority issue. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N, base 6.5) indicates network-reachable, low-complexity exploitation requiring only low-privilege authentication (PR:L), no user interaction, and a pure high-integrity impact with no confidentiality or availability loss - consistent with an IDOR (CWE-639) where an attacker manipulates object identifiers to modify records belonging to other users. The PR:L is significant: exploitation requires a valid account, and the description explicitly scopes this to the 'Subscriber' role, which many WordPress sites grant via open registration - lowering the practical barrier. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active exploitation or ready-made exploit code; the risk is therefore latent rather than imminent. The C:N/I:H/A:N profile means the danger is unauthorized data modification (e.g., altering or tampering with other users' bookings/records), not data theft or denial of service. Overall this is a real, patchable authorization flaw worth remediating on booking-heavy sites, but it is not a drop-everything emergency absent exploitation signals.

An attacker registers or obtains a low-privilege Subscriber account on a WordPress site running Bookly <= 28.2, then sends requests that reference another user's object identifier (e.g., a booking or record ID) in a parameter the plugin fails to authorize. Because the plugin does not verify ownership, the attacker modifies data belonging to other customers. No public exploit code was identified at time of analysis, but the low complexity and low privilege requirement make manual exploitation straightforward.