OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to 1.1.1, POST /api/auth/passkeys accepts a request-body userId and attacker-supplied passkey without an authenticated session, does not call WebAuthnService.verifyRegistration, and does not bind enrollment to locals.user.id. An unauthenticated attacker who knows the public tenant ID and the target staff email can use the public booking bootstrap and GET /api/tenants/[id]/appointments/staff-public-keys to obtain candidate userId values. The attacker first causes UserService.addAdditionalPasskey to store a controlled public key for a candidate userId, then attempts login with the target email; the login check compares verificationResult.userId with the email-resolved account and reveals whether the injected credential belongs to that target. Repeating this injection-before-login sequence identifies the matching userId, and the normal login endpoint accepts the attacker's assertion for the stored key and creates a STAFF session. The session can expose tenant data and reveal TENANTADMIN identifiers for further takeover; GLOBALADMIN accounts are not reachable through this tenant-scoped path. A hijacked TENANTADMIN can modify or delete tenant resources and key shares, potentially making appointment data permanently undecryptable and taking booking services offline. This issue is fixed in version 1.1.1.

OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.2, a TENANTADMIN 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.

OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.1, a fully provisioned OpenReception instance accepts unauthenticated POST requests to /setup/create-admin-account and creates additional GLOBALADMIN accounts without verifying that an admin already exists. Any unauthenticated network attacker who can submit a same-origin form POST gains full platform-level administrative control. The newly created account is isactive=true with confirmationstate=ACCESSGRANTED and does not require completing email confirmation; the GLOBALADMIN row is created active and immediately usable. Login and tenant enumeration succeed without any further interaction. This is distinct from the deployment race condition already documented on the Claiming an instance page. That documented race covers the window between deployment and first claim. The bug reported here works after the operator has properly claimed and configured the instance: the layout-level guard that protects the setup page only redirects on GET, while the default form action handler creates the user without rechecking adminExists(). Three GLOBALADMIN accounts were created in succession during testing, with no rate limiting observed. Audit-specific event logging beyond standard application logs was not assessed; the standard [error] line that surfaces only when a uniqueness conflict is hit is not the same as a security event for "additional admin created post-claim". The form post is rejected for browser drive-by CSRF by SvelteKit's built-in same-origin check, but any tool that supplies a matching Origin header (curl, Burp, automated scanners, server-side proxies) bypasses this trivially. No additional preconditions exist. Users should upgrade to version 1.0.1 to receive a patch.