CVE-2026-48080
WysokieCVSS 8.0Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 20 - wyżej niż 20% wszystkich znanych CVE
Streszczenie
Podatność w OpenReception przed wersją 1.0.2 ujawnia pełny rekord dzierżawcy (tenant) przez endpoint `GET /api/tenants/{id}` każdemu uwierzytelnionemu administratorowi tego dzierżawcy, w tym pole `databaseUrl` zawierające string połączenia z bazą PostgreSQL. W domyślnym wdrożeniu docker-compose string zawiera użytkownika `postgres` z uprawnieniami superusera i hasło w plaintext, co pozwala na pełny dostęp do wszystkich baz danych w instancji PostgreSQL.
Ocena ryzyka
Administrator jednego dzierżawcy może odczytać, zmodyfikować lub usunąć dane wszystkich innych dzierżawców, w tym zaszyfrowane wizyty, klucze, metadane oraz centralną tabelę użytkowników z hasłami i sesjami. Może też eskalować uprawnienia w kontenerze bazy danych, co całkowicie łamie izolację między dzierżawcami.
Rekomendacja
Niezwłocznie zaktualizuj OpenReception do wersji 1.0.2 lub nowszej. Jeśli nie możesz zaktualizować, ogranicz dostęp do endpointu `GET /api/tenants/{id}` i rozważ użycie mniej uprzywilejowanego użytkownika PostgreSQL dla połączeń aplikacji.
Inne podatności w OpenReception
Zobacz wszystkie- CVE-2026-48088Krytyczne
Przed wersją 1.0.4 oprogramowania OpenReception do rezerwacji wizyt, nieuwierzytelniony atakujący mógł przechowywać własne klucze publiczne ML-KEM-768 dla dowolnego najemcy, bez logowania. Nawet bez ciasteczka sesji lub rejestracji, żądanie POST do /api/tenants/{tenantId}/staff/{staffId}/crypto zapisywało klucz, a wariant z pominięciem pola email całkowicie ukrywał ostrzeżenie o nieautoryzowanej próbie. To łamie deklarację szyfrowania end-to-end, ponieważ atakujący staje się dodatkowym odbiorcą szyfrowania przyszłych wizyt pacjentów.
- CVE-2026-48087Krytyczne
Podatność w OpenReception (przed wersją 1.0.2) w rejestracji WebAuthn pozwala nieuwierzytelnionemu atakującemu na przypisanie własnego poświadczenia do konta ofiary poprzez manipulację parametrem userId w URL. Walidacja nie sprawdza, czy userId należy do adresu email z ciasteczka.
- CVE-2026-48086Krytyczne
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.
- CVE-2026-48085Krytyczne
Oprogramowanie do rezerwacji wizyt OpenReception przed wersją 1.0.1 pozwala nieuwierzytelnionemu atakującemu na utworzenie konta GLOBAL_ADMIN poprzez wysłanie żądania POST do `/setup/create-admin-account`, bez weryfikacji, czy administrator już istnieje. Atakujący może uzyskać pełną kontrolę administracyjną nad platformą, a nowe konto jest aktywne i nie wymaga potwierdzenia e-mail.
- CVE-2026-48084Wysokie
OpenReception przed wersją 1.0.2 nie ogranicza liczby nieudanych prób logowania hasłem. Atakujący może wysyłać nieograniczoną liczbę błędnych haseł dla znanego adresu e-mail, z szybkością około 10 prób na sekundę. Brak throttlingu w gałęzi hasła, podczas gdy endpoint WebAuthn ma throttling, umożliwia ataki brute-force i słownikowe na konta użytkowników. Problem naprawiono w wersji 1.0.2.
- CVE-2026-48083Średnie
Oprogramowanie do rezerwacji wizyt OpenReception przed wersją 1.0.2 ma podatność w punkcie końcowym `/api/log`, który akceptuje nieuwierzytelnione żądania POST, nie stosuje walidacji schematu do treści wiadomości, zapisuje treść kontrolowaną przez atakującego bezpośrednio do dziennika stdout aplikacji, interpretuje znaki nowej linii jako rzeczywiste przerwy linii i nie egzekwuje limitów rozmiaru ani szybkości. Istnieją trzy tryby nadużycia: wstrzykiwanie logów (fałszowanie wpisów logów), DoS przez zalanie logów (setki żądań na sekundę) oraz przesyłanie bardzo dużych danych (100 KB). Najbardziej szkodliwy jest wstrzykiwanie logów, umożliwiające atakującemu wstrzyknięcie fałszywych wpisów, które operator może pomylić z prawdziwymi błędami systemowymi, maskując własną aktywność lub zanieczyszczając reguły alertów SIEM. Wersja 1.0.2 naprawia problem.
- CVE-2026-48082Niskie
OpenReception przed wersją 1.0.6 ma zbyt słaby proof-of-work (16 bitów) w endpointcie bootstrap-challenge, co pozwala na łatwe obejście rate-limitu i automatyzację ataków na proces rezerwacji.
- CVE-2026-48081Wysokie
Przed wersją 1.0.2 oprogramowania OpenReception do rezerwacji wizyt, administrator dzierżawy (TENANT_ADMIN) może zapisać adresy URL `javascript:` w konfiguracji linków (`website`, `imprint`, `privacyStatement`). Te wartości są zwracane na stronę pacjenta przez `/api/public`, osadzane w komponencie SvelteKit Button i renderowane jako `<a href="javascript:...">` bez filtrowania schematu URL. Kliknięcie takiego linku przez pacjenta powoduje wykonanie skryptu atakującego w przeglądarce pacjenta, gdzie dane formularza są odczytywane przed szyfrowaniem po stronie klienta.
- CVE-2026-48079Wysokie
Przed wersją 1.0.2 OpenReception, podczas nawigacji do strony `/logout`, handler ładowania po stronie serwera usuwa ciasteczko `access_token` przed wywołaniem `/api/auth/logout` przez wewnętrzny `event.fetch()`. Wewnętrzne żądanie jest wykonywane bez ciasteczka uwierzytelniającego, więc `apiAuthHandle` odrzuca je, handler wylogowania nie wykonuje się, a `SessionService.revokeSession()` nie jest wywoływany dla bieżącej sesji. Sesja w bazie danych pozostaje ważna do naturalnego wygaśnięcia (domyślnie tydzień). Użytkownik widzi poprawne wylogowanie (ciasteczko usunięte, UI wraca do logowania), ale każda strona posiadająca kopię usuniętego tokena może kontynuować uwierzytelnione wywołania API do naturalnego wygaśnięcia sesji.
- CVE-2026-48078Średnie
Przed wersją 1.0.5 nieuwierzytelniony endpoint `/api/tenants/{id}/schedule` zwraca wszystkie niearchiwizowane kanały dla dzierżawcy, ignorując flagę `isPublic`. Kanały oznaczone jako `isPublic = false` są celowo ukrywane przed publicznymi użytkownikami, ale endpoint ujawnia ich nazwy, opisy, identyfikatory, powiązania z agentami, status pauzy, wymagania potwierdzenia oraz dostępność slotów. Wersja 1.0.5 naprawia ten problem.
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, the `GET /api/tenants/{id}` endpoint returns the full tenant record to any authenticated `TENANT_ADMIN` of that tenant, including the `databaseUrl` field. This field contains the live PostgreSQL connection string the application uses to connect to that tenant's database. In the tested official `docker-compose.prod.yml` deployment, the connection string contained the user `postgres` with `rolsuper=true` and the plaintext password from `secrets/postgres_password.txt`. Operators who configure a non-superuser PostgreSQL user via `secrets/postgres_user.txt` would expose a less privileged credential, but the disclosure of the connection string itself is independent of that choice. The same credential applies to every database managed by that PostgreSQL instance: the central `appointment_booking` database, every per-tenant database (one per tenant), and the postgres administrative database. A `TENANT_ADMIN` of one tenant who can reach `postgres:5432` (directly via internal network, indirectly via any SSRF, RCE, or file-read in the application) can read every other tenant's appointment ciphertexts, key shares, and metadata; read the central user table, including all `GLOBAL_ADMIN` accounts, password hashes, and session records; modify or delete any data in any tenant database; and/or i a superuser-scoped deployment: use PostgreSQL's `pg_read_server_files`, `COPY ... FROM PROGRAM`, and `CREATE EXTENSION` for further escalation inside the database container. This breaks the per-tenant database isolation that is otherwise the primary cross-tenant control in the application. The application code carefully scopes most queries to the calling tenant's database, but those scopings are irrelevant once the attacker holds the credentials that bypass the application entirely. Version 1.0.2 fixes the issue.