OpenReception EUVD-2026-54168

Requires an authenticated account holding the TENANT_ADMIN role on the target OpenReception instance (any tenant on the hosted service). The concrete prerequisite is access to the staff role-update endpoint PUT /api/tenants/[id]/staff/[staffId] with a request body setting role to the GLOBAL_ADMIN enum value; no non-default configuration, feature flag, or user interaction is needed, and the target can be the attacker's own account or any colleague within the same tenant. Limiting factors: the attacker must already possess valid tenant-admin credentials (not unauthenticated), the elevated role only takes effect after re-login because the role is carried in the JWT, and the cross-tenant impact is only realized on multi-tenant (hosted) deployments - on a single-tenant self-hosted install it is a lower-impact local privilege escalation. Note that plaintext appointment contents remain protected by the E2E model unless this is chained with the staff-crypto poisoning issue (V-4) or staff-passkey hijacking (V-1).

The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H yields 9.9 (Critical), and the metrics are internally consistent with the description: network-reachable API (AV:N), a single low-complexity request (AC:L), only tenant-admin privileges required (PR:L), no victim interaction (UI:N), and a genuine scope change (S:C) because a tenant-scoped identity crosses into other tenants' security domains. The confidentiality/integrity/availability impacts are all High and well-justified given full platform administrative control. EPSS and KEV data were not provided; there is no evidence of active exploitation, so this should be treated as a high-priority latent risk rather than a confirmed in-the-wild threat. The main tempering factor is that exploitation requires an existing valid TENANT_ADMIN account - this is not an unauthenticated internet attack - but on the hosted multi-tenant service any single paying customer's admin becomes the adversary, which is a severe trust-boundary break. On single-tenant self-hosted installs the scope-change premium does not fully apply, lowering real-world impact to a local-tenant privilege escalation.

A legitimate customer signs up for a tenant on the hosted OpenReception service and receives a normal TENANT_ADMIN account. They send one PUT request to their own tenant's staff endpoint setting their role (or a disposable collaborator's role) to GLOBAL_ADMIN, which passes schema validation and is accepted. After logging out and back in, their JWT now carries GLOBAL_ADMIN, granting full administrative control over every other tenant's configuration, users, staff records, and tenant lifecycle. No public exploit code is required - the request is a trivial role-field change.