Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-06T22:17:09.977Z",
  "pubdate": "2026-08-06T22:17:09.977Z",
  "executiveSummary": "An authentication bypass vulnerability exists in OpenReception appointment booking software prior to version 1.0.5. The flaw resides in the add-to-tunnel endpoint, which lacks caller authentication and session validation.\nAn unauthenticated attacker can exploit this vulnerability to inject arbitrary appointment rows into any client tunnel. By supplying a valid tunnelId alongside any valid emailHash acting merely as an existence check, an attacker can force the application to create a confirmed appointment.\nThe attack grants the capability to manipulate appointment ciphertext fields, dates, durations, and agent assignments with attacker-controlled data.\nThe root cause is improper authorization controls, as the endpoint is explicitly included in the apiAuthHandle public-route allowlist without enforcing a Bearer bootstrap booking access token or equivalent cryptographic verification.\nImpact includes unauthorized data insertion, appointment spoofing, resource exhaustion, and integrity compromise across affected tenant tunnels.\nExploitation requires network access to the target API endpoint and knowledge of valid identifiers, but no prior authentication, session tokens, or proof-of-work mechanisms.",
  "technicalDetails": "The vulnerability is located in the add-to-tunnel endpoint of OpenReception prior to version 1.0.5, a component intended for return-clients booking additional appointments within the end-to-end encrypted appointment booking platform.\nThe root cause of the vulnerability is an absolute lack of caller authentication, session validation, Authorization headers, booking access tokens, or proof-of-work checks on the vulnerable endpoint.\nThe application middleware explicitly configures this state, registering add-to-tunnel within the apiAuthHandle public-route allowlist alongside bootstrap and challenge endpoints that legitimately require no prior session.\nDuring execution, the endpoint performs an emailHash lookup, which functions merely as a tenant existence check rather than validating that the caller owns the supplied tunnelId.\nThe application validates only that some tenant tunnel exists associated with the provided emailHash, subsequently writing the appointment directly into the attacker-supplied tunnelId without confirming ownership or relationship between the two parameters.\nThe attack flow proceeds as follows: First, an attacker obtains or enumerates a valid tunnelId and a valid emailHash from distinct or identical targets. Second, the attacker crafts an HTTP request to the add-to-tunnel endpoint containing the attacker-controlled tunnelId, the validated emailHash, attacker-controlled ciphertext payload fields, arbitrary dates, custom durations, and a chosen agent identifier.\nThird, the endpoint processes the request, passes the loose existence validation via the emailHash, and inserts a new appointment row directly into the specified tunnel with a status of CONFIRMED.\nAffected software versions include all OpenReception deployments prior to version 1.0.5.\nPrivilege requirements are nonexistent, as the vulnerability is exposed globally on public routes without requiring user sessions or administrative privileges.\nNetwork exposure is strictly remote over standard web protocols via the exposed API endpoint.\nPost-exploitation impact includes unauthorized data modification, defacement of appointment calendars, denial of service via resource exhaustion of tenant tunnels, and potential operational disruption for legitimate clients sharing the platform."
}