VikBooking PMS EUVD-2026-96223

Requires the VikBooking chat/messaging feature (the chat controller and attachment handling referenced at controllers/chat.php and resources/chat.js) to be enabled and reachable so the attacker can submit the 'attachments[name]' value; affected versions are all releases up to and including 1.8.15. Per PR:N the injection itself needs no authentication, but realistic impact depends on a victim subsequently viewing the injected page (commonly a hotel operator/admin reviewing chat attachments), making victim page-access the practical trigger; sites not exposing the chat feature to untrusted users have materially lower exposure.

This is a stored XSS (CWE-79) in the VikBooking WordPress plugin reported by Wordfence, scored CVSS 7.2 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N). The vector signals favorable attacker conditions: network-reachable, low complexity, no privileges, and no user interaction required to inject, with a changed scope (S:C) reflecting that the payload executes in a separate victim's browser context. However, impact is bounded (C:L/I:L/A:N) - typical of XSS rather than direct server compromise. No EPSS score, no CISA KEV listing, and no public exploit code were provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The reference set points to the plugin's chat controller and chat.js (the 'attachments[name]' handling), and a 1.8.16 reference suggests a fix exists. Net: a legitimate, fix-available moderate-severity priority for sites running the affected plugin, not a mass-exploited emergency. Note a tension worth verifying: the description and CVSS claim unauthenticated (PR:N) injection via a chat attachment feature, which implies the public/front-end chat feature must be enabled and reachable - if that feature is admin-only in a given deployment, real-world exposure is lower than the raw vector implies.

An unauthenticated attacker interacts with the plugin's front-end chat feature and supplies a malicious value in the 'attachments[name]' parameter containing a script payload. Because the input is stored without sufficient sanitization and rendered without output escaping, the script executes when a victim (e.g., a hotel operator reviewing chat/attachments in the dashboard, or another user viewing the injected page) later loads that page. No public exploit code was identified at time of analysis, but AV:N/AC:L/PR:N/UI:N make the injection step trivial to automate.