CVE-2026-116678

Vaultwarden do wersji 1.37.3 pomija walidację statusu członkostwa w organizacji w trzech zapytaniach ograniczających dostęp do szyfrów, co pozwala odwołanym i niepotwierdzonym członkom zachować dostęp do odczytu, zapisu, usuwania i załączników do szyfrów organizacji.

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.

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.

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.

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.

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.

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.

W Vaultwarden przed wersją 1.35.5 nie jest wymuszane, aby wpis groups_users.users_organizations_uuid należał do tej samej organizacji co groups.groups_uuid, ani aby wpis collections_groups.collections_uuid należał do tej samej organizacji co collections_groups.groups_uuid. Administrator w organizacji A będący tylko niskouprzywilejowanym członkiem organizacji B może powiązać swoje członkostwo z grupy organizacji A i uzyskać nieautoryzowany dostęp do danych sejfu organizacji B.

Vaultwarden to serwer kompatybilny z Bitwarden napisany w Rust. W wersjach przed 1.35.5 tokeny odświeżania nie są unieważniane, gdy security_stamp użytkownika jest rotowany przez niektóre operacje istotne dla bezpieczeństwa (zmiana hasła, zmiana KDF, rotacja kluczy, zmiana e-mail, reset hasła przez administratora organizacji, przejęcie dostępu awaryjnego). Pozwala to atakującemu posiadającemu wcześniej uzyskany token odświeżania na utrzymanie dostępu do sesji nawet po podjęciu przez użytkownika działań zabezpieczających konto. Podatność została naprawiona w wersji 1.35.5.

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.