CVE-2026-48078 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 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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/07/2026
The vulnerability identified in OpenReception's appointment booking software represents a critical information disclosure flaw that undermines the intended security boundaries of the system. This issue affects the unauthenticated `/api/tenants/{id}/schedule` endpoint, which serves as a public interface for retrieving scheduling information without requiring authentication. The flaw manifests when the system returns all non-archived channels associated with a tenant, completely ignoring the `isPublic` flag that should control access to internal-only services. This design oversight creates a scenario where sensitive channel information becomes publicly accessible through an endpoint that was never intended to expose such data to unauthorized users.
The technical implementation of this vulnerability stems from inconsistent access control enforcement within the application's API layer. While the `addAppointmentToTunnel` function properly validates that channels must have `isPublic = true` before allowing appointment creation, the schedule endpoint lacks this crucial validation check. This asymmetry in security controls creates a dangerous gap where private channels can be enumerated and their metadata exposed through the schedule endpoint, despite being explicitly marked as non-public. The exposed information includes channel names, descriptions, unique identifiers, agent associations, pause status indicators, confirmation requirements, and computed slot availability for specific date ranges.
The operational impact of this vulnerability extends beyond simple data exposure to potentially enable targeted attacks against internal services. An attacker could leverage this information disclosure to map out all available booking channels for a tenant, identifying both public and private services that may have different security postures or access controls. This enumeration capability could facilitate further attacks such as service disruption through denial-of-service conditions on specific channels, or social engineering campaigns targeting particular internal services. The vulnerability also violates fundamental security principles of least privilege and defense in depth, as it provides unauthorized access to information that should remain hidden from public view.
The security implications align with CWE-200 (Information Exposure) and represent a classic example of insecure direct object reference where the system fails to properly validate access permissions before disclosing sensitive data. From an ATT&CK framework perspective, this vulnerability maps to T1566 (Phishing) and T1046 (Network Service Scanning) as it enables adversaries to discover internal services that should remain hidden from public access. The fix implemented in version 1.0.5 addresses the core issue by ensuring that the schedule endpoint respects the `isPublic` flag when determining which channels to return, thereby restoring the intended access boundaries within the application's security architecture. This patch validates that both endpoints now enforce consistent access controls, preventing unauthorized disclosure of private channel information while maintaining proper functionality for legitimate public access scenarios.