OpenReception appointment-booking-software up to 1.0.1 New Client Flow /api/public/channels createNewClientWithAppointment channelId information disclosure

Summaryinfo

A vulnerability described as problematic has been identified in OpenReception appointment-booking-software up to 1.0.1. Affected by this vulnerability is the function createNewClientWithAppointment of the file /api/public/channels of the component New Client Flow. Such manipulation of the argument channelId leads to information disclosure. This vulnerability is traded as CVE-2026-48076. The attack may be launched remotely. There is no exploit available.

Detailsinfo

A vulnerability, which was classified as problematic, has been found in OpenReception appointment-booking-software up to 1.0.1. Affected by this issue is the function createNewClientWithAppointment of the file /api/public/channels of the component New Client Flow. The manipulation of the argument channelId with an unknown input leads to a information disclosure vulnerability. Using CWE to declare the problem leads to CWE-200. The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information. Impacted is confidentiality. CVE summarizes:

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.

The advisory is shared for download at github.com. This vulnerability is handled as CVE-2026-48076 since 05/20/2026. The exploitation is known to be easy. The attack may be launched remotely. No form of authentication is required for exploitation. There are known technical details, but no exploit is available. The current price for an exploit might be approx. USD $0-$5k (estimation calculated on 08/07/2026). The MITRE ATT&CK project declares the attack technique as T1592.

There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Type

• Appointment Software

Vendor

• OpenReception

Name

• appointment-booking-software

Version

• 1.0.0
• 1.0.1

CPE 2.3info

• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion