Bookly EUVD-2026-86621

Requires a running Bookly plugin instance at a version before 28.3, and the attacker must already possess a valid customer's primary identifier (the value used to look up the customer record) - the exploit targets a specific known customer rather than working blindly. No authentication and no user interaction are needed (PR:N/UI:N), and it works against default configurations. The identifier requirement is the primary limiting factor, restricting this to targeted rather than mass, automated exploitation.

This is a genuine but moderate-severity issue, not a top-tier priority. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N = 5.3) reflects an unauthenticated network-reachable integrity-only flaw: no confidentiality or availability impact, only low integrity (I:L) from overwriting stored customer records. A public exploit exists (WPScan), which raises practical risk, but there is no EPSS score and no CISA KEV listing in the provided data, so there is no evidence of active or widespread exploitation. A critical limiting factor NOT captured in AC:L is that the attacker must already KNOW the target customer's primary identifier - this makes the attack per-target rather than identifier-blind mass exploitation, meaningfully lowering real-world scalability. Note also that the input Tag 'Information Disclosure' conflicts with the actual impact: this is data tampering/overwrite (I:L, C:N), not disclosure - treat the tag as mislabeled.

An attacker who has obtained a Bookly customer's primary identifier (e.g., from a prior booking, leaked list, or social engineering) sends an unauthenticated request to the plugin's customer-update endpoint. Because the plugin does not verify the requester's identity before writing, the attacker overwrites that customer's stored name, email, and address - potentially redirecting booking notifications. Public exploit details are available via WPScan, lowering the skill barrier.