Przechowywany XSS ukryty na widoku

Nowo ujawniona podatność w Zimbra Collaboration Suite daje zespołom bezpieczeństwa powód, by dwukrotnie sprawdzić dzienniki poprawek. Śledzona jako CVE-2025-66376 luka to przechowywany cross-site scripting (XSS) w klasycznym kliencie webowym – starszym, opartym na HTML interfejsie, wciąż używanym w wielu wdrożeniach Zimbry równolegle z nowoczesną aplikacją webową.

Tę lukę wyróżnia to, jak niewiele ofiara musi zrobić, by ją wyzwolić. Według ujawnionych informacji samo otwarcie złośliwej wiadomości w klasycznym interfejsie wystarczy, aby w uwierzytelnionej sesji poczty webowej ofiary uruchomił się kod kontrolowany przez atakującego. Stamtąd atakujący może pobrać tokeny sesyjne, hasła przechowywane w przeglądarce, a nawet kody zapasowe uwierzytelniania dwuskładnikowego – te kody awaryjne, na których polegają użytkownicy, gdy ich główna metoda 2FA nie jest dostępna.

Jak działa atak

Podatności typu stored XSS są szczególnie groźne, ponieważ złośliwy ładunek nie musi być klikany ani pobierany oddzielnie. Jest on osadzany bezpośrednio w treści, którą klient pocztowy renderuje automatycznie – w tym przypadku poprzez dyrektywy kaskadowych arkuszy stylów (CSS) wstawione do wiadomości. Klasyczny klient webowy Zimbry nie oczyszczał prawidłowo tej zawartości, co pozwalało, aby CSS wykonał JavaScript w kontekście sesji skrzynki zalogowanego użytkownika.

Gdy ten kod się uruchomi, dziedziczy wszystko, do czego sesja ofiary już ma dostęp. To właśnie umożliwia mu sięgnięcie poza skrzynkę odbiorczą i przechwycenie tokenów uwierzytelniających, poświadczeń zapisanych w przeglądarce oraz kodów zapasowych 2FA przechowywanych na potrzeby odzyskiwania konta. W praktyce jedno otwarte e-mail przekształca się w potencjalne pełne przejęcie konta, bez wpisywania przez ofiarę hasła czy klikania podejrzanego łącza.

To nie pierwszy raz, gdy obsługa osadzanej zawartości w klasycznym kliencie webowym przysparza problemów. Zimbra musiała już wcześniej łatać podobne problemy z oczyszczaniem HTML i plików ICS w tym samym interfejsie – schemat, który podkreśla, dlaczego organizacje wciąż korzystające ze starszego klienta są narażone cyklicznie, dopóki nie zaczną agresywnie instalować poprawek lub nie zrezygnują z niego całkowicie.

Kto musi działać

Podatność dotyczy Zimbra Collaboration (ZCS) 10 przed wersją 10.0.18 oraz 10.1 przed wersją 10.1.13. Zimbra opublikowała poprawione kompilacje, a jej własny komunikat bezpieczeństwa opisuje łatkę jako adresującą krytyczną podatność stored XSS w klasycznym kliencie webowym. Organizacje korzystające z podatnych wersji powinny potraktować tę aktualizację priorytetowo, a nie planować ją na najbliższe rutynowe okno serwisowe, ponieważ wykorzystanie luki nie wymaga od użytkownika żadnej interakcji poza otwarciem e-maila.

Ponieważ luka działa na poziomie dostępu do sesji, samo załatanie może nie być wystarczające, jeśli konto zostało już przejęte przed zastosowaniem aktualizacji. Administratorzy powinni również rozważyć przegląd niedawnej aktywności logowania, rotację tokenów sesyjnych i ponowne wydanie kodów zapasowych 2FA dla kont, które miały dostęp do klasycznego interfejsu, gdy podatność nie była załatana.

Co to oznacza dla Ciebie

Jeśli korzystasz z poczty webowej Zimbra – jako osoba indywidualna, mała firma lub część większej infrastruktury pocztowej organizacji – ta podatność przypomina, że tokeny uwierzytelniające i kody zapasowe są tylko tak bezpieczne, jak oprogramowanie renderujące Twoją skrzynkę odbiorczą. Uwierzytelnianie dwuskładnikowe stanowi silną obronę przed atakami opartymi na hasłach, ale stored XSS, który może bezpośrednio wykraść kody zapasowe z sesji przeglądarki, pokazuje, że 2FA nie jest srebrną kulą, jeśli sam klient webowy zostanie naruszony.

Dla zwykłych użytkowników praktyczne ryzyko zależy od tego, czy Twój dostawca poczty lub dział IT korzysta z Zimbry, a w szczególności, czy klasyczny klient webowy jest nadal używany. Większość osób nie musi robić nic poza oczekiwaniem, aż administrator zastosuje poprawkę. Dla administratorów i zespołów IT jest to natomiast pozycja do natychmiastowego działania.

Konkretne wnioski

  • Potwierdź, że Twoje wdrożenie Zimbry działa na wersji ZCS 10.0.18, 10.1.13 lub nowszej; wszystko wcześniejsze jest narażone na CVE-2025-66376.
  • Jeśli Twoja organizacja nadal opiera się na klasycznym kliencie webowym, priorytetem jest zaatanie, wyprzedzając planowaną migrację do nowoczesnego interfejsu.
  • Po zastosowaniu poprawki przejrzyj ostatnie logi uwierzytelniania pod kątem anomalii i rozważ rotację tokenów sesyjnych dla kont, które były aktywne w okresie narażenia.
  • Ponownie wydaj kody zapasowe 2FA dla wszystkich kont noszących ślady podejrzanej aktywności, ponieważ skradzione kody zapasowe mogą całkowicie ominąć zabezpieczenia dwuetapowe.
  • Traktuj komunikaty o stored XSS od swojego dostawcy poczty jako priorytetowe w przyszłości, gdyż to nie pierwszy raz, gdy starszy klient Zimbry wymagał awaryjnych poprawek oczyszczania.

Wyprzedzanie takich podatności sprowadza się do rutynowej dyscypliny łatania i dokładnej wiedzy, którego klienta webowego Twoja organizacja faktycznie używa na co dzień. Kilka minut poświęconych na sprawdzenie wersji Zimbry teraz kosztuje znacznie mniej niż odzyskiwanie skompromitowanej skrzynki później.