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.
Published: 2026-08-06
Score: 6.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability resides in OpenReception’s appointment booking platform. The API endpoint designed for adding appointments to a client’s tunnel, add-to-tunnel, performs only a basic existence check on the provided tunnel identifier and email hash. No authentication or session validation is made, allowing any requester to create a confirmed appointment with attacker‑controlled data, including ciphertext fields, date, duration, and agent. Because the endpoint does not verify that the caller owns the tunnel, an attacker can inject appointments into any tunnel belonging to any tenant. This flaw falls under incomplete authorization (CWE-862). The result is the ability to create, modify, or inject appointments without user consent, potentially disrupting tenant schedules.

Affected Systems

The affected product is OpenReception appointment booking software supplied by the vendor open-reception, any installation prior to version 1.0.5 of the application. The flaw is present on the add-to-tunnel endpoint, which accepts valid tunnel identifiers and email hashes from any client. No other products or versions are listed as impacted.

Risk and Exploitability

The impact is moderate with a CVSS score of 6.5. EPSS is not available, and the vulnerability is not listed in the CISA KEV catalog. An attacker can exploit the flaw by sending an unauthenticated HTTP request to the add-to-tunnel endpoint with a known tunnelId and any valid emailHash. The lack of authentication or authorization checks makes exploitation trivial for anyone who can reach the endpoint. This makes the vulnerability relatively low cost to attack, but the scope includes all clients relying on the affected endpoint.

Generated by OpenCVE AI on August 7, 2026 at 00:58 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade OpenReception to version 1.0.5 or later, which implements proper authentication for the add-to-tunnel endpoint.
  • If an upgrade is delayed, restrict external access to the add-to-tunnel API by configuring network firewalls or reverse‑proxy rules to only allow traffic from trusted internal networks or authorized systems.
  • Consider implementing additional application‑level access controls, such as requiring a valid bearer token or session cookie for any appointment‑modifying requests, to ensure only authorized users can create or modify appointments.

Generated by OpenCVE AI on August 7, 2026 at 00:58 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 07 Aug 2026 18:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'poc', 'Technical Impact': 'partial'}, 'version': '2.0.3'}


Fri, 07 Aug 2026 10:30:00 +0000

Type Values Removed Values Added
First Time appeared Open-reception
Open-reception appointment-booking-software
Vendors & Products Open-reception
Open-reception appointment-booking-software

Thu, 06 Aug 2026 22:15:00 +0000

Type Values Removed Values Added
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.
Title OpenReception's unauthenticated add-to-tunnel endpoint accepts arbitrary appointment injections
Weaknesses CWE-862
References
Metrics cvssV3_1

{'score': 6.5, 'vector': 'CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L'}


Subscriptions

Open-reception Appointment-booking-software
cve-icon MITRE

Status: PUBLISHED

Assigner: GitHub_M

Published:

Updated: 2026-08-07T17:15:21.502Z

Reserved: 2026-05-20T18:25:25.708Z

Link: CVE-2026-48075

cve-icon Vulnrichment

Updated: 2026-08-07T17:15:10.561Z

cve-icon NVD

Status : Received

Published: 2026-08-06T22:17:09.977

Modified: 2026-08-07T18:17:17.587

Link: CVE-2026-48075

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-07T09:59:05Z

Weaknesses