CVE-2026-55834
ŚrednieCVSS 4.3Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 19 - wyżej niż 19% wszystkich znanych CVE
Streszczenie
Pocket ID to dostawca OIDC umożliwiający uwierzytelnianie za pomocą passkeys. Od wersji 2.6.0 do 2.9.0, ścieżka klienta w authorize nie blokuje wszystkich niebezpiecznych schematów URL i nie wywołuje walidacji listy dozwolonych callbacków, co pozwala nieuwierzytelnionemu atakującemu przekierować przeglądarkę ofiary na dowolny zewnętrzny adres HTTP lub HTTPS w celu phishingu lub przemytu błędów i stanu OIDC. Problem naprawiono w wersji 2.9.0.
Ocena ryzyka
Atakujący może wykorzystać to do phishingu lub manipulacji sesją OIDC, co może prowadzić do kradzieży danych lub przejęcia konta.
Rekomendacja
Zaktualizuj Pocket ID do wersji 2.9.0 lub nowszej.
Inne podatności w Pocket ID
Zobacz wszystkie- CVE-2026-62662Wysokie
W Pocket ID od wersji 1.11.0 do 2.10.0 funkcja createTokenFromClientCredentials w backend/internal/service/oidc_service.go akceptuje parametr resource kontrolowany przez klienta i osadza go bezpośrednio w oświadczeniu aud tokenu dostępu bez walidacji, czy odbiorca jest zarejestrowany lub czy klient może uzyskać do niego dostęp. Dowolny uwierzytelniony klient OIDC może uzyskać token podpisany przez Pocket ID wskazujący innego klienta lub dowolnego odbiorcę.
- CVE-2026-115770Krytyczne
Pocket ID to dostawca OIDC umożliwiający logowanie za pomocą passkeys. W wersjach od 2.2.0 do 2.12.0 funkcja SendEmailVerification wiąże token weryfikacji e-mail tylko z identyfikatorem użytkownika, podczas gdy UpdateUser może zmienić adres e-mail bez unieważnienia tokenu, a VerifyEmail oznacza bieżący adres jako zweryfikowany. Zwykły użytkownik może zażądać tokenu dla kontrolowanego adresu, zmienić konto na dowolny nieużywany adres i wykorzystać stary token, aby Pocket ID opublikował nowy adres z email_verified ustawionym na true.
Oryginalny opis (angielski, źródło NVD)
Pocket ID is an OIDC provider that allows users to authenticate with their passkeys to services. From 2.6.0 until 2.9.0, frontend/src/routes/authorize/+page.ts reads the redirect_uri query parameter and frontend/src/routes/authorize/+page.svelte uses the raw callbackURL in redirectWithError when prompt=none cannot complete silent authorization. The client-side path only blocks javascript and data schemes and does not invoke the backend callback allow-list validation, so an unauthenticated attacker who knows a valid client_id can redirect a victim browser to an arbitrary HTTP or HTTPS origin for phishing or OIDC error and state smuggling. This issue is fixed in version 2.9.0.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS