Description

OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. The new-client booking flow in versions 1.0.1 and prior consists of three calls: `bootstrap-challenge` (returns a 16-bit PoW challenge with `difficulty=4` leading hex zeroes), `bootstrap-verify` (validates the PoW and issues a Bearer booking access token), and `create-new-client` (consumes the token and creates the tunnel and first appointment). The token correctly binds to `tenantId`, `tunnelId`, `clientPublicKey`, and `emailHash`, but never to `channelId`. The `bootstrap-challenge` request schema does not even accept a `channelId`, and the issued token's payload contains no channel information. Independently, the service function `createNewClientWithAppointment` checks only `channel.archived = false`. The `channel.isPublic` check that protects `addAppointmentToTunnel` is missing in the new-client path. The combination means: an attacker completes the bootstrap flow normally (16-bit PoW, completes in well under one second on commodity hardware, no rate limiting beyond the throttle store), receives a valid booking access token, and then submits the `create-new-client` payload with `channelId` pointing to a private (`isPublic = false`) channel. The booking lands as `CONFIRMED` if the target channel has `requiresConfirmation = false` (the default), otherwise as `NEW`. The patient-facing UI does not list private channels in its picker (`/api/public/channels` correctly filters `isPublic = true`), so the channel ID must be obtained out of band. The companion finding V-10 (schedule endpoint discloses private channels) provides exactly that: a single unauthenticated GET reveals every private channel ID for any tenant. V-10 plus V-11 together make private channels fully reachable to anonymous attackers. As of time of publication, no known patched versions are available.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-06T22:17:10.127Z",
  "pubdate": "2026-08-06T22:17:10.127Z",
  "executiveSummary": "OpenReception appointment booking software versions 1.0.1 and prior contain a critical access control vulnerability within the new-client booking flow. The vulnerability allows unauthenticated attackers to bypass privacy restrictions and create appointments in private channels. The root cause stems from a missing authorization check in the `createNewClientWithAppointment` service function, which fails to validate the `isPublic` property of the target channel, combined with an issued booking access token that lacks binding to the `channelId`. Attackers can chain this flaw with information disclosure vulnerabilities such as V-10 to harvest private channel IDs and successfully schedule appointments in private or restricted channels without authorization. The impact includes unauthorized appointment creation, resource misuse, and potential data exposure within tenant scheduling systems. Exploitation requires no prior authentication, trivial computational effort to solve the 16-bit Proof of Work (PoW) challenge, and knowledge of a valid private `channelId`. At the time of publication, no patched versions are available to remediate this flaw.",
  "technicalDetails": "The vulnerability resides in the new-client appointment booking mechanism of OpenReception versions 1.0.1 and prior. The complete booking flow consists of three distinct HTTP requests: `bootstrap-challenge`, `bootstrap-verify`, and `create-new-client`. During the initial phase, `bootstrap-challenge` returns a 16-bit Proof of Work (PoW) challenge with a low difficulty setting of four leading hex zeroes, which can be solved on commodity hardware in well under one second and lacks sufficient rate limiting beyond a basic throttle store. Following the challenge resolution, `bootstrap-verify` validates the PoW and issues a Bearer booking access token. While this token correctly binds attributes such as `tenantId`, `tunnelId`, `clientPublicKey`, and `emailHash`, it completely omits binding to the `channelId`. Furthermore, the `bootstrap-challenge` request schema does not accept a `channelId` parameter, and the resulting token payload contains no channel-level context. In the final step of the flow, the `create-new-client` endpoint consumes the token to establish a tunnel and create the first appointment. The underlying service function, `createNewClientWithAppointment`, exclusively validates that `channel.archived = false`, omitting the critical `channel.isPublic = true` check that is enforced in other endpoints such as `addAppointmentToTunnel`. Although the patient-facing user interface properly filters out private channels by enforcing `isPublic = true` through `/api/public/channels`, an attacker can obtain private channel IDs out of band. Specifically, companion findings such as V-10 disclose private channels via an unauthenticated GET request, enabling anonymous actors to discover private channel IDs for any tenant. An attacker exploits this by completing the standard bootstrap flow to acquire a valid Bearer token, and then submitting the `create-new-client` payload populated with a targeted private `channelId` (`isPublic = false`). Depending on the channel configuration, the appointment lands with a status of CONFIRMED if `requiresConfirmation = false` (the default setting), or NEW otherwise. The vulnerability is entirely network-exploitable without authentication or privileges, targeting the core appointment creation logic of the OpenReception platform."
}