Booking Calendar CVE-2026-39601

Exploitation requires the attacker to reliably win a timing race against the plugin's booking/availability logic by issuing concurrent requests to the booking submission flow of Booking Calendar ≤11.8.4; no authentication or user interaction is needed (PR:N/UI:N). The primary limiting factor is the narrow race window (AC:H) - success is non-deterministic and generally demands many rapid parallel requests - and impact is confined to integrity of booking state (I:L), with no data disclosure or service outage per the scored vector. Realistic exploitation also presumes a publicly reachable booking form with concurrent submissions permitted.

This is a low-severity, low-real-world-priority issue despite being network-reachable. The CVSS 3.1 score of 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N) reflects a race condition that, while remotely reachable and unauthenticated (PR:N), carries high attack complexity (AC:H) because the attacker must reliably win a narrow timing window, and yields only a low integrity impact (I:L) with no confidentiality or availability impact. No EPSS score, SSVC decision, KEV listing, or POC was provided in the input, so there is no signal of active exploitation or ease of weaponization - the only source is a single Patchstack advisory. Note one inconsistency worth flagging: the Tags include 'Information Disclosure,' but the CVSS vector sets C:N (no confidentiality impact) and only I:L, so the tag conflicts with the scored impact - verify with Patchstack whether the race condition leaks data or only corrupts booking state. Overall this is a genuine-but-minor flaw, not an urgent priority; the high complexity and low integrity-only impact keep real-world risk low.

An unauthenticated attacker repeatedly submits concurrent booking requests against a WordPress site running Booking Calendar ≤11.8.4, racing the plugin's unsynchronized availability check to create conflicting or duplicate bookings for the same slot. Because the flaw requires reliably winning a narrow timing window (AC:H), success is probabilistic and typically requires many rapid parallel requests. No public exploit identified at time of analysis.