Hydra Booking CVE-2026-57388

Exploitation requires that the attacker can get input persisted through a Hydra Booking form/field that is later rendered without output encoding, and - per UI:R in the CVSS vector - it requires a victim (typically a logged-in administrator or staff member) to view the page containing the stored payload before the script fires; the payload does not self-trigger. The scope change (S:C) reflects that the injected script runs in the viewer's security context rather than the attacker's. Limiting factors: success depends on an administrator actually opening the affected booking/admin view, and on the plugin being installed with its booking submission path reachable by the attacker; if submission requires an account, a low-privilege user would be needed despite the PR:N rating, which should be confirmed against the deployment.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L, 7.1 High) indicates a network-reachable, low-complexity issue that needs no privileges but does require user interaction, with a scope change reflecting that injected script executes in a different security context (the viewing user's authenticated session). No EPSS score was provided in the input, so exploitation probability cannot be quantified here. This is not a CISA KEV entry and no proof-of-concept was referenced, so there is no public exploit identified at time of analysis. Realistically this is a moderate-priority issue: stored XSS in a booking plugin can be triggered by simply awaiting an administrator's routine review of submitted bookings, but it is not the drop-everything class of unauthenticated RCE. One tension worth verifying: PR:N implies an unauthenticated actor can plant the payload, which is credible for a public booking form but should be confirmed against the plugin's actual submission flow, since many WordPress stored-XSS issues instead require a low-privilege (contributor) account.

An attacker submits a booking or form entry containing a crafted JavaScript payload in a field that Hydra Booking stores without sanitizing. When a site administrator later opens the bookings view in wp-admin, the stored script executes in their authenticated session, allowing cookie/session theft or actions performed in the admin context. No public proof-of-concept is referenced, and the attack depends on a victim rendering the poisoned page (UI:R).