Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-06T22:17:10.267Z",
  "pubdate": "2026-08-06T22:17:10.267Z",
  "executiveSummary": "OpenReception appointment booking software prior to version 1.1.0 suffers from a broken object level authorization vulnerability within its API routing architecture. Specifically, the GET handler located at the endpoint /api/tenants/{id}/appointments/{appointmentId} fails to enforce access control checks before querying and returning sensitive appointment records. Consequently, any unauthenticated or unauthorized party who obtains a valid appointment UUID can retrieve the complete database row. The impacted data includes channel IDs, agent IDs, timestamps, timezones, status indicators, and critical cryptographic components of the end-to-end encryption scheme, namely encryptedPayload, iv, authTag, and dataKey. While the corresponding DELETE handler properly invokes checkPermission(locals, tenantId, true) to enforce tenant scoping, the GET handler omits this crucial validation. Furthermore, underlying middleware components such as apiAuthHandle and authGuard fail to compensate for this deficiency, as API paths completely bypass authGuard and apiAuthHandle permits requests to non-admin endpoints in the absence of valid authentication tokens. An attacker possessing valid appointment UUIDs can systematically harvest sensitive operational data and cryptographic ciphertext without holding any privileges or meeting authentication requirements. This exposure compromises confidentiality guarantees and undermines the platform's end-to-end encryption model by leaking associated cipher parameters to unauthorized entities.",
  "technicalDetails": "The vulnerability resides in the API routing and controller logic of OpenReception prior to version 1.1.0, specifically affecting the GET handler servicing the /api/tenants/{id}/appointments/{appointmentId} endpoint. The root cause of the flaw is the complete omission of authorization validation logic within the GET request lifecycle. Unlike the corresponding DELETE handler in the same file, which correctly executes the checkPermission(locals, tenantId, true) function to verify tenant-scoped access rights, the GET handler directly queries and exposes the appointment record upon receiving a matching UUID. The middleware chain provides no compensatory controls to mitigate this authorization bypass. The authGuard middleware completely bypasses API paths, while the apiAuthHandle middleware fails to restrict requests to non-administrative endpoints when an authentication token is absent or omitted entirely. Exploitation requires network exposure to the HTTP API and knowledge or acquisition of a valid appointment UUID. Because appointment UUIDs act as the sole determinant for record retrieval without validating whether the requester belongs to the relevant tenant or possesses a valid session, the attack flow is direct and stealthy. An adversary crafts an HTTP GET request targeting /api/tenants/{id}/appointments/{appointmentId} using a target appointment UUID. The vulnerable endpoint processes the request without evaluating caller context, session state, or tenancy boundaries. The server subsequently responds with a full JSON object containing operational metadata and sensitive cryptographic primitives, including the AES-GCM encryptedPayload, initialization vector (iv), authentication tag (authTag), and the data key (dataKey). Post-exploitation impact encompasses the unauthorized disclosure of metadata regarding appointments, communication channels, and agent assignments. Furthermore, exposing the AES-GCM ciphertext components and data keys introduces severe risks to the end-to-end encryption architecture, potentially facilitating offline cryptographic attacks or unauthorized data decryption if auxiliary weaknesses exist within key management or entropy generation."
}