CVE-2026-48086
KrytyczneCVSS 9.9Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 26 - wyżej niż 26% wszystkich znanych CVE
Streszczenie
Podatność w oprogramowaniu do rezerwacji wizyt OpenReception pozwala administratorowi dzierżawy (TENANT_ADMIN) na awansowanie siebie lub innego pracownika do roli globalnego administratora (GLOBAL_ADMIN) poprzez pojedyncze żądanie PUT. Brakuje kontroli uprawnień, która wymagałaby, aby tylko istniejący GLOBAL_ADMIN mógł nadawać tę rolę. Po ponownym zalogowaniu administrator dzierżawy uzyskuje pełny dostęp do wszystkich innych dzierżaw na platformie.
Ocena ryzyka
Ryzyko obejmuje eskalację uprawnień w obrębie platformy, umożliwiającą nieautoryzowany dostęp do konfiguracji, użytkowników, danych pracowników i zarządzania cyklem życia innych dzierżaw. Może to prowadzić do naruszenia poufności i integralności danych oraz przejęcia kontroli nad całą platformą.
Rekomendacja
Należy natychmiast zaktualizować OpenReception do wersji 1.0.2 lub nowszej, która zawiera poprawkę. Dodatkowo, wdrożyć zasadę najmniejszych uprawnień i monitorować logi pod kątem nietypowych zmian ról.
Oryginalny opis (angielski, źródło NVD)
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.

