EUVD-2026-54154Severity by source
AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:N
PR:H confirmed by TENANT_ADMIN requirement; UI:R because patient click is mandatory; S:C because patient browser is a distinct security scope from the admin panel; C:H and I:H because unencrypted patient data is read and modifiable before encryption.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
4DescriptionCVE.org
OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.2, a TENANT_ADMIN can store javascript: URLs in the tenant links configuration (website, imprint, privacyStatement). These values are returned to the patient-facing landing page via /api/public, hydrated into the SvelteKit Button component, and rendered as <a href="javascript:..."> elements without URL-scheme filtering. A patient who clicks any such link executes the attacker's JavaScript inside the patient browser origin, where patient form data is read before client-side encryption is applied. This breaks the project's central trust claim that the server is an untrusted relay and that administrators cannot read patient data. Patient-side encryption happens after form input, so JavaScript executing in the patient origin can read or alter the plaintext before encryption is performed. Version 1.0.2 fixes the issue.
AnalysisAI
Stored cross-site scripting in OpenReception appointment-booking-software prior to version 1.0.2 allows a TENANT_ADMIN to plant malicious javascript: URIs in tenant link fields (website, imprint, privacyStatement), which execute in patients' browsers when they click the rendered links on the public landing page. The critical impact is not merely XSS but a complete collapse of the platform's stated end-to-end encryption guarantee: JavaScript executing in the patient origin can intercept and exfiltrate plaintext form data before client-side encryption is applied, meaning a malicious tenant administrator can silently read patient health appointment data the product claims the server can never access. No confirmed active exploitation (no CISA KEV entry) and no public POC have been identified at time of analysis.
Technical ContextAI
OpenReception is a SvelteKit-based appointment booking platform that positions itself as end-to-end encrypted, with the server acting as an untrusted relay. Tenant configuration links are stored server-side and served to unauthenticated patients via /api/public. These values are passed directly into a shared SvelteKit Button component (button.svelte) that previously rendered the raw href attribute without any URL scheme filtering, allowing javascript: URIs to be embedded as anchor hrefs. CWE-79 (Improper Neutralization of Input During Web Page Generation - Stored XSS) is the root cause: user-controlled input from a privileged role was stored and later reflected into the DOM in an executable context without sanitization. The fix (commit 98a107d) applies defense-in-depth at three layers: a Zod schema refinement that rejects non-http/https URLs at form submission, a server-side isLinkValid check in tenant-admin-service.ts that blocks storage of non-http/https links, and a derived derivedHref reactive variable in the Button component that strips any href not starting with http://, https://, mailto:, tel:, or /.
RemediationAI
Upgrade to OpenReception appointment-booking-software version 1.0.2, which is the vendor-released patched version confirmed by GitHub security advisory GHSA-xpr7-wx69-mp36 and commit 98a107d4b4eaeab5cbb96ee0a28c2342b853eee0. The patch applies URL allowlisting at three enforcement points: the frontend SvelteKit Button component now derives a safe href that returns undefined for any scheme other than http, https, mailto, tel, or relative paths; the backend tenant-admin-service validates all link fields via isLinkValid before persisting updates; and the Zod form schema rejects non-http/https URLs at the API boundary. For deployments that cannot immediately upgrade, a short-term compensating control is to audit and clear existing tenant link configurations via direct database access to remove any stored javascript: URIs, and to restrict TENANT_ADMIN account provisioning to verified, trusted operators only. Note that restricting TENANT_ADMIN access does not eliminate the vulnerability in the unpatched codebase - it only reduces exposure surface. No workaround fully mitigates the stored payload risk for already-configured malicious links without patching.
Same weakness CWE-79 – Cross-site Scripting (XSS)
View allShare
External POC / Exploit Code
Leaving vuln.today