CVE-2026-48086
CriticalCVSS 9.9Exploitation Probability (EPSS)
Low risk26th percentile - higher than 26% of all known CVEs
Summary
A vulnerability in OpenReception's appointment booking software allows a TENANT_ADMIN to promote themselves or another staff member to the platform-wide GLOBAL_ADMIN role via a single PUT request. There is no policy check enforcing that only an existing GLOBAL_ADMIN can grant GLOBAL_ADMIN, so schema validation acts as the authorization decision. After re-login, the tenant admin gains full access to all other tenants on the platform.
Risk Assessment
The risk involves privilege escalation within the platform, enabling unauthorized access to configuration, users, staff records, and tenant lifecycle management of other tenants. This could lead to confidentiality and integrity breaches and full platform takeover.
Recommendation
Immediately upgrade OpenReception to version 1.0.2 or later, which fixes the issue. Additionally, enforce the principle of least privilege and monitor logs for unusual role changes.
Original NVD description (English source)
OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.2, a TENANT_ADMIN promotes themselves to platform-wide GLOBAL_ADMIN through a single PUT request. The role-update handler accepts the `GLOBAL_ADMIN` enum value from any tenant admin updating their own tenant's staff. No policy check enforces that "only an existing GLOBAL_ADMIN may grant GLOBAL_ADMIN", so the schema validation IS the authorization decision. After re-login, the JWT contains the new role and the formerly-tenant-scoped admin reaches every other tenant on the platform. On the hosted OpenReception service this is a scope-changed escalation: a single customer-side tenant administrator gains full platform-wide administrative control over all other tenants' configuration, users, staff records, operational metadata, and tenant lifecycle. Plaintext appointment contents remain subject to the E2E model unless chained with the staff-crypto poisoning issue (V-4) or with staff-passkey hijacking (V-1). On a single-tenant self-hosted deployment it is still a privilege escalation because TENANT_ADMIN should not be able to create new tenants, modify global configuration, or manage other administrators. The same handler also accepts updates targeted at any colleague within the tenant. A tenant admin can promote a separate collaborator account instead of themselves, leaving their own audit trail clean while the platform-wide breach happens through a separate identity. Version 1.0.2 fixes the issue.