CVE-2026-48075 in appointment-booking-software
Summary
by MITRE • 08/07/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/07/2026
The vulnerability in OpenReception's appointment booking software represents a critical authorization flaw that allows arbitrary appointment creation across client tunnels without proper authentication mechanisms. This issue exists in the `add-to-tunnel` endpoint which was designed for returning clients to book additional appointments but lacks any form of caller verification or session management. The endpoint accepts attacker-supplied parameters including tunnelId and emailHash without validating that the requester has legitimate authorization to modify the specified tunnel, creating a path for unauthorized appointment manipulation.
The technical implementation flaw stems from the endpoint's validation logic that performs only a superficial existence check on the emailHash parameter rather than authenticating the caller against the tunnel ownership. This pattern of validation bypass occurs because the system validates that some tunnel exists with the given emailHash but fails to verify that the attacker controls the tunnel identified by the supplied tunnelId. The lack of session management, Authorization headers, booking access tokens, or proof-of-work mechanisms means that any attacker can submit a request containing arbitrary tunnel identifiers and emailHash values, resulting in appointment records being created with attacker-controlled attributes including status, ciphertext fields, date, duration, and assigned agent.
The operational impact of this vulnerability is significant as it allows attackers to inject confirmed appointments into any client tunnel regardless of their authorization status. This creates potential for appointment spoofing, data integrity violations, and service disruption since attackers can manipulate appointment details including scheduling conflicts and resource allocation. The vulnerability effectively removes the security boundary between different client tunnels, enabling cross-tunnel appointment manipulation that undermines the end-to-end encryption promise of the platform. According to CWE-285, this represents an authorization flaw where the system fails to properly verify the identity of the requester before allowing access to protected resources.
The misconfiguration becomes particularly concerning when considering the application's own middleware design decisions which explicitly allowlist the `add-to-tunnel` endpoint alongside bootstrap and challenge endpoints in the public-route allowlist. This intentional design choice demonstrates that the developers understood this endpoint should remain unauthenticated but failed to implement proper validation controls. The contrast with the `create-new-client` endpoint, which requires a Bearer bootstrap booking access token issued through a proper authentication flow, highlights the inconsistent security approach within the application's API architecture. The vulnerability aligns with ATT&CK technique T1078 which covers legitimate credentials used for persistence and privilege escalation, though in this case it manifests as unauthorized appointment creation rather than persistent access.
The fix implemented in version 1.0.5 addresses these authorization gaps by enforcing proper authentication checks before allowing appointment creation in any client tunnel. The remediation likely involves implementing session validation, tunnel ownership verification, or requiring authentication tokens for the `add-to-tunnel` endpoint similar to how other authenticated endpoints operate. This change ensures that only authorized clients can create appointments in specific tunnels, maintaining the integrity of the multi-tenant architecture and preventing cross-tunnel appointment manipulation that could compromise service availability and data consistency. The vulnerability demonstrates the importance of consistent authentication patterns throughout API implementations and highlights how seemingly minor authorization gaps can result in significant security exposure in collaborative systems.