Hydra Booking EUVD-2026-58861

Exploitation requires the target WordPress site to have the Hydra Booking plugin active at version ≤ 1.2.2 and the plugin's public Signup shortcode deployed on at least one publicly accessible page, enabling unauthenticated visitor self-registration as a tfhb_host. Without the Signup shortcode present on a public page, an attacker must possess a legitimately provisioned tfhb_host account (consistent with CVSS PR:L) or higher privilege to inject the payload. A victim must subsequently visit the host archive page rendering the injected first_name value for script execution to occur. Exploitation is therefore bounded by two factors: the presence of the public Signup shortcode determines whether the barrier is effectively zero (any site visitor) or low-privilege (existing host account required); and victim browsing of the archive page introduces a user-interaction dependency not fully captured by the official CVSS UI:N rating.

The CVSS 6.4 score (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) moderately understates practical risk because the PR:L requirement is effectively neutralized by the plugin's self-registration feature - even a mid-sized municipal IT team in gniezno should treat this as urgent if the Signup shortcode is publicly exposed, since any anonymous visitor can acquire host-level access and plant persistent payloads without further interaction. EPSS data is absent from available intelligence, so automated exploitation probability cannot be quantified independently. No active exploitation has been confirmed (no CISA KEV listing) and no standalone public exploit code has been identified, which reduces immediate mass-exploitation risk somewhat. The upstream fix commit (changeset 3632543) provides a clear remediation path, tempering urgency for sites that patch promptly or disable the Signup shortcode as an interim measure.

An attacker visits a WordPress site running Hydra Booking ≤ 1.2.2 with the public Signup shortcode active, completes the self-registration flow to obtain the tfhb_host role, and submits a crafted JavaScript payload (such as a session cookie exfiltration script) in the first_name field of their host profile. The payload is stored without sanitization and subsequently rendered unescaped on the host archive page, executing in the browser of any user - including administrators - who visits that page.