CVE-2026-47164
WysokieCVSS 7.7Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 19 - wyżej niż 19% wszystkich znanych CVE
Streszczenie
Podatność w Vaultwarden przed wersją 1.36.0 umożliwia atakującemu przejęcie konta ofiary poprzez SSO. Problem wynika z braku weryfikacji atrybutu email_verified od IdP podczas łączenia tożsamości z istniejącym kontem lokalnym.
Ocena ryzyka
Atakujący może podszyć się pod adres e-mail ofiary i zalogować się na jej konto, co prowadzi do nieautoryzowanego dostępu do przechowywanych haseł i innych poufnych danych.
Rekomendacja
Należy niezwłocznie zaktualizować Vaultwarden do wersji 1.36.0 lub nowszej, która zawiera poprawkę usuwającą tę lukę.
Inne podatności w Vaultwarden
Zobacz wszystkie- CVE-2026-43914Wysokie
W Vaultwarden, przed wersją 1.35.4, występuje podatność, która pozwala na ominięcie ochrony przed atakami brute-force na logowanie, jeśli włączona jest dwuetapowa weryfikacja (2fa) przez e-mail. Funkcja 2fa send_email_login działa jako oracle, co umożliwia atakującym testowanie kombinacji nazwy użytkownika i hasła bez ograniczeń czasowych.
- CVE-2026-43913Wysokie
Vaultwarden, serwer kompatybilny z Bitwarden, przed wersją 1.35.5 pozwalał niepotwierdzonemu właścicielowi organizacji na usunięcie całego skarbca organizacji. Proces zapraszania do organizacji nie weryfikował statusu potwierdzenia, co umożliwiało usunięcie danych przez użytkownika zaproszonego jako właściciel.
- CVE-2026-43912Wysokie
Vaultwarden przed wersją 1.35.5 nie weryfikuje, czy wpisy dotyczące użytkowników i grup należą do tej samej organizacji, co prowadzi do możliwości nieautoryzowanego dostępu do danych w skarbcu innej organizacji.
- CVE-2026-47160Średnie
Podatność SSRF w Vaultwarden przed wersją 1.36.0 pozwalała na ominięcie walidacji adresów IP w formacie dziesiętnym, szesnastkowym i ósemkowym podczas pobierania ikon, co umożliwiało skanowanie wewnętrznych portów i sieci.
- CVE-2026-47159Średnie
Podatność w Vaultwarden przed wersją 1.36.0 umożliwiała wyciek metadanych SSO organizacji, w tym identyfikatora organizationIdentifier, dla dowolnych adresów e-mail. Pozwalało to na uzyskanie ważnego tokena JWT do pre-walidacji SSO, co ułatwiało enumerację organizacji i nadużycie procesu uwierzytelniania.
- CVE-2026-47158Wysokie
Podatność w Vaultwarden przed wersją 1.36.0 umożliwia nieuwierzytelnionemu atakującemu przejęcie sesji użytkownika poprzez manipulację przepływem autoryzacji SSO. Brak powiązania parametru OAuth state z sesją przeglądarki oraz akceptacja kontrolowanych przez atakującego parametrów PKCE pozwalają na wywołanie uwierzytelnienia u dostawcy tożsamości i przechwycenie tokenów.
- CVE-2026-33420Średnie
Vaultwarden w wersji 1.35.4 i wcześniejszych ma brak sprawdzenia has_full_access() w punkcie końcowym get_org_collections_details (GET /api/organizations/{org_id}/collections/details), które istnieje w pokrewnym punkcie get_org_collections. Pozwala to użytkownikom z rolą Manager z accessAll=False i bez przypisanych kolekcji na pobranie nazw, UUID, mapowań użytkownik-kolekcja i grupa-kolekcja dla wszystkich kolekcji w organizacji. Problem został naprawiony w wersji 1.35.5.
- CVE-2026-31835Średnie
Vaultwarden w wersji 1.35.4 i wcześniejszych zawiera podatność w przepływie uwierzytelniania WebAuthn. Funkcja validate_webauthn_login() aktualizuje trwałe metadane poświadczeń (flagi backup_eligible i backup_state) na podstawie niezweryfikowanego authenticatorData przed walidacją podpisu. Atakujący znający hasło użytkownika, ale nie mogący wygenerować prawidłowego podpisu WebAuthn, może trwale zmodyfikować flagi kopii zapasowej dla danego poświadczenia. Jeśli weryfikacja podpisu nie powiedzie się, aktualizacja bazy danych nie jest wycofywana. Może to prowadzić do trwałej odmowy usługi uwierzytelniania dwuskładnikowego WebAuthn. Problem naprawiony w wersji 1.35.5.
Oryginalny opis (angielski, źródło NVD)
Vaultwarden is a Bitwarden-compatible server written in Rust. Prior to 1.36.0, Vaultwarden's SSO login flow checked the IdP email_verified claim only for new-user creation and not when SSO_SIGNUPS_MATCH_EMAIL=true linked an IdP identity to an existing local account, allowing an attacker-controlled IdP identity asserting a victim email address to bind to and authenticate as that account. This issue is fixed in version 1.36.0.

