CVE-2026-48083

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.

W OpenReception w wersjach 2.1.0 i starszych nieuwierzytelniony atakujący może zapisać dowolny klucz publiczny ML-KEM-768 pod tożsamością dowolnego istniejącego użytkownika w katalogu odbiorców staff-crypto dowolnego tenanta. Projekt gwarantuje, że dane spotkań są szyfrowane end-to-end do pracowników, a katalog odbiorców nie jest zapisywalny przez atakującego, więc nawet administratorzy i operator nie mogą czytać danych pacjentów. Ten endpoint łamie tę gwarancję dla nieuwierzytelnionego zdalnego aktora: pozwala zapisać dowolnego odbiorcę szyfrowania do katalogu odbiorców dowolnego tenanta. Wstrzyknięty klucz otrzymuje klucz tunelu każdego spotkania zarezerwowanego później w tym tenancie, ponieważ klienci rezerwacji szyfrują do wszystkich aktywnych kluczy pracowników. Atakujący posiada odpowiadający klucz tajny i jest trwałym, nieautoryzowanym odbiorcą tego materiału kluczowego. W momencie publikacji brak publicznie dostępnych poprawek.

W OpenReception przed wersją 2.2.2 atakujący może przepełnić rezerwacje agenta, umieszczając wiele spotkań w jednym przedziale czasowym, który system ma utrzymywać jako wyłączny. Liczba nakładających się spotkań równa się liczbie równoczesnych żądań, a jeden token rezerwacji wystarczy, ponieważ token jest zużywany po wstawieniu. Powoduje to naruszenie integralności kalendarza rezerwacji i odmowę dostępności innym klientom. Problem naprawiono w wersji 2.2.2.

W OpenReception w wersjach 2.1.0 i starszych sześciocyfrowy PIN rezerwacji powracającego klienta można zgadnąć metodą brute-force online w obrębie tenanta ofiary. Udane zgadnięcie daje token dostępu do rezerwacji klienta, a tym samym dostęp do jego tunelu spotkań z danymi szyfrowanymi end-to-end oraz możliwość działania w imieniu klienta, np. dodawania lub anulowania spotkań. Obejście ma charakter międzytenantowy — stan jednego tenanta usuwa zabezpieczenie uwierzytelniania innego tenanta. W momencie publikacji brak publicznie dostępnych poprawek.

W OpenReception przed wersją 2.2.1 atakujący, który przechwyci oczekujący token zaproszenia, może go odtworzyć, aby uzyskać poświadczenie rejestracji passkey i zarejestrować własny passkey na zaproszonym koncie, przejmując nad nim kontrolę. Dla zaproszenia pracownika lub administratora tenanta daje to dostęp do kontekstu tenanta powiązanego z tym kontem. Problem naprawiono w wersji 2.2.1.

W OpenReception przed wersją 2.0.0 link potwierdzający konto w e-mailach jest budowany z nagłówka Host żądania bez listy dozwolonych. Nieuwierzytelniony POST /api/auth/resend-confirmation rotuje token potwierdzenia oczekującego zaproszonego i wysyła e-mail z linkiem, którego host pochodzi z żądania. Atakujący wysyłając jedno żądanie z Host: attacker.example i adresem e-mail oczekującego zaproszonego powoduje, że ofiara otrzymuje e-mail, którego jedyny link prowadzi do atakującego; po kliknięciu jednorazowy token trafia do atakującego, który potwierdza konto na prawdziwej domenie tenanta i rejestruje własny passkey, przejmując konto. Wszystkie wydane wersje do v1.1.0 są podatne; brak poprawki. Osiągnięcie aplikacji ze sfałszowanym Host zależy od frontowego proxy: domyślny Caddy catch-all przekazuje go, a operator z jawnymi blokami proxy per tenant nie jest podatny. Problem naprawiono w wersji 2.0.0.