EUVD-2026-54145Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Network-accessible REST API, no authentication required, trivial PoW yields AC:L; no direct confidentiality exposure from this CVE path; partial integrity and availability impact from unauthorized booking injection.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
1DescriptionCVE.org
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.
AnalysisAI
Unauthorized booking injection into private channels affects OpenReception appointment-booking-software ≤ 1.0.1 via a missing isPublic authorization check in the new-client booking path. An unauthenticated remote attacker solves a trivial 16-bit proof-of-work challenge, obtains a valid bearer token, and then supplies any private channelId in the create-new-client payload - bypassing the access control that protects the standard appointment path. When chained with companion finding V-10 (unauthenticated schedule endpoint leaking all private channel IDs), the entire attack requires only two unauthenticated HTTP sequences, no public exploit code identified at time of analysis.
Technical ContextAI
OpenReception appointment-booking-software is a TypeScript-based end-to-end encrypted scheduling platform. The three-step new-client booking flow issues a bearer token after a proof-of-work gate; that token binds tenantId, tunnelId, clientPublicKey, and emailHash but is structurally incapable of binding channelId because the bootstrap-challenge schema does not accept one and the token payload carries no channel claim. The root cause is CWE-863 (Incorrect Authorization): the service function createNewClientWithAppointment applies only a channel.archived = false predicate, omitting the channel.isPublic = true check enforced by addAppointmentToTunnel on the standard appointment path. The 16-bit PoW (4 leading hex zeroes) completes in sub-second time on commodity hardware with no additional rate limiting beyond a throttle store, making token acquisition effectively free. Affected versions per EUVD-2026-54145: appointment-booking-software ≤ 1.0.1; no CPE string was included in source data.
RemediationAI
No vendor-released patch has been identified at time of analysis; the advisory explicitly states no known patched versions exist. Operators should monitor https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-3658-3j75-p5j3 for patch releases. Until a patch is available, the highest-value compensating control is to enforce channel.isPublic = true within the createNewClientWithAppointment service function, mirroring the check present in addAppointmentToTunnel - this is the surgical code-level fix and requires a local patch to the application source. As a workflow-level mitigation, setting requiresConfirmation = true on all private channels prevents unauthorized bookings from landing as CONFIRMED; they will arrive as NEW status and require staff review before processing, adding manual overhead but containing the integrity impact. Operators should also restrict or authenticate the schedule endpoint implicated in companion V-10, as it is the primary channel-enumeration primitive that makes this exploit trivially chainable; removing that endpoint or requiring authentication eliminates the unauthenticated channel discovery step. Adding stricter rate limiting to bootstrap-challenge and bootstrap-verify raises the marginal cost of bulk token minting, though this alone does not close the authorization gap.
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today