Citrix NetScaler to sprzęt, którego przeciętny użytkownik nigdy nie zobaczy, ale od którego zależy działanie wielu firmowych logowań, portali i bramek VPN. To właśnie takie urządzenia stoją na styku firmowej sieci z internetem i pilnują, kto ma prawo wejść do środka. Dlatego kolejna luka z rodziny „CitrixBleed” budzi niepokój — 2 lipca 2026 roku szkocka firma Lupovis potwierdziła, że napastnicy zaczęli ją wykorzystywać w niecałą dobę po tym, jak stała się publiczna.
Na czym polega luka
Błąd oznaczono jako CVE-2026-8451 i wyceniono na 8,8 w dziesięciostopniowej skali CVSS. To tak zwany out-of-bounds read, czyli odczyt danych spoza przewidzianego obszaru pamięci. Problem tkwi w parserze XML urządzenia NetScaler skonfigurowanego jako dostawca tożsamości SAML. Parser nie kończył prawidłowo wczytywania wartości atrybutu XML bez cudzysłowów, jeśli po niej następował znak nowej linii. W efekcie odczytywał pamięć poza właściwym buforem, a jej zawartość trafiała do odpowiedzi HTTP — konkretnie do ciasteczka o nazwie NSC_TASS.
Najgroźniejsze jest to, że atak nie wymaga logowania. Napastnik nie musi znać żadnego hasła ani konta — wystarczy, że urządzenie jest widoczne w internecie i pełni rolę dostawcy SAML. Nazwa „CitrixBleed” nawiązuje do wcześniejszych podatności tego typu, w których z pamięci urządzenia „wyciekały” tokeny sesji i inne poufne dane pozwalające przejąć aktywne sesje użytkowników.
Eksploatacja ruszyła natychmiast
Łatki i szczegóły techniczne opublikowano 30 czerwca. Gdy tylko firma watchTowr udostępniła opis błędu wraz z narzędziem do jego wykrywania, w sieci pojawili się pierwsi napastnicy. Czujniki Lupovis zarejestrowały skanowanie z adresu IP hostowanego we Frankfurcie — prawdopodobnie jednorazowego węzła zbudowanego specjalnie do tego celu. Gdy pułapka odpowiedziała komunikatem „200 OK”, napastnik od razu wysłał złośliwe zapytanie: pusty znacznik AuthnRequest uzupełniony 476 spacjami i znakiem nowej linii — dokładnie tak, jak w publicznym narzędziu wykrywającym. Dzień później aktywność powtórzył drugi napastnik, tym razem z adresu w Hongkongu. To klasyczny scenariusz — publikacja szczegółów technicznych działa jak instrukcja obsługi dla atakujących.
Jak się chronić
Firmy korzystające z NetScalera powinny natychmiast zainstalować poprawki wydane przez Citrix. Jeśli aktualizacja nie jest możliwa od ręki, warto tymczasowo wyłączyć funkcję dostawcy tożsamości SAML, bo bez niej luka nie działa. Administratorzy powinni też przejrzeć logi pod kątem ruchu na ścieżce /saml/login, sprawdzić wartości przesyłanych zapytań oraz zawartość ciasteczka NSC_TASS — nietypowe dane mogą świadczyć o próbie ataku.
Podsumowanie
Ten przypadek to podręcznikowy przykład wyścigu, jaki toczy się po każdej publikacji luki. Od ujawnienia szczegółów do pierwszych ataków minęły godziny, nie tygodnie. Dla firm płynie z tego jasny wniosek: urządzenia brzegowe, takie jak bramki VPN czy systemy logowania, trzeba łatać priorytetowo i bez zwłoki, bo to one są pierwszym celem. W świecie cyberbezpieczeństwa liczy się dziś nie tylko to, czy załatasz podatność, ale jak szybko to zrobisz.