CVE-2026-48088
CriticalCVSS 9.4Exploitation Probability (EPSS)
Low risk26th percentile - higher than 26% of all known CVEs
Summary
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.
Risk Assessment
The organization risks exposure of sensitive medical data: an unauthenticated attacker can decrypt appointment content for bookings where they were added as a key recipient. Additionally, weak key validation allows poisoning the staff directory, potentially disrupting legitimate booking flows.
Recommendation
Immediately upgrade OpenReception to version 1.0.4 or later, which patches the issue. After upgrading, audit the staff_crypto table for unauthorized entries, and consider adding unique constraints on user_id and strengthening key validation.
Other vulnerabilities in OpenReception
See all- CVE-2026-54460Critical
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.
- CVE-2026-48087Critical
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.
- CVE-2026-48086Critical
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.
- CVE-2026-48085Critical
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.
- CVE-2026-48084High
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.
- CVE-2026-48083Medium
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.
- CVE-2026-48082Low
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.
- CVE-2026-48081High
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.
- CVE-2026-48080High
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.
- CVE-2026-48079High
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.
Original NVD description (English source)
OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.4, the route `POST /api/tenants/{tenantId}/staff/{staffId}/crypto` accepts and stores attacker-controlled ML-KEM-768 public keys against any tenant on the platform without authentication. The handler logs an "Unauthorized crypto key storage attempt" warning when neither a session nor a registration cookie is present, then proceeds to insert the row regardless. The platform's E2E claim that "even administrators cannot view sensitive information" is broken: any unauthenticated network attacker can register themselves as an additional encryption recipient for any tenant's future patient appointments. A second variant of the bug suppresses the unauthorized-warning log entry. The Zod schema makes the `email` field optional. When the request body omits `email` and the request carries no registration cookie, the comparison `registrationEmail === email` becomes `undefined === undefined`, which evaluates to `true`. The handler treats the request as a legitimate registration flow, skips the warning entirely, and stores the row. Successful storage is still recorded as an `[info]` log line, but the security-relevant warning that operators are most likely to monitor or alert on is gone. The `staff_crypto` table has no unique constraint on `user_id`, so an arbitrary number of attacker rows can coexist for the same staff identifier and all return as `is_active=true`. The supplied `staffId` does not need to match any existing user or pending invite. Schema validation on `passkeyId`, `publicKey`, and `privateKeyShare` is also weak: the literal string `<placeholder-base64>` was accepted, indicating no length, format, or cryptographic-validity check beyond field presence. This weakness is independent of the auth bypass but compounds it: a poisoned directory can also be filled with malformed entries that break legitimate booking flows. The injected key is consumed by the public booking flow. After completing the unauthenticated `bootstrap-challenge` and `bootstrap-verify` ceremony as a "patient", the resulting `bookingAccessToken` is accepted by `GET /api/tenants/{id}/appointments/staff-public-keys`, which returns the attacker-controlled keys alongside any legitimate ones. A new appointment encrypts its tunnel key with ML-KEM to all listed recipients, so the attacker becomes a co-recipient of the encryption and can decapsulate the tunnel key with the matching secret. From there, all appointment payloads for that booking are decryptable. Version 1.0.4 patches the issue.