EUVD-2026-54168Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Network API reachable with one low-complexity request; only tenant-admin privileges needed (PR:L), no user interaction, and crossing into other tenants' domains justifies S:C with full C/I/A impact.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
4DescriptionCVE.org
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.
AnalysisAI
Privilege escalation in OpenReception's appointment booking platform (versions prior to 1.0.2) lets any TENANT_ADMIN promote an account to platform-wide GLOBAL_ADMIN with a single PUT request to the staff role-update endpoint. Because no policy check enforces that only an existing GLOBAL_ADMIN may grant that role, schema validation alone acts as the authorization gate, and after re-login the attacker's JWT carries platform-wide control over every tenant. No public exploit identified at time of analysis, but the fix is a one-line authorization guard, making the flaw trivially reproducible for anyone reading the GHSA advisory or patch commit.
Technical ContextAI
OpenReception is a SvelteKit-based, end-to-end encrypted, multi-tenant appointment booking service. The vulnerable code lives in the staff role-update handler at src/routes/api/tenants/[id]/staff/[staffId]/+server.ts (the PUT handler). The role field is a TypeScript/schema enum that includes GLOBAL_ADMIN, and the handler treated passing enum validation as sufficient authorization - a textbook CWE-269 (Improper Privilege Management) failure where a data-shape check is mistaken for an access-control decision. Roles are propagated through JWTs issued at login, so an elevated role only takes full effect after the attacker re-authenticates. The fix (commit 8525d35a41c31078d9f01c62e9687e653cf1a494) adds an explicit AuthorizationError thrown whenever updateData.role === "GLOBAL_ADMIN", blocking assignment of that role through this endpoint entirely.
RemediationAI
Vendor-released patch: upgrade to OpenReception 1.0.2, which adds an explicit authorization check rejecting any attempt to assign the GLOBAL_ADMIN role through the staff role-update endpoint (commit 8525d35a41c31078d9f01c62e9687e653cf1a494; advisory GHSA-5qfr-7q4g-3469). If you cannot upgrade immediately, apply the equivalent server-side guard yourself in src/routes/api/tenants/[id]/staff/[staffId]/+server.ts by rejecting PUT requests where role === "GLOBAL_ADMIN" unless the caller is already a GLOBAL_ADMIN - the trade-off is a manual code change that must be re-applied on redeploy. As a compensating control, audit the current staff/role table for any unexpected GLOBAL_ADMIN accounts and for tenant-admin-initiated promotions of colleague accounts (the handler also allows promoting other staff, which can leave the attacker's own audit trail clean), and restrict or monitor access to the tenant staff-management API. Revoke and re-issue JWTs and force re-login after remediation so any already-elevated tokens lose effect.
Same weakness CWE-269 – Improper Privilege Management
View allSame technique Privilege Escalation
View allShare
External POC / Exploit Code
Leaving vuln.today