Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-06T22:17:10.850Z",
  "pubdate": "2026-08-06T22:17:10.850Z",
  "executiveSummary": "OpenReception appointment booking software prior to version 1.0.2 suffers from a Stored Cross-Site Scripting (XSS) vulnerability that compromises its core end-to-end encryption trust model.\nA malicious TENANT_ADMIN can leverage administrative privileges to store arbitrary javascript: URLs within tenant configuration parameters including website, imprint, and privacyStatement links.\nThese malicious payloads are subsequently returned to patient-facing landing pages via the /api/public endpoint and dynamically rendered as clickable anchor elements without any URL-scheme filtering.\nWhen a victim patient interacts with these rendered links, malicious JavaScript code executes within the context of the patient browser origin.\nThis execution successfully bypasses the architectural security guarantee that the server acts merely as an untrusted relay, as patient form inputs can be intercepted, read, or modified in plaintext prior to the execution of client-side encryption routines.\nThe risk implication is severe, leading to a total breach of patient data confidentiality and integrity.\nSuccessful exploitation requires administrative access to a tenant account and user interaction via link clicking by the patient.",
  "technicalDetails": "The vulnerability resides in the handling and rendering of tenant configuration links within the patient-facing landing page of OpenReception prior to version 1.0.2.\nThe root cause is the absence of strict URL-scheme validation and sanitization when hydrating tenant link parameters (website, imprint, and privacyStatement) into the SvelteKit Button component.\nA user with TENANT_ADMIN privileges can supply arbitrary JavaScript execution vectors, such as javascript: URIs, into the configuration fields.\nThe application persists these strings and serves them via the /api/public endpoint to unauthenticated visitors accessing the appointment booking interface.\nThe step-by-step attack flow proceeds as follows: First, the TENANT_ADMIN updates the tenant configuration links with a malicious javascript: payload. Second, a patient visits the landing page and fetches the public configuration via /api/public. Third, the SvelteKit application hydrates these insecure values directly into anchor tags (<a href=\"javascript:...\">) without verifying that the URL scheme is limited to safe protocols like http or https.\nFourth, when the patient clicks the affected link, the browser executes the embedded JavaScript within the origin of the patient session.\nBecause client-side encryption of sensitive appointment form data occurs within the browser after input capture but prior to transmission, the executing script possesses full DOM access to read, scrape, or alter form inputs in plaintext.\nThis invalidates the foundational security claim of the platform, allowing rogue tenant administrators to capture sensitive patient health data before encryption mechanisms ever execute.\nThe affected component is the SvelteKit Button component rendering pipeline processing inputs from the /api/public endpoint across all OpenReception versions prior to 1.0.2."
}