Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-06T22:17:11.593Z",
  "pubdate": "2026-08-06T22:17:11.593Z",
  "executiveSummary": "A privilege escalation vulnerability exists in OpenReception appointment booking software prior to version 1.0.2.\nThe vulnerability allows a TENANT_ADMIN to promote themselves or a collaborator to a platform-wide GLOBAL_ADMIN through a single PUT request.\nThis occurs because the role-update handler accepts the GLOBAL_ADMIN enum value without enforcing a policy check that only an existing GLOBAL_ADMIN may grant this role.\nThe impact includes full platform-wide administrative control over all other tenants' configurations, users, staff records, operational metadata, and tenant lifecycle in hosted environments.\nOn single-tenant self-hosted deployments, it allows unauthorized creation of new tenants, modification of global configurations, and management of other administrators.\nAttacker capabilities require authenticated access as a TENANT_ADMIN, enabling them to alter role parameters within API requests.\nRemediation requires updating OpenReception to version 1.0.2.",
  "technicalDetails": "The vulnerability resides within the role-update handler of OpenReception prior to version 1.0.2.\nThe root cause is an improper authorization check where the application relies solely on schema validation rather than enforcing an explicit access control policy.\nSpecifically, the role-update handler accepts the GLOBAL_ADMIN enum value from any TENANT_ADMIN updating their own tenant's staff or when targeting any colleague within the tenant.\nThe lack of a policy check ensuring that only an existing GLOBAL_ADMIN can grant the GLOBAL_ADMIN role allows the schema validation itself to act as the authorization decision.\nThe exploitation method involves sending a crafted PUT request containing the GLOBAL_ADMIN enum value.\nAn attacker with TENANT_ADMIN privileges can either promote themselves directly or promote a separate collaborator account to keep their own audit trail clean.\nUpon re-login, the generated JSON Web Token (JWT) contains the newly acquired GLOBAL_ADMIN role.\nThis grants the formerly tenant-scoped administrator cross-tenant access across the platform.\nIn hosted environments, this scope-changed escalation permits access to all other tenants' configurations, users, staff records, operational metadata, and tenant lifecycles.\nPlaintext appointment contents remain protected by the end-to-end encryption model unless combined with additional issues such as staff-crypto poisoning or staff-passkey hijacking.\nThe affected component is the role-update handler in versions prior to 1.0.2."
}