VikBooking CVE-2026-6820

Exploitation requires that the target run VikBooking 1.8.8 or earlier and expose the booking/submission workflow that accepts the 'email' parameter to untrusted users - the default deployment for a public hotel booking site. No authentication is required (PR:N), and the attacker needs only to reach the network-accessible submission endpoint. The key limiting factor is that the stored payload is inert until a subsequent victim - typically a staff member or administrator viewing the booking record - loads the page containing the unescaped value; impact is therefore gated on someone with a valuable session opening the injected content, and is confined to browser-context effects rather than direct server compromise.

The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N, base 7.2 High) reflects a network-reachable, low-complexity, unauthenticated injection with a scope change - consistent with stored XSS whose payload crosses from the attacker into a victim's authenticated browser session. No EPSS score, KEV entry, POC, or SSVC decision data was provided, so quantitative exploitation-probability signals are absent; risk must be judged from the vector and description alone. The realistic impact is meaningful but bounded: stored XSS in an admin-facing booking console can lead to session/cookie theft and forged privileged actions, yet it does not by itself yield direct code execution or data-store compromise (C:L/I:L, A:N). One nuance to verify: the vector lists UI:N, but a stored XSS payload only fires when a victim later views the injected page, which is arguably a passive user interaction - treat the 'no interaction' framing cautiously when prioritizing. Overall this is a genuine but moderate-priority issue: high likelihood of exploitability given unauthenticated access, capped severity because impact is confidentiality/integrity-limited and browser-scoped.

An unauthenticated attacker submits a booking or contact interaction to a VikBooking-powered site, placing a script payload (e.g., a cookie-exfiltration or admin-action snippet) into the 'email' field. The value is stored and later rendered without escaping when hotel staff open the corresponding record in the WordPress admin, executing the attacker's JavaScript in the administrator's authenticated session. No public exploit has been identified at time of analysis, but the low attack complexity and lack of authentication make weaponization straightforward.