Krajobraz Zagrożeń 19-25/03/2026

W niniejszym wydaniu „Krajobrazu Zagrożeń” przyglądamy się trzem zjawiskom dobrze ilustrującym obecne trendy w cyberbezpieczeństwie. Pierwszym z nich jest kampania przypisywana grupie TeamPCP, pokazująca jak skutecznie można wykorzystać zaufanie do narzędzi open source i procesów CI/CD do przejęcia łańcucha dostaw oprogramowania. Drugim – rosnąca skala i różnorodność ataków typu ClickFix, które potwierdzają, iż inżynieria społeczna przez cały czas pozostaje jednym z najskuteczniejszych wektorów initial access, ewoluując wraz z zachowaniami użytkowników. Trzecim elementem są kolejne podatności w urządzeniach brzegowych Citrix, przypominające, iż klasyczne błędy implementacyjne w krytycznych komponentach infrastruktury wciąż stanowią realne i trudne do wyeliminowania ryzyko. Te trzy przypadki łączy jeden wspólny mianownik: wykorzystywanie zaufania. Niezależnie od tego, czy chodzi o zaufanie do biblioteki open source, znanej marki, czy mechanizmu uwierzytelniania, to właśnie ono jest dziś środkiem do osiągnięcia celu atakujących.

Łańcuch dostaw

TeamPCP i kompromitacja łańcucha dostaw w ekosystemie open source.

Marcowa kampania przypisywana grupie TeamPCP ilustruje kierunek, w jakim ewoluuje współczesny krajobraz zagrożeń: od pojedynczych incydentów do skoordynowanych, wieloetapowych operacji atakujących łańcuch dostaw oprogramowania, w których każde kolejne przejęcie środowiska staje się punktem wyjścia do kolejnego ataku.

Jednym z najnowszych i bardziej znaczących etapów tej kampanii był atak na LiteLLM – popularną bibliotekę open source pełniącą rolę warstwy pośredniczącej pomiędzy aplikacjami a dostawcami modeli językowych. LiteLLM umożliwia korzystanie z wielu usług LLM poprzez jednolity interfejs API, upraszczając integrację i eliminując konieczność implementowania oddzielnych mechanizmów dla wszystkich providera. W praktyce bardzo często komponent stanowi centralny element architektury – odpowiada za routing zapytań, zarządzanie kluczami API oraz integrację z backendem. Jest wykorzystywany zarówno w środowiskach produkcyjnych, jak i w pipeline’ach CI/CD czy procesach testowych, gdzie umożliwia m.in. przełączanie modeli, optymalizację kosztów czy testy porównawcze.

Ta wygoda i uniwersalność mają jednak swoją cenę. LiteLLM operuje w obszarze szczególnie wrażliwym – przetwarza dane użytkowników, posiada dostęp do kluczy API i często działa w środowiskach o podwyższonych uprawnieniach. W efekcie jego kompromitacja nie ogranicza się do jednej aplikacji, ale może prowadzić do przejęcia szerokiego zakresu zasobów – od usług chmurowych po hasła i tokeny infrastrukturalne. Właśnie dlatego tego typu komponenty stają się atrakcyjnym celem.

Sam atak na LiteLLM miał charakter typowego ataku na łańcuch dostaw, ale z wyraźnym wykorzystaniem bardziej zaawansowanych technik. Złośliwy kod nie trafił do publicznego repozytorium, ale został wstrzyknięty bezpośrednio do artefaktu publikowanego w PyPI. To oznacza, iż standardowe praktyki, takie jak przegląd kodu źródłowego, nie były w stanie wykryć manipulacji. Dopiero porównanie artefaktu z kodem źródłowym ujawniało niezgodności, co pokazuje rosnące znaczenie kontroli integralności procesu budowania oraz dystrybucji paczek oprogramowania.

Rys. Zatrucie LiteLLM: Złośliwy kod dodany w pliku proxy_server.py.; Źródło: Endor Labs.

Mechanizm infekcji został zaprojektowany w sposób maksymalizujący zasięg przy jednoczesnym ograniczeniu widoczności. W jednej z wersji payload wykonywał się już w momencie importu modułu, co oznaczało brak potrzeby jakiejkolwiek interakcji użytkownika. W bardziej agresywnym wariancie wykorzystano pliki .pth, dzięki czemu kod uruchamiał się przy każdym starcie interpretera Pythona – niezależnie od tego, czy biblioteka była faktycznie używana. W praktyce oznaczało to przejęcie całego środowiska wykonawczego, a nie tylko aplikacji korzystającej z podatnej zależności.

Po uruchomieniu malware realizował wieloetapowy łańcuch działań, którego głównym celem było pozyskanie danych uwierzytelniających. Zakres zbieranych informacji był szeroki i obejmował zarówno klasyczne artefakty, takie jak klucze SSH czy pliki konfiguracyjne, jak i dane charakterystyczne dla nowoczesnych środowisk – sekrety Kubernetes, dane z usług chmurowych (AWS, GCP, Azure), konfiguracje CI/CD czy pliki .env. Wyraźnie widać tu zmianę priorytetów – zamiast danych użytkownika celem stały się sekrety infrastrukturalne, które umożliwiają dalszą eskalację i dostęp do środowisk produkcyjnych.

Na tym etapie malware nie ograniczał się do biernego zbierania danych. W przypadku wykrycia środowiska Kubernetes podejmował próby lateral movement poprzez uruchamianie uprzywilejowanych podów na wszystkich węzłach klastra. Taki model działania pozwalał na dostęp do systemów hosta, a w praktyce oznaczało przejęcie całej infrastruktury. Utrzymanie dostępu realizowane było poprzez komponent działający jako usługa systemowa, cyklicznie komunikująca się z infrastrukturą sterującą i umożliwiająca pobieranie kolejnych payloadów. Dane eksfiltrowane były w postaci zaszyfrowanej, co dodatkowo utrudniało ich analizę i wykrycie.

LiteLLM nie był jednak pierwszym celem tej kampanii. Wcześniejsze etapy obejmowały m.in. kompromitację Trivy – narzędzia powszechnie wykorzystywanego w pipeline’ach CI/CD do skanowania podatności. Atak polegał na przejęciu repozytorium projektu i wykorzystaniu go do dystrybucji złośliwych wersji narzędzia. Malware wykonywany w kontekście runnerów CI/CD umożliwiał dostęp do pamięci procesów i przechowywanych tam sekretów, takich jak tokeny czy klucze API. Co istotne, wszystko odbywało się w ramach zaufanego procesu, co znacząco utrudniało wykrycie incydentu.

Kolejnym krokiem było rozszerzenie zasięgu ataku na inne komponenty łańcucha dostaw, w tym akcje GitHub oraz narzędzia powiązane z KICS. W tych przypadkach wykorzystano ten sam typ malware’u – wyspecjalizowany credential stealer – co wskazuje na spójność całej kampanii. Przejęte wcześniej poświadczenia były wykorzystywane do wprowadzania złośliwych zmian w kolejnych repozytoriach, często poprzez manipulację tagami i publikację zmodyfikowanych wersji oprogramowania. Taki model działania prowadził do efektu kaskadowego, w którym jedna kompromitacja umożliwiała kolejne. Warto zwrócić uwagę na szeroki zakres danych zbieranych przez malware, określany często jako „TeamPCP Cloud stealer”. Obejmuje on nie tylko klucze SSH i dane dostępowe do systemów kontroli wersji, ale również poświadczenia do usług chmurowych, sekrety Kubernetes, konfiguracje CI/CD, a choćby dane z portfeli kryptowalut czy webhooki komunikatorów. Informacje te były szyfrowane i przesyłane do infrastruktury kontrolowanej przez atakującego, przy czym wykorzystywane domeny często podszywały się pod legalne usługi, co utrudnia ich identyfikację. W niektórych przypadkach stosowane były alternatywne metody eksfiltracji, takie jak tworzenie repozytoriów w infrastrukturze ofiary i zapisywanie w nich wykradzionych danych.

Istotnym rozszerzeniem kampanii była również kompromitacja środowisk deweloperskich poprzez trojanizację rozszerzeń publikowanych w OpenVSX. W tym scenariuszu złośliwy kod aktywował się w środowisku IDE, analizował dostępne poświadczenia, a następnie pobierał kolejne etapy payloadu.

Zestawienie tych incydentów pokazuje wyraźnie, iż działania TeamPCP mają charakter systemowy i długofalowy. Kluczowym zasobem w tej kampanii nie są pojedyncze systemy, ale przejęte poświadczenia, które umożliwiają dalszą propagację w kolejnych środowiskach. W efekcie powstaje mechanizm samonapędzającej się kompromitacji łańcucha dostaw, w którym granice pomiędzy poszczególnymi incydentami zacierają się, a każdy kolejny etap stanowi naturalną konsekwencję poprzedniego.

Więcej informacji:
https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/
https://docs.litellm.ai/blog/security-update-march-2026
https://www.endorlabs.com/learn/teampcp-isnt-done

Cybercrime

ClickFix w pięciu (nowych) klastrach.

Według raportu Mandiant M-Trends 2026 z roku na rok phishing mailowy jest coraz mniej popularnym wektorem infekcji. Z kolei rosnące wykorzystanie techniki ClickFix uznano za jedno z istotniejszych globalnych wydarzeń roku 2025. Według raportu GTIG ta technika występuje w wielu odmianach i jest wykorzystywana przez zróżnicowane grupy, głównie te skupiające się na masowych operacjach initial access. Sama technika występuje w wielu wersjach, takich jak fałszywa CAPTCHA czy instrukcje instalacji systemu lub naprawy problemu w rzeczywistości prowadzące do instalacji złośliwego oprogramowania. Analitycy GTIG mówią o dziesiątkach klastrów zagrożeń, ale bez szczegółów opisujących sposób ich klasyfikacji czy przykładów (poza przytoczeniem wykorzystania w atakach tej techniki przez grupę UNC5518).

Chcąc przyjrzeć się klastrowaniu ClickFixów bliżej, warto przeanalizować publikację Insikt Group Recorded Future opisującą szczegółowo zaobserwowane przez nich warianty tego ataku. Analitycy zdecydowali się na wyodrębnienie 5 klastrów: Intuit QuickBooks, Booking.com, Birdeye, Dual-Platform Selection oraz macOS Storage Cleaning. To według Recorded Future nowe klastry zyskujące na popularności i wyróżniające się m.in. podejściem do wykorzystania techniki ClickFix.

Jednym ze szczególnych elementów wielu ataków z wykorzystaniem socjotechniki jest posługiwanie się przez atakujących znanymi logami lub nazwami renomowanych firm. Ma to uwiarygodnić „przynętę” poprzez odwołanie się do zaufanej marki. W przypadkach opisywanych przez Insikt Group jedną z takich marek było Intuit i ich oprogramowanie do księgowości QuickBooks. ClickFixy imitujące to właśnie oprogramowanie i pojawiające się w Stanach Zjednoczonych w terminach zbiegających się z rozliczeniami podatkowymi obrazują aktywne dopasowywanie ataków do kontekstu w jakim będą odbierane. Z czasem, ten sam klaster zaczął celować w użytkowników portalu sprzedażowego nieruchomości Zillow, również popularnego w USA. Według analityków w przypadku tego scenariusza wykorzystującego odmianę FakeCAPTCHA na atakowane urządzenia z systemem Windows dostarczany był NetSupportRAT.

Analogicznie została wykorzystana marka Booking.com. Tu również fałszywa CAPTCHA na stronie miała imitować weryfikację powiązaną z firmą, ale pojawił się dodatkowy etap. Ofiara miała najpierw wykonać zadanie bardziej standardowe dla potwierdzenia, iż jest się człowiekiem — wybrać obrazki przedstawiające konkretny przedmiot. Dopiero w kolejnym kroku pojawiała się instrukcja, a do schowka na urządzeniu ofiary wstrzykiwano obfuskowaną komendę. Tu także ostatecznym payloadem był NetSupportRAT.

Podobną metodę zastosowano także w wariancie Birdeye, gdzie FakeCAPTCHA podszywała się pod firmę marketingową o tej właśnie nazwie. Charakterystyczne w tym przypadku było budowanie infrastruktury z użyciem domen zawierających frazę „Bird” oraz przekierowanie ofiary na oficjalną stronę firmy Birdeye po wykonaniu instrukcji typ ClickFix. W tym scenariuszu dostarczane było zróżnicowane złośliwe oprogramowanie typu stealer, m.in. Lumma oraz RedLine.

Dwa ostatnie klastry nie zostały opisane równie dobrze, co poprzednie. Na dzień przygotowania materiału artykuł był prawdopodobnie wybrakowany w wyniku błędu. Same ogólne opisy zwracają jednak uwagę na dwa istotne wątki warte przytoczenia mimo niedociągnięć w artykule. Klaster „Dual-Platform Selection” zyskał swoją nazwę przez wyróżniający go mechanizm weryfikacji systemu operacyjnego urządzenia, z którego odwiedzana jest strona. Na podstawie tej informacji ofierze wyświetlana jest odpowiednia wersja instrukcji w wariancie na macOS lub Windows. W tym scenariuszu ofiara sama musi skopiować komendę (nie jest ona wstrzykiwana do schowka) oraz uruchomić terminal, do którego wklei polecenie.

Klaster „macOS Storage Cleaning” w przeciwieństwie do poprzednich przykładów nie wykorzystywał motywu FakeCAPTCHA. Atakujący przygotowali instrukcje mające nakłonić ofiarę do skopiowania i wykonania polecenia systemowego, które miałoby usunąć zbędne pliki tymczasowe i zwolnić miejsce na dysku. Rzeczywistym efektem wykonania komendy jest instalacja malware. W tych klastrach na systemy macOS dostarczane było złośliwe oprogramowanie z rodzin Odyssey Stealer oraz MacSync.

W artykule znalazły się także IoC, które pozwalają zweryfikować, czy użytkownicy w monitorowanej organizacji natknęli się na tę kampanię. Wykrycie połączeń do jednej z wymienionych domen powinno być początkiem dalszych działań mających na celu potwierdzenie czy użytkownik wykonał polecenia widoczne na stronie i zainstalował złośliwe oprogramowanie na stacji roboczej. W zależności od urządzenia i daty odwiedzin strony ofiara mogła otrzymać inny malware lub trafić na już nieaktywną kampanię. W przypadku takich analiz każdy szczegół ma znaczenie.

Przytoczone przykłady nowych klastrów ataków typu ClickFix wskazują na ciągły rozwój techniki. Choć w Polsce nie obserwujemy wszystkich opisywanych odmian to możemy się spodziewać ewolucji już widywanych wariantów. Przejęte strony polskich biznesów i instytucji są nieustannie atakowane i wykorzystywane do nakłaniania odwiedzających do wykonania instrukcji typu ClickFix skutkujących infekcją złośliwym oprogramowaniem. Jednym z przykładów może być rozwinięta wersja standardowego motywu FakeCAPTCHA z podszyciem pod Cloudflare zaobserwowana na stronie polskiej firmy.

Rys. Trzy kolejne etapy wstrzykniętej instrukcji typu ClickFix w scenariuszu FakeCAPTCHA z podszyciem pod Cloudflare.

W przypadku wstrzyknięcia złośliwych elementów typu FakeCAPTCHA wejście na docelową stronę jest znacząco utrudnione. choćby osoby świadome zagrożenia, niebędące skłonne do wykonania instrukcji mogą mieć problem z ominięciem fałszywej weryfikacji CAPTCHA ze względu na funkcje umieszczone w kodzie. Pierwszy etap wymaga jedynie kliknięcia w przycisk „Continue to verification”, w kolejnym konieczne jest jednak wciśnięcie jakiegokolwiek klawisza na klawiaturze w celu przejścia do następnego ekranu. Tam wystarczy już tylko kliknąć przycisk „Verify” by znaleźć się na docelowej stronie, niezależnie do tego, czy wklejono w okno „Uruchom” polecenie ze schowka i je wykonano. Z perspektywy właściciela strony zaniedbania w zakresie zabezpieczeń skutkują szkodą dla odwiedzających potencjalnie infekowanych malware oraz stratą dla biznesu, do którego oferty dostęp staje się utrudniony. Nie warto także zapominać o skazie na reputacji firmy, której strona powinna być wizytówką, nie świadectwem zaniedbań w zakresie cyberbezpieczeństwa. Jako CERT Orange Polska kontaktujemy się właścicielami polskich stron, na których wykryliśmy tego typu złośliwy kod, by poinformować ich o infekcji i jej konsekwencjach.

ClickFixy na stałe zagościły w arsenale socjotechnicznych metod wykorzystywanych przez atakujących. Ich zróżnicowanie i błyskawiczne dostosowywanie się do zmian w systemach zabezpieczeń sprawiają, iż to zagrożenie wymagające ciągłego śledzenia. Większość przytoczonych scenariuszy opiera się na motywie Fake CAPTCHA, który jest prawdopodobnie tym najczęściej obserwowanym w atakach z wykorzystaniem techniki ClickFix. Są jednak przykłady nakłaniania ofiar do wykonania szkodliwych komend w ramach zupełnie innych scenariuszy lub wyglądających inaczej niż te, które można znaleźć w artykule Insikt Group. Szerzenie świadomości jako kluczowa metoda walki z inżynierią społeczną zwykle opiera się o konkretne przykłady ataków i zrzuty ekranów. Niestety przykłady przytoczone przez Insikt Group i inne analizy wyraźnie pokazują, iż atakujący korzystają z różnych metod, szat graficznych i „przynęt”. Z tego względu zalecamy tam, gdzie to możliwe skoncentrowanie działań na techniczne zabezpieczenia ograniczające możliwość wykonania czynności, do których chcą nakłonić atakujący. Blokada za pośrednictwem GPO skrótu Win+R jest działaniem dość radykalnym, ale znacząco utrudniającym atakującym działanie. W przypadkach, kiedy blokady nie są możliwe warto uważnie monitorować komendy wykonywane przez użytkowników, szczególnie te inicjujące połączenia z zasobami w internecie lub zakodowane.

Więcej informacji:
https://www.recordedfuture.com/research/clickfix-campaigns-targeting-windows-and-macos

CVE Tygodnia

Citrix i deja vu z pamięcią.

Citrix opublikował w marcu 2026 roku biuletyn bezpieczeństwa opisujący dwie nowe podatności w NetScaler ADC i NetScaler Gateway. Jedna z nich, oznaczona CVE-2026-3055, to kolejna odsłona schematu, który środowisko cyberbezpieczeństwa zna aż za dobrze — nieszczelna obsługa pamięci w urządzeniu brzegowym odpowiedzialnym za kontrolę dostępu. Dane Shadowserver potwierdzają to, co widać przy każdym incydencie tego typu, a mianowicie tysiące instancji tych urządzeń jest dostępnych bezpośrednio z Internetu. Przy czym wiele z nich nie zostanie załatane na czas.

CVE-2026-3055 (CVSS v4 9.3) to błąd niewystarczającej walidacji danych wejściowych (out-of-bounds read). W praktyce oznacza to możliwość ujawnienia zawartości pamięci urządzenia przez nieuwierzytelnionego atakującego. Podatność dotyczy wyłącznie konfiguracji, w której NetScaler działa jako SAML Identity Provider (IdP).

CVE-2026-4368 (CVSS v4 7.7) to błąd race condition prowadzący do zjawiska określanego jako user session mixup, czyli niezamierzonego mieszania sesji różnych użytkowników. Podatność występuje, gdy urządzenie działa jako Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy) lub jako AAA virtual server.

Podatne wersje

CVE-2026-3055:

• NetScaler ADC / NetScaler Gateway: 14.1 wcześniejsze niż 14.1-66.58,
• NetScaler ADC / NetScaler Gateway: 13.1 wcześniejsze niż 13.1-62.23,
• NetScaler ADC FIPS oraz NDcPP: wcześniejsze niż 13.1-37.262.

CVE-2026-4368:

• NetScaler ADC / NetScaler Gateway: 14.1-66.54.

Zestawienie obu podatności pokazuje interesujące rozłożenie ryzyka. CVE-2026-3055, z wyższym CVSS, dotyczy konfiguracji SAML IdP — specjalistycznego, ale typowego elementu federacji tożsamości i SSO w środowiskach enterprise. CVE-2026-4368 dotyczy konfiguracji Gateway/AAA, czyli obszaru zwykle związanego ze zdalnym dostępem.

Skala instancji wystawionych na atak

Dane Shadowserver z ostatniego tygodnia marca 2026 roku, pokazane na przytoczonych wykresach, dokumentują skalę problemu. Zarówno instancje NetScaler ADC, jak i NetScaler Gateway są widoczne z Internetu w tysiącach. Nie ma jednak w tej chwili żadnych informacji na temat tego, ile z nich korzysta z podatnych na ataki konfiguracji lub zostało już zabezpieczonych przed atakami.

Rys. Instancje Citrix NetScaler ADC dostępne z Internetu (Shadowserver).

Rys. Instancje Citrix NetScaler Gateway dostępne z Internetu (Shadowserver).

Ten obraz nie jest nowy. Przy każdej poprzedniej podatności klasy CitrixBleed widać ten sam wzorzec — wiele niezaktualizowanych instancji, które pozostają dostępne tygodniami i miesiącami po wydaniu łatki. Przy CVE-2023-4966 podatne urządzenia były aktywnie exploitowane jeszcze dwa lata po ogłoszeniu poprawki.

CitrixBleed, CitrixBleed 2.0 i nowe podatności

Żeby zrozumieć, dlaczego CVE-2026-3055 jest istotne, warto cofnąć się do 2023 roku. CitrixBleed — CVE-2023-4966 (CVSS v3 9.4) — był błędem ujawnienia pamięci w NetScaler skonfigurowanym jako Gateway lub AAA virtual server. Exploit był trywialny, specjalnie spreparowane żądanie HTTP zwracało zawartość pamięci urządzenia, w tym aktywne tokeny sesji. To wystarczyło, by ominąć MFA i przejąć sesję użytkownika bez znajomości jego hasła. Podatność była aktywnie exploitowana jako zero-day od co najmniej sierpnia 2023, zanim Citrix wydał łatkę w październiku. Afilianci LockBit 3.0 gwałtownie włączyli ją do swojego arsenału — ofiarami padły Boeing, Industrial & Commercial Bank of China, DP World i Allen & Overy. Exploitacja trwała mimo dostępności patcha, bo skompromitowane sesje pozostawały aktywne choćby po aktualizacji systemu.

W czerwcu 2025 roku historia powtórzyła się. CVE-2025-5777, gwałtownie okrzyknięty CitrixBleed 2.0, to ponownie out-of-bounds read w mechanizmie uwierzytelniania NetScalera skonfigurowanego jako Gateway lub AAA. Mechanizm działania również jest prosty — gdy do endpointu /p/u/doAuthentication.do trafi żądanie POST z parametrem login bez znaku równości i wartości, backend zamiast zwrócić pusty string oddaje zawartość niezainicjalizowanej zmiennej lokalnej, a więc cokolwiek aktualnie zajmuje odpowiednią przestrzeń na stosie. Klasyczny CWE-457 w urządzeniu odpowiedzialnym za bezpieczeństwo dostępu do sieci. Exploitacja CVE-2025-5777 była już obserwowana od połowy czerwca 2025, tygodnie przed opublikowaniem PoC, a jeden z atakujących adresów IP powiązano z grupą RansomHub. CISA dodała podatność do katalogu KEV 10 lipca 2025 roku.

CVE-2026-3055 wpisuje się w ten schemat, ale inny wariant. Tym razem podatna konfiguracja to SAML IdP, nie Gateway. Klasa błędu jest ta sama — out-of-bounds read z potencjalnym wyciekiem danych z pamięci, ale kontekst jest inny. Urządzenie działające jako SAML IdP uczestniczy w procesach federacji tożsamości, więc w trakcie przetwarzania żądań uwierzytelnienia może obsługiwać dane wrażliwe związane z logowaniem i wymianą atrybucji. CVE-2026-4368 to z kolei race condition w konfiguracji Gateway/AAA powodujący pomieszanie sesji użytkowników. Scenariusze konsekwencji są różne — od ujawnienia danych sesji niewłaściwemu użytkownikowi po potencjalny dostęp do zasobów, do których atakujący nie powinien mieć uprawnień.

Rekomendacje

Priorytetem jest natychmiastowa aktualizacja do poprawionych wersji. W środowiskach, gdzie aktualizacja jest chwilowo niemożliwa, ograniczenie dostępu do Gateway/AAA do zaufanych źródeł IP redukuje powierzchnię ataku, choć nie eliminuje ryzyka dla usług wymagających dostępu publicznego. Citrix nie opublikował dotąd dodatkowych zaleceń post-patch specyficznych dla tych podatności, dlatego nie należy automatycznie przenosić procedur znanych z wcześniejszych CitrixBleedów na obecną sytuację.

Więcej informacji:
https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX696300
https://labs.watchtowr.com/how-much-more-must-we-bleed-citrix-netscaler-memory-disclosure-citrixbleed-2-cve-2025-5777/
https://dashboard.shadowserver.org/statistics/iot-devices/time-series/?date_range=other_range&d1=2026-03-19&d2=2026-03-25&vendor=citrix&type=application-delivery-controller&model=netscaler&dataset=count&limit=100&group_by=geo&stacking=stacked
https://dashboard.shadowserver.org/statistics/iot-devices/time-series/?date_range=other_range&d1=2026-03-19&d2=2026-03-25&vendor=citrix&type=vpn&model=gateway&dataset=count&limit=100&group_by=geo&stacking=stacked