CVE-2026-48082

W oprogramowaniu OpenReception przed wersją 1.1.1 endpoint POST /api/auth/passkeys przyjmuje userId z treści żądania oraz klucz passkey dostarczony przez atakującego bez uwierzytelnionej sesji, nie wywołuje WebAuthnService.verifyRegistration i nie wiąże rejestracji z locals.user.id. Nieuwierzytelniony atakujący znający publiczny identyfikator tenanta i adres e-mail pracownika może wstrzyknąć kontrolowany klucz publiczny, zidentyfikować pasujący userId i utworzyć sesję STAFF.

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.

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.

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.

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.

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.

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.

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.

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.

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.