CVE-2026-48079
WysokieCVSS 7.4Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 31 - wyżej niż 31% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Ryzyko polega na tym, że sesja pozostaje aktywna po wylogowaniu, co może pozwolić osobie trzeciej na dostęp do konta użytkownika bez jego wiedzy. Może to prowadzić do nieautoryzowanego dostępu do danych lub działań w systemie.
Rekomendacja
Zaktualizuj OpenReception do wersji 1.0.2 lub nowszej, która inicjuje wylogowanie po stronie serwera przed usunięciem ciasteczek uwierzytelniających. Wersja 2.0.0 zastępuje to bezpiecznym przepływem wylogowania po stronie klienta.
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-48080Wysokie
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.
- 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, when a user navigates to the `/logout` page, the page's server-side load handler deletes the `access_token` cookie before calling `/api/auth/logout` via an internal `event.fetch()`. The internal fetch consequently runs without the auth cookie, so `apiAuthHandle` rejects it, the logout handler never executes, and `SessionService.revokeSession()` is never called for the current session. The DB session row remains valid until its natural expiry (one week by default). The user sees a successful logout (cookie gone, UI returns to login), but any party still holding a copy of the now-deleted access token can continue making authenticated API calls until the session naturally expires. The root cause is a simple ordering mistake. The same auth subsystem implements the correct order in `/api/auth/logout`: revoke the current DB session first, then delete the cookie. The page-level wrapper does the opposite. Version 1.0.2 initiates server-side logout before removing authentication cookies and first appears in version 1.0.2. Version 2.0.0 later replaces this with a race-free client-side logout flow.