CVE-2026-48076 in appointment-booking-software
Summary
by MITRE • 08/07/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/07/2026
The vulnerability in OpenReception's appointment booking software stems from a critical authorization flaw in the new-client booking flow that affects versions 1.0.1 and prior. This issue creates a path for unauthorized access to private channels through a combination of weak token binding and missing security checks. The system's bootstrap process consists of three sequential API calls that should establish secure authentication but instead create exploitable gaps in the authorization model. The initial `bootstrap-challenge` call generates a 16-bit proof-of-work challenge requiring only four leading hex zeroes, which can be solved rapidly on standard hardware without any rate limiting mechanisms to prevent abuse.
The core technical flaw lies in how the booking access token is constructed and validated during the `bootstrap-verify` phase. While the token correctly binds essential identifiers including `tenantId`, `tunnelId`, `clientPublicKey`, and `emailHash`, it fails to include `channelId` in its binding constraints. This omission means that an attacker can reuse a valid token across different channels, fundamentally undermining the intended channel-level security boundaries. The token's payload structure contains no channel information whatsoever, making it possible for an attacker to manipulate which channel receives the booking regardless of their authorization status.
The operational impact becomes severe when examining how `createNewClientWithAppointment` processes these requests. This service function performs validation checks but notably omits the crucial `channel.isPublic` verification that should protect against unauthorized access to private channels. The function only validates that `channel.archived = false`, leaving the public/private status of channels completely unverified during new client creation. This design flaw creates a direct pathway for attackers to submit bookings to private channels by simply specifying the appropriate channel ID in their payload, bypassing all intended access controls.
The attack vector becomes exploitable when combined with another vulnerability that allows anonymous enumeration of private channel IDs. The companion finding V-10 reveals that unauthenticated GET requests to the schedule endpoint disclose every private channel ID for any tenant through the `/api/public/channels` endpoint. This information disclosure creates the necessary intelligence for attackers to identify and target specific private channels. Once armed with valid private channel IDs, attackers can complete the normal bootstrap flow using legitimate proof-of-work solutions, obtain a valid booking token, and then submit the `create-new-client` request with malicious channel ID targeting private channels.
The consequences extend beyond simple unauthorized access to include potential data exposure and service disruption. Bookings submitted to private channels appear in the patient-facing UI according to the channel's configuration, meaning that sensitive appointments could be scheduled without proper authorization. When `requiresConfirmation = false` (the default setting), bookings automatically appear as `CONFIRMED`, while `requiresConfirmation = true` results in `NEW` status but still represents unauthorized access. This vulnerability directly violates principle of least privilege and creates a situation where any anonymous attacker can effectively gain read and write access to private appointment channels, undermining the end-to-end encryption and privacy guarantees that the platform claims to provide.
This vulnerability maps to CWE-285 (Improper Authorization) and CWE-347 (Improper Verification of Cryptographic Signature) while aligning with ATT&CK technique T1078 (Valid Accounts) through unauthorized access using legitimate authentication tokens. The lack of proper channel binding in the token creation process creates a situation where authorization is effectively bypassed for private resources, making this a critical security flaw that could result in significant privacy violations and data exposure across multiple tenants.
The absence of any rate limiting mechanisms beyond basic throttle store implementations compounds the severity of this vulnerability, allowing attackers to conduct automated exploitation attempts without detection. The combination of rapid proof-of-work completion, valid token reuse capability, and public channel enumeration creates a complete attack chain that can be executed repeatedly with minimal cost or risk of detection. No patched versions are currently available, leaving affected systems vulnerable to exploitation by any attacker with basic technical knowledge and access to the platform's public API endpoints.
The root cause of this vulnerability demonstrates poor security architecture design where token binding was insufficiently implemented across all relevant identifiers, and proper authorization checks were omitted from critical paths in the booking flow. The system fails to enforce channel-level access controls during new client creation, creating a fundamental mismatch between the intended security model and actual implementation. This flaw represents a failure to properly implement the principle of least privilege and demonstrates how seemingly minor oversights in token design can create catastrophic security implications for sensitive appointment booking systems that rely on privacy and authorization boundaries to protect patient data.