CVE-2026-48081 in appointment-booking-software
Summary
by MITRE • 08/07/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/07/2026
This vulnerability exists within OpenReception's appointment booking platform where tenant administrators possess elevated privileges to inject malicious javascript URLs into configuration settings. The flaw manifests in the tenant links configuration fields including website, imprint, and privacyStatement which are subsequently exposed through the public API endpoint /api/public. These values flow directly into SvelteKit Button components without proper URL scheme validation or sanitization, creating a direct path for malicious code execution when rendered as HTML anchor elements with href attributes containing javascript: protocols. The security implications are severe because patient-facing landing pages render these links in the browser context where they execute with the same origin privileges as legitimate application code.
The technical exploitation occurs through a server-side configuration injection vulnerability that bypasses client-side input validation mechanisms. When patients interact with the rendered links, their browsers execute the embedded javascript within the same security context as the legitimate application, allowing attackers to access form data before it undergoes client-side encryption. This represents a critical breakdown in the application's core security model where administrators who should be trusted only as relay operators gain the ability to read patient information directly from the browser environment. The vulnerability specifically targets the trust boundary between server and client components, undermining the fundamental promise of end-to-end encryption.
The operational impact extends beyond simple data theft to encompass potential data manipulation and complete compromise of patient privacy assurances. Attackers can harvest sensitive information including personal details, medical history, and contact information before any encryption occurs, effectively nullifying the security posture that the system claims to maintain. The vulnerability affects all versions prior to 1.0.2 and represents a classic cross-site scripting attack vector that leverages legitimate configuration fields to deliver malicious payloads. This flaw aligns with CWE-79 (Cross-Site Scripting) and CWE-20 (Improper Input Validation) categories, while also mapping to ATT&CK technique T1566 (Phishing) and T1071.004 (Application Layer Protocol: DNS).
The remediation implemented in version 1.0.2 addresses this vulnerability through proper input sanitization and URL scheme filtering mechanisms that prevent javascript: protocol execution within the application's configuration fields. The fix ensures that all link values passed to the SvelteKit components undergo strict validation to reject potentially dangerous protocols before rendering, thereby maintaining the security boundary between legitimate application functionality and malicious code injection. This update restores the intended trust model where administrators cannot access patient data directly through browser-based attacks while preserving the system's core functionality for legitimate use cases.
This vulnerability demonstrates how seemingly innocuous configuration fields can become attack vectors when proper input validation is absent from the application's security architecture. The flaw highlights the importance of maintaining strict security boundaries even within trusted administrative interfaces and underscores the critical need for comprehensive sanitization of all user-provided content that reaches client-side execution contexts. The resolution reinforces defensive programming practices around input validation and output encoding, establishing a more robust foundation for maintaining end-to-end encryption guarantees in healthcare applications where patient privacy is paramount.