CVE-2026-34834
WysokieCVSS 7.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 17 - wyżej niż 17% wszystkich znanych CVE
Streszczenie
Bulwark Webmail przed wersją 1.4.10 zawiera podatność w funkcji verifyIdentity(), która zwracała true przy braku ciasteczek sesyjnych. Pozwala to nieuwierzytelnionym atakującym na ominięcie zabezpieczeń i dostęp do endpointu /api/settings, umożliwiając modyfikację ustawień użytkownika.
Ocena ryzyka
Nieuwierzytelnieni atakujący mogą zmieniać ustawienia użytkowników, co może prowadzić do przejęcia konta lub wycieku danych.
Rekomendacja
Należy zaktualizować Bulwark Webmail do wersji 1.4.10 lub nowszej.
Inne podatności w Bulwark Webmail
Zobacz wszystkie- CVE-2026-35391Wysokie
W Bulwark Webmail przed wersją 1.4.11 funkcja getClientIP() ufa pierwszemu (najbardziej lewemu) wpisowi nagłówka X-Forwarded-For, który jest w pełni kontrolowany przez klienta. Atakujący może sfałszować źródłowy adres IP, aby ominąć ograniczniki szybkości oparte na IP (umożliwiając ataki brute-force na panel administracyjny) lub sfałszować wpisy w dzienniku audytu.
- CVE-2026-35390Średnie
Bulwark Webmail przed wersją 1.4.11 ustawia nagłówek Content-Security-Policy-Report-Only zamiast egzekwującego Content-Security-Policy. Oznacza to, że ataki XSS są logowane, ale nie blokowane, co pozwala na wykonanie dowolnego JavaScript przez spreparowany HTML wiadomości e-mail.
- CVE-2026-35389Wysokie
W Bulwark Webmail przed wersją 1.4.11 weryfikacja podpisu S/MIME nie sprawdzała łańcucha zaufania certyfikatu, przez co każdy e-mail podpisany samopodpisanym lub niezaufanym certyfikatem był wyświetlany jako mający ważny podpis.
- CVE-2026-34833Wysokie
Bulwark Webmail przed wersją 1.4.10 ujawniał hasło użytkownika w postaci jawnego tekstu w odpowiedzi JSON z endpointu GET /api/auth/session. To narażało dane logowania na przechwycenie przez przeglądarkę, lokalne pamięci podręczne i proxy sieciowe.
Oryginalny opis (angielski, źródło NVD)
Bulwark Webmail is a self-hosted webmail client for Stalwart Mail Server. Prior to version 1.4.10, the verifyIdentity() function contained logic that returned true if no session cookies were present. This allowed unauthenticated attackers to bypass security checks and access/modify user settings via the /api/settings endpoint by providing arbitrary headers. This issue has been patched in version 1.4.10.

