EUVD-2026-54144Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L
Network-reachable with no authentication, but AC:H because exploitation requires independently valid tunnelId and emailHash identifiers; integrity high for arbitrary appointment injection; no confidentiality loss due to end-to-end encryption.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
3DescriptionCVE.org
OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.5, the add-to-tunnel endpoint creates a new appointment row in any client tunnel without any caller authentication. A request that supplies any valid tunnelId and any valid emailHash (the two need not belong to the same tunnel) results in an inserted appointment with status = "CONFIRMED", attacker-controlled ciphertext fields, attacker-controlled date and duration, and an attacker-chosen agent. The endpoint validates only that some tunnel exists with the given emailHash, then writes the appointment using the attacker-supplied tunnelId directly. The emailHash lookup is effectively an existence check on the tenant; it does not authenticate the caller as the owner of the supplied tunnelId. Combined with the absence of any session, Authorization header, booking access token, or PoW, this makes the endpoint accept arbitrary appointment writes into arbitrary tunnels. By contrast, the sibling endpoint create-new-client (used to bootstrap a brand-new client tunnel) requires a Bearer bootstrap booking access token issued by the bootstrap-challenge / bootstrap-verify flow. The add-to-tunnel endpoint, intended for return-clients booking additional appointments, has no equivalent gate. The application's own middleware confirms this is intentional: add-to-tunnel is explicitly listed in the apiAuthHandle public-route allowlist alongside the bootstrap and challenge endpoints (which legitimately have no session). Version 1.0.5 fixes the issue.
AnalysisAI
Unauthenticated appointment injection in OpenReception appointment-booking-software prior to version 1.0.5 allows any remote caller to insert CONFIRMED appointments into arbitrary client tunnels by exploiting a missing authorization gate on the add-to-tunnel endpoint. The endpoint accepted any POST supplying a valid emailHash - used only as a tenant existence check - alongside an unrelated valid tunnelId, writing attacker-controlled appointment fields (ciphertext content, date, duration, agent) without a session, Authorization header, booking access token, or proof-of-work. No CISA KEV listing or public POC is identified at time of analysis, but the exploit pattern is structurally straightforward once valid identifiers are obtained.
Technical ContextAI
OpenReception is an end-to-end encrypted appointment booking platform organized around per-client encrypted channels called tunnels. The vulnerable endpoint /api/tenants/[id]/appointments/add-to-tunnel was designed for returning clients booking additional appointments and was explicitly placed on the application's apiAuthHandle public-route allowlist - the same allowlist as the unauthenticated bootstrap and challenge endpoints - making the missing authorization an intentional architectural decision rather than an accidental omission. CWE-862 (Missing Authorization) is the root cause: the server validated tenant existence via an emailHash lookup but performed no ownership check binding the caller to the supplied tunnelId, allowing the two identifiers to be drawn from entirely different tenants. The sibling create-new-client endpoint correctly required a Bearer bootstrap booking access token issued through a challenge-verify flow, demonstrating that the token-based authorization design was already implemented and available but simply not applied to add-to-tunnel. The affected package is appointment-booking-software < 1.0.5 per ENISA EUVD-2026-54144.
RemediationAI
Upgrade to OpenReception appointment-booking-software version 1.0.5, confirmed as the patched release in GitHub Security Advisory GHSA-rhp5-vmcx-4qm8 and commit 4522a44c001782848faff5529d7c1e2be7ac9ef5. The fix introduces a requireBootstrapBookingAccessToken function on the add-to-tunnel handler that enforces a Bearer token in the Authorization header, verifies the token via verifyBookingAccessToken, checks the token scope is EXISTING_CLIENT_BOOKING_SCOPE, and binds the token to the specific tenantId, tunnelId, and emailHash of the request. The token is consumed post-appointment to prevent replay attacks. A complementary client-side fix removes the isFirstAppointment && guard so returning clients always include their booking access token - not only on first booking - ensuring the server-side gate is never bypassed by a legitimate returning client. If immediate upgrade is not possible, operators should block unauthenticated external access to the /api/tenants/[id]/appointments/add-to-tunnel path at the reverse-proxy or network perimeter layer; note that this workaround will prevent all returning-client bookings until version 1.0.5 is deployed. The full advisory is at https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-rhp5-vmcx-4qm8.
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today