A TENANT_ADMIN in OpenReception's appointment booking software can promote themselves to a platform-wide GLOBAL_ADMIN by sending a single PUT request that updates the user’s role to the GLOBAL_ADMIN enum. Because the system performs only schema validation and imposes no policy check, anyone with tenant-administrator permissions can grant themselves global‑level privileges. Once re‑authenticated, the JSON Web Token contains the new role, enabling the former tenant‑scoped admin to access every other tenant’s configuration, users, staff records, operational metadata, and tenant lifecycle settings. The vulnerability exists prior to version 1.0.2 and allows an attacker to gain unrestricted administrative control across the entire platform.

The vulnerability affects the open-reception:appointment‑booking‑software product in all releases before 1.0.2. Any deployment—whether hosted on the OpenReception service or a single‑tenant self‑hosted instance—is susceptible because the enterprise‑wide role update handler is reachable by any tenant administrator. Users should identify whether their installation uses a pre‑1.0.2 version and assess the scope of tenant‑admin accounts. A tenant administrator with this flaw can alter global configuration, create tenants, manage other administrators, and compromise the entire platform’s confidentiality, integrity, or availability.

The flaw carries a CVSS score of 9.9, indicating critical severity. Exploitation requires only that a tenant administrator has the ability to issue a role‑update request, which is typically available to users who can manage staff within their own tenant. The EPSS score is not available, so no current estimate of exploitation probability is provided, but the absence of a KEV listing does not mitigate the high potential impact. Once exploited, the attacker gains full platform ownership, and can perform any action that a legitimate GLOBAL_ADMIN can, including creating new tenants, editing global settings, and accessing all user data. The attack path is straightforward: send a validated PUT request to the role‑update endpoint, then re‑login to obtain a JWT reflecting the new role. The setting of the GLOBAL_ADMIN flag is the sole authorization decision, so the vulnerability is a classic example of improper privilege management (CWE‑269).