OpenReception vulnerabilities

In OpenReception prior to 1.1.1, the POST /api/auth/passkeys endpoint accepts a request-body userId and an 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 inject a controlled public key, identify the matching userId, and create a STAFF session.

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.

In OpenReception versions 2.1.0 and prior, an unauthenticated attacker can store an arbitrary ML-KEM-768 public key under any existing user's identity in any tenant's staff-crypto recipient directory. The product's design guarantees that appointment data is end-to-end encrypted to staff members and that the staff recipient directory is not attacker-writable, so that even administrators and the operator cannot read patient data. This endpoint breaks that guarantee for an unauthenticated remote actor: it allows writing an arbitrary encryption recipient into the recipient directory of any tenant. The injected key receives the tunnel key of every appointment booked afterward in that tenant, because booking clients encrypt to all active staff keys. The attacker holds the corresponding secret key and is a persistent, unauthorized recipient of that key material. At time of publication, there are no publicly available patches.

In OpenReception prior to version 2.2.2, an attacker overbooks an agent, placing multiple appointments into a single time slot that the system is designed to keep exclusive. The number of overlapping appointments equals the number of concurrent requests, and one booking token is enough because the token is consumed after the insert. This results in the integrity of the booking calendar breaking and availability being denied to other clients. This issue has been patched in version 2.2.2.

In OpenReception versions 2.1.0 and prior, a returning client's six-digit booking PIN can be brute-forced online within the victim tenant. A successful guess yields the client's booking access token, granting access to that client's appointment tunnel with end-to-end-encrypted data and the ability to act as the client, e.g. adding or cancelling appointments. The bypass is cross-tenant: state owned by one tenant removes an authentication protection of a different tenant. At time of publication, there are no publicly available patches.

In OpenReception prior to version 2.2.1, an attacker who captures a pending invite token can replay it to obtain a passkey-registration credential and register their own passkey on the invited account, taking control of that account. For a staff or tenant-admin invite this yields access to the tenant context tied to that account. This issue has been patched in version 2.2.1.

In OpenReception prior to version 2.0.0, the account-confirmation link in emails is built from the request Host header with no allowlist. The unauthenticated POST /api/auth/resend-confirmation rotates a pending invitee's confirmation token and emails a link whose host comes from the request. An attacker sending one resend-confirmation with Host: attacker.example and a pending invitee's email causes that invitee to receive a confirmation email whose only link points to the attacker; if clicked, the one-time token reaches the attacker, who confirms the account on the real tenant domain and registers a passkey they control, taking over the account. All released versions through v1.1.0 are affected; no patched version exists yet. Reaching the app with a spoofed Host depends on the front proxy: the stock Caddy catch-all forwards it, while an operator with explicit per-tenant proxy blocks is not affected. This issue has been patched in version 2.0.0.

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's appointment booking software prior to version 1.0.2 has a vulnerability in the `/api/log` endpoint that accepts unauthenticated POST requests, applies no schema validation to the message body, writes attacker-controlled content directly into the application's stdout log, interprets newline characters as real line breaks, and enforces no size or rate limits. Three independent abuse modes follow: log injection (forge log lines that look like legitimate system events), log volume DoS (saturate the logging pipeline at sustained 100+ requests per second of small messages), and oversized-payload submission (100 KB payloads accepted; larger sizes not tested). The most operationally damaging mode is log injection. An attacker can inject lines that an operator scanning logs would mistake for real system errors, mask their own activity behind fake noise, or pollute SIEM alerting rules with crafted false positives. Version 1.0.2 fixes the issue.

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.

Prior to version 1.1.0, the GET handler at `/api/tenants/{id}/appointments/{appointmentId}` performs no authorization check before returning the appointment record. Any party who knows or obtains a valid appointment UUID receives the full row, including channel and agent IDs, time and timezone, status, and the AES-GCM ciphertext components. Version 1.1.0 patches the issue.

A vulnerability in OpenReception's appointment booking software (versions 1.0.1 and prior) allows an unauthenticated attacker to add an appointment to a private channel (where `isPublic = false`). The new-client booking flow does not bind the access token to `channelId`, and the validation in `createNewClientWithAppointment` lacks the `channel.isPublic` check, enabling bypass. The attack requires only solving a 16-bit proof-of-work (trivial) and knowing the channel ID, which can be obtained from another vulnerability (V-10).

A vulnerability in OpenReception's appointment booking software before version 1.0.5 allows an unauthenticated attacker to add arbitrary appointments to any client tunnel. The `add-to-tunnel` endpoint does not verify the caller's identity, only that a tunnel with the given `emailHash` exists, enabling insertion of appointments with CONFIRMED status, attacker-controlled ciphertext fields, date, duration, and chosen agent.

OpenReception before 1.0.6 has a vulnerability in staff deletion by TENANT_ADMIN that removes invites in other tenants sharing the same email.

Prior to version 1.0.4, the PIN-type challenge throttle uses `emailHash` as the only key, and the `challenge_throttle` table is shared across all tenants. An attacker who knows a patient's email can lock out that patient on another tenant by issuing failed challenge responses against one tenant. The lockout escalates with repeated failures, leading to sustained denial of service. Version 1.0.4 patches the issue.