Booking Calendar EUVD-2026-94765

Exploitation requires that the attacker can determine or tightly bound the creation time of a specific target booking, because each per-booking access hash is derived from a low-entropy, time-seeded value; knowing the seed window makes the hash predictable. No authentication is required (PR:N) and no victim interaction is needed (UI:N), but the attack is inherently per-booking and targeted rather than broad - the practical limiting factors are the need to identify a victim booking, estimate its creation timestamp, and run the vulnerable Booking Calendar plugin at a version earlier than 11.8. This is not a default-configuration mass-exploitation flaw; its reach is constrained to bookings whose timing an attacker can approximate.

This is a genuinely moderate-risk issue that correctly sits in the low-to-mid CVSS band rather than being an overstated 'critical'. The CVSS vector (AV:N/AC:H/PR:N/UI:N) confirms a network-reachable, unauthenticated flaw, but the High attack complexity is the decisive limiter: exploitation requires the attacker to first determine or closely estimate a specific booking's creation time in order to reconstruct the low-entropy, time-seeded hash. Impact is bounded (C:L/I:L, A:N) - disclosure or modification of a single targeted booking's data, not server compromise or mass data exfiltration. No EPSS score, KEV listing, or POC was provided in the input, so there is no active-exploitation or exploit-probability signal to weigh; absence of these is not evidence of safety but does argue against widespread automated exploitation. The signals are internally consistent - no contradictions between the CVSS vector and the description. Realistically this is a targeted, per-booking privacy/integrity issue (e.g. an attacker who knows roughly when a victim booked) rather than a wormable or opportunistically scannable vulnerability, so patch prioritization should be driven by whether the site handles sensitive personal booking data under privacy regulation.

An attacker who knows approximately when a victim submitted a booking (e.g. from an email timestamp, a confirmation page, or social engineering) brute-forces the narrow range of time-seeded values to regenerate the per-booking access hash. Using the predicted hash, they open the booking-management link to read the victim's personal data or alter the reservation. No public exploit code was identified in the provided data, and the High attack complexity reflects the need to constrain the creation-time window.