CVE-2026-48083

Prior to version 1.0.4, OpenReception's appointment booking software allowed unauthenticated attackers to store attacker-controlled ML-KEM-768 public keys for any tenant without authentication. The POST /api/tenants/{tenantId}/staff/{staffId}/crypto route logged a warning but still inserted the row, and a variant with omitted email field suppressed the warning entirely. This breaks the end-to-end encryption claim, as the attacker becomes an additional encryption recipient for future patient appointments.

A vulnerability in OpenReception (before 1.0.2) in WebAuthn registration allows an unauthenticated attacker to associate their own credential with a victim's account by manipulating the userId parameter in the URL. The validation does not check that the userId belongs to the email in the cookie.

A vulnerability in OpenReception's appointment booking software allows a TENANT_ADMIN to promote themselves or another staff member to the platform-wide GLOBAL_ADMIN role via a single PUT request. There is no policy check enforcing that only an existing GLOBAL_ADMIN can grant GLOBAL_ADMIN, so schema validation acts as the authorization decision. After re-login, the tenant admin gains full access to all other tenants on the platform.

OpenReception's appointment booking software before version 1.0.1 allows an unauthenticated attacker to create a GLOBAL_ADMIN account by sending a POST request to `/setup/create-admin-account`, without verifying that an admin already exists. The attacker gains full administrative control over the platform, and the new account is active and does not require email confirmation.

OpenReception before version 1.0.2 does not throttle failed passphrase login attempts. An attacker can submit unlimited wrong passphrase guesses against any known email address, at a rate of about 10 attempts per second. The lack of throttling in the passphrase branch, while the WebAuthn endpoint has throttling, enables brute-force and dictionary attacks on user accounts. The issue is fixed in version 1.0.2.

OpenReception before 1.0.6 has a weak proof-of-work (16 bits) in the bootstrap-challenge endpoint, allowing easy bypass of rate limiting and automated abuse of booking flow.

Prior to version 1.0.2 of OpenReception's appointment booking software, 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.

OpenReception before version 1.0.2 exposes the full tenant record via `GET /api/tenants/{id}` to any authenticated TENANT_ADMIN, including the `databaseUrl` field with the live PostgreSQL connection string. In the default docker-compose deployment, this string contains the `postgres` superuser with plaintext password, allowing full access to all databases managed by that PostgreSQL instance.

Prior to version 1.0.2 of OpenReception, when a user navigates to the `/logout` page, the page's server-side load handler deletes the `access_token` cookie before calling `/api/auth/logout` via an internal `event.fetch()`. The internal fetch consequently runs without the auth cookie, so `apiAuthHandle` rejects it, the logout handler never executes, and `SessionService.revokeSession()` is never called for the current session. The DB session row remains valid until its natural expiry (one week by default). The user sees a successful logout (cookie gone, UI returns to login), but any party still holding a copy of the now-deleted access token can continue making authenticated API calls until the session naturally expires.

Prior to version 1.0.5, the unauthenticated `/api/tenants/{id}/schedule` endpoint returns all non-archived channels for a tenant regardless of the `isPublic` flag. Channels marked `isPublic = false` are intended to be hidden from public callers, but the endpoint discloses their names, descriptions, IDs, agent associations, pause status, confirmation requirements, and slot availability. Version 1.0.5 patches the issue.