CVE-2026-75525
ŚrednieCVSS 5.3Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 7 - wyżej niż 7% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Atakujący może trwale odszyfrowywać dane spotkań rezerwowanych po wstrzyknięciu klucza, łamiąc gwarancję poufności end-to-end. Brak poprawek oznacza konieczność wdrożenia własnych środków zaradczych.
Rekomendacja
Ogranicz dostęp do endpointu zapisu katalogu odbiorców staff-crypto i monitoruj zmiany w katalogu pod kątem nieznanych kluczy. Do czasu wydania poprawki rozważ rotację kluczy i audyt istniejących wpisów.
Inne podatności w OpenReception
Zobacz wszystkie- CVE-2026-54460Krytyczne
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.
- 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-75524Średnie
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.
- CVE-2026-65825Wysokie
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.
- CVE-2026-65824Wysokie
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.
- CVE-2026-58202Wysokie
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.
- 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.
Oryginalny opis (angielski, źródło NVD)
OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. In versions 2.1.0 and prior, an unauthenticated attacker can store an arbitrary ML-KEM-768 public key under any existing user's identity in any tenant's staff-crypto recipient directory. The product's design guarantees that appointment data is end-to-end encrypted to staff members and that the staff recipient directory is not attacker-writable, so that even administrators and the operator cannot read patient data. This endpoint breaks that guarantee for an unauthenticated remote actor: it allows writing an arbitrary encryption recipient into the recipient directory of any tenant. The injected key receives the tunnel key of every appointment booked afterward in that tenant, because booking clients encrypt to all active staff keys. The attacker holds the corresponding secret key and is a persistent, unauthorized recipient of that key material. At time of publication, there are no publicly available patches.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS