Description

OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.5, the unauthenticated `/api/tenants/{id}/schedule` endpoint returns every non-archived channel for a tenant regardless of the channel's `isPublic` flag. Channels marked `isPublic = false` are intended to be invisible to public callers; the dashboard creates them deliberately to hide internal-only services from the patient booking UI. The schedule endpoint ignores the flag entirely and discloses channel names, descriptions, IDs, agent associations, pause status, confirmation requirements, and computed slot availability for the requested date range. The asymmetry between `addAppointmentToTunnel` (which enforces `eq(channel.isPublic, true)`) and the schedule endpoint (which does not) confirms the design intent: private channels exist as a real access boundary in the booking flow, just not in the schedule disclosure. Version 1.0.5 patches the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-06T22:17:10.420Z",
  "pubdate": "2026-08-06T22:17:10.420Z",
  "executiveSummary": "An authorization bypass and information disclosure vulnerability exists in OpenReception appointment booking software prior to version 1.0.5. The vulnerability affects the unauthenticated endpoint /api/tenants/{id}/schedule, which fails to respect the isPublic visibility flag assigned to tenant channels. Consequently, unauthenticated public callers can enumerate internal-only services, private channel configurations, agent associations, pause statuses, confirmation requirements, and computed slot availability for any requested date range. This exposes sensitive operational metadata intended exclusively for internal dashboard workflows and hidden from the patient booking user interface. The risk implication is unauthorized reconnaissance of internal scheduling topology and resource allocation. Attackers require no authentication, privileges, or prior access beyond network connectivity to the publicly exposed API. Exploitation is trivially performed by sending HTTP GET requests directly to the affected schedule endpoint, bypassing intended access boundary controls observed in other functional components such as addAppointmentToTunnel.",
  "technicalDetails": "The vulnerability resides within the schedule retrieval logic of OpenReception prior to version 1.0.5, specifically impacting the unauthenticated HTTP endpoint /api/tenants/{id}/schedule. The root cause is a failure in access control validation and query filtering regarding the isPublic boolean flag associated with tenant channels. While internal dashboard systems deliberately create channels with isPublic set to false to conceal administrative or internal-only services from public clients, the schedule endpoint logic omits this filtering condition.\nA direct architectural asymmetry exists within the application codebase. Functions such as addAppointmentToTunnel explicitly enforce a strict access boundary by validating that channel.isPublic evaluates to true before processing requests. However, the /api/tenants/{id}/schedule endpoint completely bypasses this check, returning all non-archived channels regardless of their intended visibility state.\nThe attack flow proceeds as follows. An unauthenticated attacker targets the network-exposed /api/tenants/{id}/schedule endpoint by substituting a valid tenant identifier into the URL path. The backend application queries the database or internal data structures for all non-archived channels associated with the specified tenant ID. Due to the missing authorization filter, the application serializes and returns the complete set of channel records in the HTTP response payload.\nThe returned payload exposes critical operational intelligence, including internal channel names, descriptive metadata, unique channel identifiers, associated agent details, operational pause statuses, confirmation requirements, and computed time slot availability over arbitrary date ranges. This data leakage provides malicious actors with granular visibility into internal scheduling infrastructure and availability metrics without requiring authentication or high privileges. The issue is fully remediated in version 1.0.5 by enforcing the isPublic access boundary check within the schedule endpoint."
}