Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.4",
  "pubDate": "2026-08-06T22:17:11.893Z",
  "pubdate": "2026-08-06T22:17:11.893Z",
  "executiveSummary": "OpenReception appointment booking software prior to version 1.0.4 suffers from an unauthenticated cryptographic key injection vulnerability within the staff crypto management route.\nThe flaw allows any unauthenticated network attacker to register arbitrary ML-KEM-768 public keys against any tenant and staff identifier on the platform.\nThis breaks the end-to-end encryption (E2E) guarantees of the platform, enabling attackers to intercept and decrypt future patient appointment payloads by becoming co-recipients of the encrypted tunnel keys.\nThe vulnerability stems from improper authentication enforcement, insecure conditional evaluation in Zod schema validation that suppresses security warning logs, lack of unique database constraints, and absent cryptographic validation on submitted key material.\nAttacker capabilities include arbitrary cryptographic identity injection, denial-of-service via malformed entries, and complete compromise of appointment confidentiality across targeted tenants without requiring prior access or privileges.",
  "technicalDetails": "The vulnerability resides in the route POST /api/tenants/{tenantId}/staff/{staffId}/crypto within OpenReception prior to version 1.0.4. The root cause is a failure to properly enforce authentication and session validation before persisting attacker-controlled ML-KEM-768 public keys to the staff_crypto database table.\nWhen a request lacks both a session and a registration cookie, the handler logs an unauthorized attempt warning but proceeds with the database insertion regardless. A second variant of the bug suppresses this warning entirely: the Zod schema makes the email field optional, causing the comparison registrationEmail === email to evaluate to undefined === undefined (true) when the email is omitted and no registration cookie is present. This tricks the handler into treating the request as a legitimate registration flow, skipping the warning and recording only a standard info log.\nAdditional weaknesses compound the issue. The staff_crypto table lacks a unique constraint on user_id, allowing an arbitrary number of malicious rows to coexist for the same staff identifier, all returning as is_active=true. Furthermore, the supplied staffId does not require matching any existing user or pending invite, and schema validation accepts placeholder values such as <placeholder-base64> without checking length, format, or cryptographic validity.\nThe attack flow proceeds as follows: First, an unauthenticated network attacker submits a crafted POST request to the vulnerable endpoint containing arbitrary ML-KEM-768 public keys, passkeyId, and privateKeyShare values for any target tenantId and staffId. Second, the backend bypasses authentication checks or incorrectly evaluates the optional email parameter, successfully storing the poisoned key records. Third, the injected keys are integrated into the public booking flow; when a patient completes the unauthenticated bootstrap-challenge and bootstrap-verify ceremony, the resulting bookingAccessToken is accepted by GET /api/tenants/{id}/appointments/staff-public-keys, which returns the attacker-controlled keys alongside legitimate ones.\nFinally, when a new appointment encrypts its tunnel key using ML-KEM to all listed recipients, the attacker receives the encrypted tunnel key, decapsulates it using the matching secret, and achieves full decryption of all appointment payloads associated with that booking."
}