CVE-2026-48088

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 ` 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.