Luka w popularnym, self-hostowanym serwerze haseł otrzymała ocenę 8.3 w skali CVSS (Common Vulnerability Scoring System — skala 0-10 oceniająca powagę luki). Problem dotyczy Vaultwarden, serwera kompatybilnego z Bitwarden napisanego w języku Rust 1. Ze względu na swoją wydajność i niski koszt, jest to częsty wybór w polskich firmach MŚP oraz wśród entuzjastów technologii do samodzielnego zarządzania hasłami. Błąd w implementacji logowania jednokrotnego może prowadzić do pełnego przejęcia sesji użytkownika.

TL;DR

  • Produkt: Vaultwarden, serwer kompatybilny z Bitwarden.
  • Wektor: Błąd w przepływie autoryzacji SSO (Single Sign-On — logowanie jednokrotne).
  • CVE-ID: CVE-2026-47158.
  • Wskaźniki kompromitacji: Brak publicznych wskaźników. Zalecana jest analiza logów serwera pod kątem nietypowych lub nieudanych prób logowania przez SSO.
  • Kogo dotyczy: Administratorzy instancji Vaultwarden w wersji starszej niż 1.36.0, korzystający z funkcji SSO.
  • Pierwszy ruch: Natychmiastowa aktualizacja do wersji 1.36.0 lub nowszej.

Wektor ataku

Luka oznaczona jako CVE-2026-47158 znajduje się w sposobie, w jaki Vaultwarden obsługuje proces logowania za pomocą zewnętrznego dostawcy tożsamości (IdP), czyli w mechanizmie SSO. W wersjach podatnych na atak, przepływ autoryzacji nie wiązał poprawnie parametru state protokołu OAuth z sesją przeglądarki, która zainicjowała logowanie 2.

Proces ten można opisać jako łańcuch zdarzeń, w którym zabrakło kluczowego ogniwa weryfikującego. Atakujący mógł wykorzystać tę słabość do przeprowadzenia kilku operacji:

  1. Inicjacja logowania: Atakujący rozpoczyna proces logowania SSO na konto ofiary.
  2. Manipulacja parametrami: Z powodu braku powiązania sesji, atakujący mógł przejąć kontrolę nad parametrami PKCE (Proof Key for Code Exchange — mechanizm zabezpieczający OAuth) 3.
  3. Przechwycenie tokenu: Po tym, jak ofiara uwierzytelni się u swojego dostawcy tożsamości, atakujący mógł wykorzystać spreparowane parametry do wymiany kodu autoryzacyjnego na token dostępowy.

Dodatkowym czynnikiem ułatwiającym atak był fakt, że serwer pozostawiał nienaruszone rekordy SsoAuth nawet po nieudanej próbie wymiany tokenu 4. To pozwalało atakującemu na ponawianie prób bez resetowania stanu po stronie serwera.

Konsekwencją jest możliwość uzyskania przez nieautoryzowanego atakującego w pełni uwierzytelnionej sesji w menedżerze haseł 5. Daje to dostęp do wszystkich zapisanych w nim sekretów, haseł i notatek. Dla polskich firm, które używają Vaultwarden do przechowywania kluczy dostępowych do infrastruktury lub danych klientów, jest to scenariusz prowadzący do naruszenia danych w rozumieniu RODO (Rozporządzenie o Ochronie Danych Osobowych).

Wskaźniki kompromitacji

Na ten moment nie opublikowano jednoznacznych wskaźników kompromitacji (IoC — Indicators of Compromise) takich jak adresy IP czy hashe plików. Administratorzy instancji Vaultwarden powinni skupić się na analizie logów serwera.

Należy szukać przede wszystkim:

  • Nietypowych, powtarzających się wpisów dotyczących endpointu /connect/authorize.
  • Logów wskazujących na nieudane wymiany tokenów SSO, po których następowały kolejne próby z tego samego źródła.
  • Korelacji czasowej między logowaniem SSO a nietypową aktywnością na koncie (np. dostęp z nowego adresu IP).

Co zrobić w 24-48h

Rekomendowane podejście zakłada wykonanie poniższych kroków w podanej kolejności. Działania te mają na celu natychmiastowe zamknięcie wektora ataku i weryfikację potencjalnej kompromitacji.

  1. Natychmiastowa aktualizacja: Najważniejszym krokiem jest aktualizacja instancji Vaultwarden do wersji 1.36.0 lub nowszej 6. W tej wersji problem został w pełni załatany. Proces aktualizacji, zwłaszcza w popularnych wdrożeniach opartych o Docker, jest zazwyczaj prosty i sprowadza się do pobrania nowego obrazu i ponownego uruchomienia kontenera.

  2. Analiza logów: Należy przeanalizować logi serwera WWW (np. Nginx, Caddy) oraz samej aplikacji Vaultwarden w poszukiwaniu śladów opisanych w sekcji „Wskaźniki kompromitacji”. Analizę należy przeprowadzić co najmniej dla okresu od momentu wdrożenia wersji podatnej na atak.

  3. Tymczasowe wyłączenie SSO: Jeśli natychmiastowa aktualizacja jest niemożliwa (np. z powodu zależności w środowisku produkcyjnym), należy tymczasowo wyłączyć możliwość logowania przez SSO w konfiguracji Vaultwarden. To zamyka wektor ataku, ale jest rozwiązaniem doraźnym.

  4. Rozważenie rotacji sekretów: Jeśli analiza logów jest niekonkluzywna lub wskazuje na możliwą kompromitację, należy założyć najgorszy scenariusz. Oznacza to konieczność rotacji wszystkich haseł i sekretów przechowywanych w sejfie. Dla polskich podmiotów zobowiązanych do raportowania incydentów, np. do CERT Polska, jest to kluczowy moment decyzyjny.

Źródła

Zobacz też

Przypisy

  1. Vaultwarden to serwer kompatybilny z Bitwarden, napisany w Rust. — nvd.nist.gov › CVE 2026 47158 ↩

  2. Przed wersją 1.36.0, przepływ autoryzacji SSO w Vaultwarden nie wiązał parametru stanu OAuth akceptowanego przez /connect/authorize z inicjującą sesją przeglądarki. — nvd.nist.gov › CVE 2026 47158 ↩

  3. Luka w Vaultwarden pozwalała na kontrolowane przez atakującego parametry PKCE. — nvd.nist.gov › CVE 2026 47158 ↩

  4. Luka w Vaultwarden pozostawiała nienaruszone rekordy SsoAuth po nieudanej wymianie tokenów. — nvd.nist.gov › CVE 2026 47158 ↩

  5. Nieautoryzowany atakujący mógł wykorzystać tę lukę do wywołania uwierzytelnienia IdP i wymiany tokenów na w pełni uwierzytelnioną sesję. — nvd.nist.gov › CVE 2026 47158 ↩

  6. Problem został naprawiony w wersji 1.36.0 Vaultwarden. — nvd.nist.gov › CVE 2026 47158 ↩