CVE-2026-48088
KrytyczneCVSS 9.4Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 30 - wyżej niż 30% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Organizacja narażona jest na przechwycenie poufnych danych medycznych: nieuwierzytelniony atakujący może odszyfrować treść wizyt, do których został dodany jako odbiorca klucza. Ponadto brak walidacji kluczy pozwala na zatrucie katalogu personelu, co może zakłócić legalne procesy rezerwacji.
Rekomendacja
Niezwłocznie zaktualizuj OpenReception do wersji 1.0.4 lub nowszej, która zawiera poprawkę. Po aktualizacji zweryfikuj, czy w tabeli staff_crypto nie ma nieautoryzowanych wpisów, i rozważ dodanie unikalnych ograniczeń na user_id oraz wzmocnienie walidacji kluczy.
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-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-75525Średnie
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.
- 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. Prior to version 1.0.4, the route `POST /api/tenants/{tenantId}/staff/{staffId}/crypto` accepts and stores attacker-controlled ML-KEM-768 public keys against any tenant on the platform without authentication. The handler logs an "Unauthorized crypto key storage attempt" warning when neither a session nor a registration cookie is present, then proceeds to insert the row regardless. The platform's E2E claim that "even administrators cannot view sensitive information" is broken: any unauthenticated network attacker can register themselves as an additional encryption recipient for any tenant's future patient appointments. A second variant of the bug suppresses the unauthorized-warning log entry. The Zod schema makes the `email` field optional. When the request body omits `email` and the request carries no registration cookie, the comparison `registrationEmail === email` becomes `undefined === undefined`, which evaluates to `true`. The handler treats the request as a legitimate registration flow, skips the warning entirely, and stores the row. Successful storage is still recorded as an `[info]` log line, but the security-relevant warning that operators are most likely to monitor or alert on is gone. The `staff_crypto` table has no unique constraint on `user_id`, so an arbitrary number of attacker rows can coexist for the same staff identifier and all return as `is_active=true`. The supplied `staffId` does not need to match any existing user or pending invite. Schema validation on `passkeyId`, `publicKey`, and `privateKeyShare` is also weak: the literal string `<placeholder-base64>` was accepted, indicating no length, format, or cryptographic-validity check beyond field presence. This weakness is independent of the auth bypass but compounds it: a poisoned directory can also be filled with malformed entries that break legitimate booking flows. The injected key is consumed by the public booking flow. After completing the unauthenticated `bootstrap-challenge` and `bootstrap-verify` ceremony as a "patient", the resulting `bookingAccessToken` is accepted by `GET /api/tenants/{id}/appointments/staff-public-keys`, which returns the attacker-controlled keys alongside any legitimate ones. A new appointment encrypts its tunnel key with ML-KEM to all listed recipients, so the attacker becomes a co-recipient of the encryption and can decapsulate the tunnel key with the matching secret. From there, all appointment payloads for that booking are decryptable. Version 1.0.4 patches the issue.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS