CVE-2026-48077 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.1.0, the GET handler at `/api/tenants/{id}/appointments/{appointmentId}` performs no authorization check before returning the appointment record. Any party who knows or obtains a valid appointment UUID receives the full row, including channel and agent IDs, time and timezone, status, and the AES-GCM ciphertext components (`encryptedPayload`, `iv`, `authTag`, `dataKey`). The same file's DELETE handler calls `checkPermission(locals, tenantId, true)` before allowing deletion. The intent is clear: appointment records are tenant-scoped and require authentication to access. The GET handler is missing the equivalent call. The middleware chain (`apiAuthHandle`, `authGuard`) does not compensate: API paths bypass `authGuard` entirely, and `apiAuthHandle` does not block requests to non-admin paths when no token is present. Version 1.1.0 patches the issue.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/07/2026
The vulnerability in OpenReception's appointment booking software represents a critical authorization flaw that exposes sensitive patient data through improper access controls. This issue manifests in the GET handler at `/api/tenants/{id}/appointments/{appointmentId}` which fails to perform necessary authorization checks before returning complete appointment records. The flaw exists within the application's permission model where tenant-scoped appointment data becomes accessible to any party possessing a valid appointment UUID, creating a significant security risk that aligns with CWE-285: "Improper Authorization" and falls under ATT&CK technique T1078: "Valid Accounts" as unauthorized parties can leverage legitimate identifiers to access protected information.
The technical implementation reveals a clear inconsistency in the application's security controls where the DELETE handler properly calls `checkPermission(locals, tenantId, true)` to validate user permissions before allowing record deletion, yet the GET handler omits this crucial authorization check entirely. This discrepancy indicates a fundamental flaw in the middleware chain design where `apiAuthHandle` and `authGuard` middleware components fail to provide adequate protection for GET endpoints. The `apiAuthHandle` middleware specifically does not block requests to non-admin paths when no authentication token is present, while `authGuard` middleware entirely bypasses API paths, creating a dangerous gap in the security perimeter that allows unauthorized access to encrypted appointment data.
The operational impact of this vulnerability extends beyond simple information disclosure to encompass potential privacy violations and compliance breaches. Appointment records contain sensitive channel and agent IDs, precise time and timezone information, status details, and complete AES-GCM encryption components including `encryptedPayload`, `iv`, `authTag`, and `dataKey`. This comprehensive exposure means that unauthorized parties can access not only appointment scheduling data but also the cryptographic elements necessary to potentially decrypt sensitive patient information, violating principles of least privilege and data protection. The vulnerability essentially creates a backdoor that allows any attacker with knowledge of a valid UUID to retrieve complete appointment records without proper authentication.
The remediation implemented in version 1.1.0 addresses this critical security gap by ensuring that the GET handler performs the same authorization checks as the DELETE handler, thereby establishing consistent permission enforcement across all appointment management endpoints. This patch resolves the fundamental inconsistency in the application's access control model and restores proper tenant-scoped authorization for appointment data. The fix aligns with industry best practices for API security and ensures that cryptographic components remain protected from unauthorized access. Organizations using OpenReception should immediately upgrade to version 1.1.0 or later to mitigate this risk, as the vulnerability could enable attackers to reconstruct sensitive patient information through exploitation of the exposed encryption parameters and appointment metadata.