EUVD-2026-54147Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Network-exploitable with no auth token required (PR:N); UUID possession is not meaningful access complexity (AC:L); impact limited to individual appointment record confidentiality (C:L), no integrity or availability effect.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
3DescriptionCVE.org
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.
AnalysisAI
Unauthenticated read access to appointment records in OpenReception appointment-booking-software (versions prior to 1.1.0) exposes scheduling metadata and AES-GCM cryptographic components - including encryptedPayload, iv, authTag, and dataKey - to any caller who possesses a valid appointment UUID. The GET handler at /api/tenants/{id}/appointments/{appointmentId} omits the checkPermission() call that the DELETE handler on the same file correctly enforces, and neither the apiAuthHandle nor authGuard middleware compensates because API paths bypass authGuard entirely and apiAuthHandle does not block unauthenticated requests on non-admin routes. No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV, but the CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms zero-friction remote exploitation against any unpatched instance.
Technical ContextAI
The affected product is OpenReception's SvelteKit-based appointment booking platform (EUVD-2026-54147 confirms affected range: appointment-booking-software < 1.1.0). The vulnerable route is implemented in src/routes/api/tenants/[id]/appointments/[appointmentId]/+server.ts, which exports both GET and DELETE request handlers. The DELETE handler correctly calls checkPermission(locals, tenantId, true) before proceeding; the GET handler omitted this call entirely prior to the patch in commit 16474d96c591e246a103b9d6aa15ca30d436d11b. CWE-862 (Missing Authorization) describes this class precisely: a resource operation executes without verifying that the requestor holds the required permission. The middleware pipeline (apiAuthHandle, authGuard) is not a compensating control - API paths bypass authGuard completely, and apiAuthHandle does not enforce token presence on non-admin paths. The data exposed is particularly notable: beyond scheduling metadata and tenant-scoped agent/channel IDs, the response includes the raw AES-GCM key material (encryptedPayload, iv, authTag, dataKey), which could enable decryption of the appointment payload if an attacker obtains both the ciphertext and its associated keying material.
RemediationAI
Upgrade to OpenReception appointment-booking-software version 1.1.0, which adds the missing checkPermission(locals, tenantId, true) call to the GET handler, as confirmed by commit 16474d96c591e246a103b9d6aa15ca30d436d11b and the vendor advisory at https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-8547-9x2c-9vmf. If immediate upgrade is not feasible, operators should apply a reverse proxy or WAF rule requiring a valid authentication token on all requests matching the path pattern /api/tenants/*/appointments/* - note this will block any legitimate unauthenticated consumers of the endpoint, so application behavior must be validated before enforcing this rule in production. A lower-disruption compensating control is to restrict API surface to authenticated network segments (VPN or private subnet), which limits exposure to internal actors without altering the application's authentication behavior. Both workarounds carry operational trade-offs and should be treated as temporary measures pending the 1.1.0 upgrade.
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today