Wojciech Ciemski, Autor w serwisie Security Bez Tabu

Secrets sprawl w 2026 roku: AI, repozytoria wewnętrzne i narastający problem wycieków poświadczeń

Wprowadzenie do problemu / definicja

Secrets sprawl to niekontrolowane rozprzestrzenianie się wrażliwych danych uwierzytelniających w środowisku organizacji. Chodzi przede wszystkim o klucze API, tokeny dostępu, hasła, poświadczenia chmurowe, sekrety CI/CD oraz dane używane przez aplikacje, automatyzację i usługi sztucznej inteligencji.

W 2026 roku problem ten pozostaje jednym z najpoważniejszych wyzwań bezpieczeństwa w nowoczesnym cyklu wytwarzania oprogramowania. Rosnąca liczba integracji, automatyzacji i tożsamości nieludzkich sprawia, że sekrety pojawiają się w coraz większej liczbie miejsc, często poza formalną kontrolą zespołów bezpieczeństwa.

W skrócie

Skala zjawiska wyraźnie wzrosła. W 2025 roku odnotowano 29 milionów nowych hardcodowanych sekretów w publicznych commitach, co oznacza wzrost o 34% rok do roku. Szczególnie dynamicznie rosły wycieki związane z usługami AI, których liczba zwiększyła się o 81% rok do roku.

Jednocześnie problem przestał dotyczyć wyłącznie publicznych repozytoriów. Sekrety coraz częściej trafiają do prywatnych repozytoriów, komunikatorów, systemów ticketowych, obrazów kontenerów, środowisk developerskich i runnerów CI/CD. Dodatkowym zagrożeniem jest niski poziom remediacji, przez co część ujawnionych poświadczeń pozostaje aktywna przez lata.

29 mln nowych sekretów w publicznych commitach w 2025 roku
34% wzrost rok do roku
81% wzrost wycieków powiązanych z AI
Wysoka ekspozycja repozytoriów wewnętrznych i środowisk self-hosted
Utrzymujący się problem aktywnych, nieunieważnionych poświadczeń

Kontekst / historia

Wyciekające sekrety od lat stanowią istotny problem dla organizacji rozwijających oprogramowanie w modelu chmurowym i DevOps. W przeszłości największa uwaga koncentrowała się na publicznych repozytoriach, ponieważ były one najłatwiejsze do monitorowania i często prowadziły do głośnych incydentów.

Obecnie krajobraz zagrożeń jest jednak znacznie szerszy. Upowszechnienie konteneryzacji, automatyzacji pipeline’ów, infrastruktury jako kodu, usług SaaS oraz integracji z modelami AI doprowadziło do sytuacji, w której poświadczenia są rozproszone w całym środowisku technologicznym organizacji. Każda nowa integracja oznacza kolejne tokeny, klucze i konta usługowe, które muszą być zarządzane i chronione.

W praktyce wiele firm nadal zakłada, że repozytoria prywatne lub narzędzia współpracy są wystarczająco bezpieczne. To błędne założenie, ponieważ naruszenie konta, zła konfiguracja uprawnień, przejęcie endpointu lub incydent w łańcuchu dostaw mogą bardzo szybko doprowadzić do ujawnienia danych dostępowych.

Analiza techniczna

Najważniejszy wniosek techniczny jest prosty: liczba wycieków sekretów rośnie szybciej niż populacja programistów. Oznacza to, że źródłem problemu nie jest wyłącznie większa liczba osób tworzących kod, ale również charakter nowoczesnych procesów wytwórczych, w których automatyzacja i AI zwiększają wolumen kodu, konfiguracji i integracji.

Szczególnie widoczny jest wzrost liczby sekretów związanych z ekosystemem AI. Obejmuje to nie tylko klucze do modeli, ale także poświadczenia do usług wyszukiwania, backendów agentowych, narzędzi orkiestracyjnych i komponentów pomocniczych. W efekcie organizacje tworzą coraz więcej tożsamości maszynowych, często bez jednoznacznego właściciela, bez procesu rotacji i bez centralnej ewidencji.

Istotnym zjawiskiem jest też większa ekspozycja repozytoriów wewnętrznych niż publicznych. To właśnie tam częściej znajdują się prawdziwe dane produkcyjne, tokeny CI/CD, poświadczenia do baz danych i klucze chmurowe. Prywatny charakter repozytorium nie eliminuje ryzyka, ponieważ dostęp do niego może zostać uzyskany w wyniku przejęcia konta, błędnej konfiguracji lub kompromitacji systemu pośredniczącego.

Coraz więcej wycieków pochodzi również spoza kodu źródłowego. Sekrety pojawiają się w Slacku, Jira, Confluence i innych narzędziach współpracy, zwykle podczas troubleshootingu, onboardingu, ręcznej wymiany informacji operacyjnych lub działań związanych z incydentami. Tego typu dane bywają szczególnie niebezpieczne, ponieważ często dotyczą aktywnych systemów produkcyjnych.

Osobnym problemem są środowiska self-hosted oraz obrazy kontenerów. W praktyce sekrety mogą pozostać zapisane w warstwach builda, plikach konfiguracyjnych, zmiennych środowiskowych i artefaktach tymczasowych. Nawet jeśli aplikacja nie eksponuje ich bezpośrednio, analiza obrazu lub hosta może pozwolić na odzyskanie cennych poświadczeń.

Raport zwraca też uwagę na trwałość wycieków. Wiele sekretów zidentyfikowanych lata wcześniej nadal pozostaje aktywnych, co pokazuje, że sama detekcja nie rozwiązuje problemu. Jeśli organizacja nie ma sprawnego procesu unieważniania, rotacji i bezpiecznej wymiany poświadczeń, raz ujawniony sekret może stać się długoterminową ścieżką dostępu dla atakującego.

Duże znaczenie mają również endpointy deweloperskie i runnery CI/CD. Na pojedynczym systemie mogą znajdować się te same sekrety w plikach .env, historii poleceń, konfiguracjach IDE, cache narzędzi oraz pozostałościach po buildach. Kompromitacja takiej maszyny daje atakującemu szeroki zestaw gotowych danych dostępowych, a w przypadku runnerów CI/CD skala potencjalnego wpływu jest jeszcze większa.

Nowym obszarem ryzyka stały się także konfiguracje związane z agentami AI i Model Context Protocol. Sekrety trafiają tam do plików JSON, parametrów startowych i lokalnych konfiguracji integracyjnych, które nie zawsze są objęte klasycznym skanowaniem bezpieczeństwa.

Konsekwencje / ryzyko

Secrets sprawl przekłada się bezpośrednio na realne scenariusze ataku. Ujawnione poświadczenia mogą posłużyć do przejęcia kont chmurowych, naruszenia pipeline’ów CI/CD, uzyskania dostępu do danych klientów, eskalacji uprawnień i lateral movement wewnątrz środowiska.

Szczególnie niebezpieczne są aktywne sekrety produkcyjne, które pozostają ważne długo po wycieku. Pozwalają one napastnikom wrócić do środowiska nawet po zakończeniu początkowej fazy incydentu, a czasem również po pozornym zamknięciu sprawy przez organizację.

W środowiskach wykorzystujących AI ryzyko rośnie jeszcze szybciej, ponieważ firmy często nie mają pełnej wiedzy o wszystkich istniejących tożsamościach nieludzkich. Brak właściciela, brak inwentaryzacji i szerokie uprawnienia tworzą warunki do poważnych naruszeń bezpieczeństwa oraz problemów z zgodnością i audytem.

Przejęcie kont usługowych i środowisk chmurowych
Kompromitacja łańcucha dostaw oprogramowania
Dostęp do danych klientów i systemów produkcyjnych
Lateral movement i utrzymanie trwałej obecności w środowisku
Ryzyko reputacyjne, regulacyjne i operacyjne

Rekomendacje

Organizacje powinny traktować sekrety jako element zarządzania tożsamościami nieludzkimi, a nie wyłącznie jako problem jakości kodu. Punktem wyjścia musi być pełna inwentaryzacja kont usługowych, kluczy API, tokenów, poświadczeń pipeline’ów oraz danych używanych przez aplikacje i agentów AI.

Niezbędne jest wdrożenie wielowarstwowego skanowania obejmującego repozytoria publiczne i prywatne, komunikatory, systemy ticketowe, obrazy kontenerów, artefakty buildów, środowiska self-hosted oraz endpointy deweloperskie. Kontrole te powinny być zintegrowane z SDLC i pipeline’ami CI/CD.

Kluczowe znaczenie ma automatyzacja remediacji. Samo wykrycie sekretu nie wystarczy, jeśli organizacja nie jest w stanie szybko go unieważnić, zrotować lub zastąpić bezpiecznym mechanizmem dostępu. W praktyce warto ograniczać stosowanie statycznych poświadczeń na rzecz krótkotrwałych tokenów, federacji tożsamości, dynamicznych sekretów oraz centralnych sejfów sekretów.

Dobrą praktyką jest również ograniczanie ekspozycji na stacjach roboczych i runnerach CI/CD. Obejmuje to zasadę minimalnych uprawnień, segmentację, bezpieczne przechowywanie sekretów, wyłączanie ich z historii poleceń i regularne usuwanie artefaktów tymczasowych. W środowiskach kontenerowych należy dodatkowo monitorować warstwy obrazów i procesy buildów pod kątem przypadkowego zapisu danych uwierzytelniających.

W kontekście AI firmy powinny objąć konfiguracje agentów, integracje MCP i lokalne pliki konfiguracyjne tymi samymi zasadami, które stosują wobec systemów produkcyjnych. Każdy sekret powinien mieć właściciela, określony cykl życia, zakres uprawnień i procedurę rotacji.

Podsumowanie

Secrets sprawl pozostaje jednym z najszybciej narastających problemów bezpieczeństwa w nowoczesnych środowiskach IT. Najnowsze dane pokazują, że skala wycieków poświadczeń rośnie szybciej niż liczba deweloperów, a rozwój AI dodatkowo przyspiesza ten trend.

Największa zmiana polega jednak na przesunięciu źródeł ekspozycji poza publiczny kod. Dziś sekrety wyciekają również z repozytoriów wewnętrznych, narzędzi współpracy, obrazów kontenerów, runnerów CI/CD i konfiguracji agentów. Dlatego organizacje muszą przejść od pasywnego wykrywania do aktywnego zarządzania cyklem życia poświadczeń oraz pełnego nadzoru nad tożsamościami nieludzkimi.

Źródła

Infinity Stealer na macOS: nowy infostealer wykorzystuje ClickFix i ładunek Python kompilowany przez Nuitka

Wprowadzenie do problemu / definicja

Infinity Stealer to nowo opisana rodzina malware typu infostealer, wymierzona w użytkowników systemu macOS. Jej głównym celem jest kradzież wrażliwych danych, takich jak poświadczenia zapisane w przeglądarkach, wpisy z Keychain, dane portfeli kryptowalutowych, pliki konfiguracyjne zawierające sekrety oraz zrzuty ekranu. Na tle wielu wcześniejszych kampanii zagrożenie wyróżnia się tym, że nie bazuje na klasycznym exploicie, lecz na socjotechnice, która nakłania ofiarę do samodzielnego uruchomienia złośliwego polecenia w Terminalu.

W skrócie

Kampania wykorzystuje technikę ClickFix, znaną wcześniej głównie z ataków na użytkowników Windows, ale coraz częściej adaptowaną także do środowiska Apple. Ofiara trafia na fałszywą stronę weryfikacyjną przypominającą CAPTCHA i otrzymuje instrukcję wklejenia komendy do Terminala. Po jej wykonaniu uruchamiany jest wieloetapowy łańcuch infekcji.

Pierwszy etap stanowi skrypt Bash pobierający kolejne komponenty.
Drugi etap to natywny loader dla macOS, skompilowany z użyciem Nuitka.
Trzeci etap to właściwy stealer napisany w Pythonie 3.11, odpowiedzialny za zbieranie i eksfiltrację danych.

To połączenie socjotechniki i wieloetapowej architektury pokazuje rosnącą dojrzałość zagrożeń kierowanych przeciwko użytkownikom macOS.

Kontekst / historia

ClickFix zdobył popularność jako metoda obchodzenia części tradycyjnych mechanizmów ochronnych bez konieczności wykorzystywania podatności. Zamiast dostarczać złośliwy plik w załączniku lub inicjować automatyczne pobranie, atakujący skłania ofiarę do wykonania polecenia samodzielnie. W praktyce przenosi to część odpowiedzialności za uruchomienie malware na użytkownika, co utrudnia wykrywanie i zwiększa skuteczność ataku.

W analizowanej kampanii technika została dostosowana do macOS. Instrukcje odwołują się do uruchomienia Spotlight, otwarcia Terminala i wklejenia wskazanej komendy. Badacze zauważyli również podobieństwa pierwszego etapu infekcji do wcześniejszych rodzin malware dla macOS, w tym MacSync, co może sugerować wykorzystanie wspólnych elementów buildera lub ponowne użycie gotowych schematów działania.

Analiza techniczna

Infekcja zaczyna się od wejścia na stronę podszywającą się pod proces weryfikacji użytkownika. Witryna prezentuje komunikat stylizowany na stronę ochronną i instruuje ofiarę, aby wkleiła polecenie Bash do Terminala. To polecenie pobiera pierwszy etap z infrastruktury kontrolowanej przez operatora kampanii.

Pierwszy etap pełni rolę droppera. Skrypt przygotowuje środowisko dla kolejnego komponentu, dekoduje osadzony ładunek, zapisuje binarium drugiego etapu w katalogu tymczasowym, usuwa atrybut kwarantanny systemu macOS za pomocą mechanizmu xattr, uruchamia plik w tle przy użyciu nohup i czyści część śladów po wykonaniu.

Drugi etap to loader w formacie Mach-O przeznaczony dla Apple Silicon. Został przygotowany z użyciem Nuitka w trybie onefile, co oznacza przekształcenie aplikacji Python do postaci natywnego pliku wykonywalnego. Takie podejście utrudnia analizę statyczną i może ograniczać skuteczność części mechanizmów detekcyjnych. Po uruchomieniu loader dekompresuje osadzone dane i przekazuje kontrolę do finalnego modułu kradnącego informacje.

Trzeci etap, określany jako UpdateHelper.bin, został przygotowany dla Python 3.11. To właśnie ten komponent odpowiada za właściwą kradzież danych z systemu ofiary.

Zbiera dane z przeglądarek opartych na Chromium oraz z Firefoksa.
Odczytuje wpisy z macOS Keychain.
Wyszukuje portfele kryptowalutowe.
Przechwytuje pliki .env zawierające tokeny i sekrety aplikacyjne.
Wykonuje zrzuty ekranu.
Eksfiltruje dane przez żądania HTTP POST.

Próbka zawiera również mechanizmy utrudniające analizę. Oprogramowanie sprawdza obecność środowisk analitycznych i sandboxów, stosuje losowe opóźnienia wykonania i ogranicza w ten sposób skuteczność automatycznej detonacji. Dodatkowo operator może otrzymywać powiadomienia przez Telegram, a przechwycone poświadczenia mogą zostać wykorzystane w dalszych etapach ataku.

Konsekwencje / ryzyko

Ryzyko związane z Infinity Stealer jest wysokie, ponieważ malware koncentruje się na danych umożliwiających szybkie przejęcie kont, dostępów firmowych i aktywów finansowych. Kradzież poświadczeń z przeglądarek oraz Keychain może prowadzić do naruszenia poczty, usług chmurowych, VPN, paneli administracyjnych i narzędzi deweloperskich.

Szczególnie groźne jest pozyskiwanie plików .env, które bardzo często zawierają klucze API, dane dostępowe do baz danych, sekrety aplikacyjne i tokeny usług CI/CD. W środowisku firmowym może to oznaczać kompromitację nie tylko pojedynczego urządzenia, ale także repozytoriów kodu, systemów SaaS oraz infrastruktury produkcyjnej. Dla użytkowników indywidualnych skutki mogą obejmować utratę dostępu do poczty, usług finansowych i portfeli kryptowalutowych.

Rekomendacje

Najważniejsza zasada obronna jest prosta: nie należy wklejać do Terminala poleceń pochodzących ze stron internetowych, nawet jeśli strona twierdzi, że jest to część procesu weryfikacji. Legalne mechanizmy CAPTCHA i standardowe systemy bezpieczeństwa nie wymagają uruchamiania komend powłoki przez użytkownika.

Jeśli podejrzane polecenie zostało już wykonane, należy natychmiast przerwać używanie urządzenia do działań wrażliwych, takich jak logowanie do bankowości, poczty czy systemów firmowych. Następnie trzeba z czystego i zaufanego urządzenia zmienić hasła, unieważnić aktywne sesje oraz przeprowadzić rotację tokenów API, kluczy SSH i innych sekretów.

Przeprowadzić analizę artefaktów w katalogach tymczasowych.
Sprawdzić lokalizacje odpowiedzialne za trwałość, zwłaszcza ~/Library/LaunchAgents/ oraz /tmp.
Uruchomić pełne skanowanie antymalware.
Zweryfikować historię logowań do krytycznych usług.
Monitorować nietypowe połączenia wychodzące i użycie przejętych poświadczeń.
W środowiskach firmowych wdrożyć reguły detekcyjne dla nietypowego użycia Terminala, poleceń typu curl | bash, usuwania atrybutów kwarantanny i pojawiania się nieoczekiwanych binariów Mach-O w katalogach tymczasowych.

Podsumowanie

Infinity Stealer potwierdza, że ekosystem zagrożeń dla macOS staje się coraz bardziej zaawansowany. Kampania łączy skuteczną socjotechnikę ClickFix z wieloetapowym łańcuchem infekcji oraz natywnym loaderem zbudowanym przy użyciu Nuitka, co podnosi poziom ukrycia i utrudnia analizę. Najważniejszy wniosek jest jednoznaczny: pojedyncze polecenie wklejone do Terminala może wystarczyć do pełnej kompromitacji danych użytkownika lub organizacji.

Źródła

Security Affairs – New macOS Infinity Stealer uses Nuitka Python payload and ClickFix — https://securityaffairs.com/190147/security/new-macos-infinity-stealer-uses-nuitka-python-payload-and-clickfix.html
Malwarebytes – Infiniti Stealer: a new macOS infostealer using ClickFix and Python/Nuitka — https://www.malwarebytes.com/blog/threat-intel/2026/03/infiniti-stealer-a-new-macos-infostealer-using-clickfix-and-python-nuitka

Domniemany zero-day w Telegramie: spór o możliwe przejęcie urządzenia bez kliknięcia

Wprowadzenie do problemu / definicja

W świecie bezpieczeństwa komunikatorów jednymi z najgroźniejszych podatności są luki typu zero-click remote code execution. Umożliwiają one zdalne wykonanie kodu bez jakiejkolwiek interakcji użytkownika, co oznacza, że samo odebranie odpowiednio spreparowanej treści może wystarczyć do uruchomienia ataku. W ostatnich doniesieniach taki scenariusz został powiązany z Telegramem, choć producent stanowczo odrzucił te twierdzenia.

Sprawa dotyczy domniemanej podatności, która miała pozwalać na przejęcie urządzenia poprzez wysłanie złośliwej animowanej naklejki. Gdyby taki mechanizm rzeczywiście działał, mielibyśmy do czynienia z incydentem o bardzo wysokiej wadze operacyjnej, szczególnie dla użytkowników narażonych na ataki ukierunkowane.

W skrócie

Badacz bezpieczeństwa zgłosił krytyczną podatność oznaczoną jako ZDI-CAN-30207.
Według opisu luka miała umożliwiać przejęcie urządzenia bez kliknięcia przez spreparowaną animowaną naklejkę.
Potencjalnie zagrożone miały być wersje Telegrama dla Androida i Linuksa.
Telegram zaprzeczył, by taki scenariusz był technicznie możliwy.
Brak publicznie dostępnych szczegółów technicznych uniemożliwia jednoznaczną ocenę skali zagrożenia.

Kontekst / historia

Informacja o luce pojawiła się w związku ze zgłoszeniem przekazanym do programu koordynującego ujawnianie podatności. Sam opis zwrócił uwagę środowiska bezpieczeństwa, ponieważ mówił o możliwości przejęcia urządzenia bez otwierania wiadomości i bez działań po stronie ofiary. To właśnie ten aspekt sprawił, że sprawa została potraktowana bardzo poważnie.

Jednocześnie pojawił się istotny problem: publiczny opis incydentu nie zawierał pełnej analizy technicznej, a producent od razu zakwestionował zasadność zgłoszenia. W efekcie powstała klasyczna sytuacja sporna, w której alarm o krytycznej luce zderza się z formalnym zaprzeczeniem dostawcy oprogramowania. Dla zespołów bezpieczeństwa oznacza to konieczność ostrożnej oceny ryzyka przy ograniczonej liczbie twardych danych.

Analiza techniczna

Z dostępnych informacji wynika, że domniemana podatność miała być związana z automatycznym przetwarzaniem treści multimedialnych używanych przez Telegram do generowania podglądów lub renderowania animacji. W praktyce taki scenariusz zakłada, że aplikacja po odebraniu specjalnie spreparowanego obiektu trafia w ścieżkę przetwarzania prowadzącą do błędu parsera, uszkodzenia pamięci albo innego stanu umożliwiającego wykonanie kodu.

Model ataku byłby relatywnie prosty. Napastnik przygotowuje plik wyglądający jak prawidłowa animowana naklejka, przesyła go do ofiary, a klient komunikatora automatycznie analizuje zawartość jeszcze przed jakąkolwiek akcją użytkownika. To właśnie ta automatyzacja czyni luki zero-click tak niebezpiecznymi, ponieważ ogranicza znaczenie klasycznej socjotechniki.

Telegram odrzucił jednak ten scenariusz, wskazując, że naklejki przechodzą walidację po stronie serwera przed dostarczeniem do aplikacji klienckiej. Z perspektywy producenta ma to uniemożliwiać przesłanie spreparowanego obiektu, który mógłby wyzwolić exploit po stronie użytkownika. Jeśli ten mechanizm działa zgodnie z deklaracjami, wektor oparty wyłącznie na złośliwej naklejce powinien być zablokowany jeszcze przed dotarciem do odbiorcy.

Największym ograniczeniem obecnej analizy jest brak publicznego proof-of-concept oraz niedostępność szczegółów dotyczących typu błędu, warunków jego wyzwolenia i wymaganych zależności środowiskowych. Bez takich danych nie da się przesądzić, czy chodzi o rzeczywistą lukę, błędną interpretację zachowania aplikacji, czy też o bardziej ograniczony scenariusz niż ten przedstawiony w pierwszych doniesieniach.

Konsekwencje / ryzyko

Gdyby podatność została potwierdzona, jej skutki mogłyby być bardzo poważne. Zero-click RCE w popularnym komunikatorze otwierałby drogę do kompromitacji urządzeń bez ostrzeżeń widocznych dla użytkownika. Taki mechanizm mógłby zostać wykorzystany do instalacji spyware, kradzieży danych, przejęcia sesji, eskalacji uprawnień lub uzyskania trwałej obecności na urządzeniu.

Najbardziej narażone byłyby osoby o podwyższonym profilu ryzyka, takie jak dziennikarze, administratorzy, kadra kierownicza, pracownicy sektora publicznego, działy prawne czy zespoły operujące na danych o dużej wartości wywiadowczej. Komunikatory są dla takich użytkowników naturalnym kanałem kontaktu, a więc także atrakcyjnym celem dla zaawansowanych kampanii.

Nawet jeśli sama luka nie zostanie ostatecznie potwierdzona, sprawa przypomina o szerszym problemie bezpieczeństwa aplikacji obsługujących złożone formaty multimedialne. Każdy moduł odpowiedzialny za dekodowanie, renderowanie i generowanie podglądów zwiększa powierzchnię ataku i wymaga ciągłej weryfikacji.

Rekomendacje

Organizacje i użytkownicy indywidualni powinni przyjąć podejście ostrożnościowe do czasu pełnego wyjaśnienia sprawy. W praktyce oznacza to ograniczanie ekspozycji na wiadomości od nieznanych nadawców oraz szczególną ochronę kont używanych w komunikacji wrażliwej.

Utrzymywać Telegrama, Androida i systemy Linux w najnowszych dostępnych wersjach.
Ograniczyć możliwość kontaktu od nieznanych użytkowników tam, gdzie jest to możliwe.
Monitorować awarie aplikacji, nietypowe procesy i anomalie związane z obsługą multimediów.
Wdrażać rozwiązania EDR lub MTD na urządzeniach wysokiego ryzyka.
Stosować segmentację urządzeń używanych do komunikacji o podwyższonej wrażliwości.
Analizować logi i zdarzenia korelujące się z odbiorem wiadomości lub treści multimedialnych.

Zespoły SOC i CSIRT powinny dodatkowo śledzić dalsze komunikaty producenta, badaczy oraz podmiotów zajmujących się koordynacją ujawniania podatności. W razie pojawienia się potwierdzonych wskaźników kompromitacji warto mieć przygotowaną procedurę szybkiej izolacji urządzeń i odtworzenia zaufanego środowiska pracy.

Podsumowanie

Doniesienia o rzekomej luce zero-click w Telegramie pokazują, jak trudna bywa ocena zagrożeń na wczesnym etapie ujawnienia. Z jednej strony opisano scenariusz potencjalnie krytyczny, umożliwiający przejęcie urządzenia bez interakcji ofiary. Z drugiej strony producent jednoznacznie zaprzeczył, by taki wektor był możliwy, wskazując na mechanizmy walidacji po stronie serwera.

Do czasu pojawienia się pełnych dowodów technicznych najbardziej racjonalnym podejściem pozostaje ostrożność, redukcja powierzchni ataku oraz bieżące monitorowanie nowych ustaleń. W praktyce to właśnie szybka aktualizacja, segmentacja i obserwacja anomalii mogą ograniczyć ryzyko, nawet jeśli sprawa ostatecznie okaże się niepotwierdzona.

Źródła

Security Affairs — https://securityaffairs.com/190167/security/its-a-mystery-alleged-unpatched-telegram-zero-day-allows-device-takeover-but-telegram-denies.html
ACN advisory update — https://www.acn.gov.it/portale/w/telegram-negazione-vulnerabilita-zero-click
Zero Day Initiative — https://www.zerodayinitiative.com/

Trzy klastry powiązane z Chinami prowadziły cyberszpiegostwo przeciw administracji w Azji Południowo-Wschodniej

Wprowadzenie do problemu / definicja

W 2025 roku ujawniono zaawansowaną kampanię cyberszpiegowską wymierzoną w organizację rządową w Azji Południowo-Wschodniej. Analiza incydentu wskazuje, że w środowisku ofiary działały równolegle co najmniej trzy odrębne klastry aktywności powiązane z chińskim ekosystemem APT. Celem operacji nie było zakłócenie pracy systemów, lecz długotrwałe utrzymanie dostępu, zbieranie informacji i rozwijanie przyczółków w sieci.

To istotny przykład współczesnych operacji cyberwywiadowczych, w których kilka zespołów może realizować zbieżne cele wobec jednej instytucji o strategicznym znaczeniu. Tego typu kampanie są trudniejsze do wykrycia i usunięcia, ponieważ opierają się na różnych rodzinach malware, odmiennych technikach infiltracji i wielu warstwach trwałości.

W skrócie

W kampanii zidentyfikowano trzy klastry: Mustang Panda, CL-STA-1048 oraz CL-STA-1049.
Atakujący używali rozbudowanego zestawu narzędzi, w tym HIUPAN, PUBLOAD, EggStremeFuel, EggStremeLoader, MASOL RAT, TrackBak, Hypnosis Loader i FluffyGh0st.
Jeden z wektorów opierał się na propagacji przez nośniki USB, a inne na loaderach i backdoorach wdrażanych w celu utrzymania dostępu.
Nakładające się ramy czasowe i wspólne cele sugerują skoordynowane działania kilku zespołów wobec jednego celu rządowego.
Największe ryzyko dotyczy wycieku danych administracyjnych, poświadczeń, konfiguracji sieci oraz materiałów o znaczeniu politycznym i operacyjnym.

Kontekst / historia

Aktywność przypisywana poszczególnym klastrom rozciągała się na wiele miesięcy 2025 roku. Mustang Panda miał być aktywny od czerwca do połowy sierpnia, CL-STA-1048 od marca do września, a CL-STA-1049 co najmniej w kwietniu i sierpniu. Taki układ wskazuje, że ofiara pozostawała pod długotrwałą presją, a działania mogły być prowadzone równolegle lub etapowo, zależnie od bieżących potrzeb operacyjnych.

Kampania wpisuje się w szerszy trend obserwowany wcześniej w regionie Azji Południowo-Wschodniej. W poprzednich raportach dotyczących operacji Crimson Palace oraz aktywności Unfading Sea Haze również opisywano długotrwałą obecność w środowiskach rządowych, wykorzystanie wielu rodzin malware oraz nacisk na pozyskiwanie danych politycznych, wojskowych i gospodarczych. Najnowszy przypadek wyróżnia się jednak wyraźną konwergencją kilku klastrów wokół tej samej ofiary.

Analiza techniczna

Wątek powiązany z Mustang Panda obejmował użycie malware rozprzestrzeniającego się przez urządzenia USB. Narzędzie HIUPAN, znane także jako USBFect, służyło do przenoszenia komponentów na nośniki wymienne oraz infekowania kolejnych stacji roboczych. Następnie uruchamiany był loader ClaimLoader, którego rolą było załadowanie do pamięci backdoora PUBLOAD. Taki łańcuch zwiększał trwałość infekcji i ułatwiał ruch boczny w środowisku.

PUBLOAD komunikował się z infrastrukturą C2 przy użyciu zaszyfrowanych danych i ruchu przypominającego legalną komunikację TLS. W tej samej linii aktywności odnotowano również COOLCLIENT, czyli backdoor umożliwiający transfer plików, rejestrowanie klawiszy, tunelowanie ruchu i zbieranie informacji o portach. To sugeruje, że operatorzy budowali wielowarstwową obecność, zamiast polegać na pojedynczym implancie.

CL-STA-1048 stosował bardziej modułowe podejście i wykorzystywał kilka rodzin malware o podobnej funkcji. W zestawie znalazły się EggStremeFuel, EggStremeLoader, MASOL RAT oraz TrackBak. EggStremeFuel działał jako lekki backdoor umożliwiający transfer plików, uruchamianie powłoki zwrotnej i zmianę konfiguracji serwera C2. EggStremeLoader rozszerzał możliwości operatora o liczne komendy zdalnego zarządzania i wspierał eksfiltrację danych.

MASOL RAT odpowiadał za zdalne wykonywanie poleceń i operacje na plikach, a TrackBak skupiał się na zbieraniu logów, danych ze schowka, informacji sieciowych i plików z dysku. Taki zestaw narzędzi może wskazywać na aktywne testowanie różnych komponentów pod kątem skuteczności wobec zabezpieczeń EDR i XDR.

CL-STA-1049 działał ostrożniej i wykorzystywał nowy loader DLL określany jako Hypnosis Loader. Był on uruchamiany za pomocą techniki DLL side-loading, a jego zadaniem było wdrożenie FluffyGh0st RAT. To złośliwe oprogramowanie było już wcześniej wiązane z operacjami szpiegowskimi w regionie Morza Południowochińskiego. Taki model działania wskazuje na preferowanie technik maskowania aktywności w zaufanych procesach oraz ograniczania widoczności dla narzędzi obronnych.

Najważniejsza w tej kampanii jest funkcjonalna komplementarność użytych narzędzi. Razem zapewniają one początkową infiltrację, trwałość, ruch boczny, tunneling, keylogging, zbieranie danych oraz elastyczne kanały komunikacji z infrastrukturą sterującą. To charakterystyczny profil operacji cyberwywiadowczej nastawionej na długoterminową obecność i systematyczną eksfiltrację informacji.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem takiej kampanii jest utrata poufności danych administracyjnych i strategicznych. W praktyce może to obejmować dokumenty robocze, dane uwierzytelniające, mapy sieci, informacje o użytkownikach, materiały polityczne oraz dane operacyjne. Dodatkowym zagrożeniem jest obecność wielu niezależnych implantów, które zwiększają odporność przeciwnika na działania naprawcze.

W tego typu incydencie usunięcie jednego komponentu nie oznacza automatycznie pełnej neutralizacji zagrożenia. Osobne klastry mogą korzystać z różnych mechanizmów trwałości, innych kanałów C2 i alternatywnych ścieżek dostępu. Szczególnie niebezpieczne są propagacja przez USB w środowiskach częściowo odizolowanych, nadużywanie DLL side-loading oraz długie okna aktywności, które pozwalają intruzom spokojnie rozwijać operację.

Rekomendacje

Organizacje publiczne i podmioty wysokiego ryzyka powinny wzmocnić kontrolę nośników wymiennych. Obejmuje to blokowanie nieautoryzowanych urządzeń USB, skanowanie offline oraz monitorowanie operacji kopiowania bibliotek DLL i plików wykonywalnych na dyski przenośne. Równie ważne jest wykrywanie technik DLL side-loading poprzez analizę relacji między legalnymi aplikacjami a nietypowymi bibliotekami ładowanymi z katalogów użytkownika i ścieżek tymczasowych.

Warto również rozbudować detekcję behawioralną pod kątem keyloggingu, tunelowania ruchu, nietypowych połączeń TCP udających szyfrowaną komunikację oraz tworzenia mechanizmów autostartu. Zespoły bezpieczeństwa powinny prowadzić regularny threat hunting z uwzględnieniem telemetrii endpointów, zdarzeń PowerShell, zmian w katalogach ProgramData i AppData, uruchomień z nośników wymiennych oraz zależności proces-plik-DLL.

Ograniczyć użycie nośników USB i wdrożyć ścisłe polityki ich obsługi.
Monitorować DLL side-loading oraz nietypowe ładowanie bibliotek.
Rozszerzyć wykrywanie o zachowania charakterystyczne dla loaderów pamięciowych i shellcode.
Segmentować sieć oraz ograniczać uprawnienia lokalnych administratorów.
Stosować kontrolę aplikacyjną i centralne zarządzanie IOC oraz IOA.
Po wykryciu incydentu szybko rotować poświadczenia i zakładać możliwość obecności wielu klastrów jednocześnie.

W przypadku podejrzenia kompromitacji nie należy zakładać, że incydent ogranicza się do jednego implantu. Konieczne jest pełne scope’owanie zdarzenia, analiza pamięci, przegląd hostów pod kątem ukrytych komponentów oraz weryfikacja, czy przeciwnik nie utrzymuje alternatywnych ścieżek dostępu.

Podsumowanie

Opisana kampania pokazuje, że nowoczesne operacje APT coraz częściej przybierają formę wielowarstwowych działań prowadzonych równolegle przez kilka klastrów wobec jednego celu. W tym przypadku różne zestawy narzędzi, od robaków USB po stealth loadery i zaawansowane RAT-y, wspierały wspólny cel: długoterminowe utrzymanie dostępu do sieci administracji rządowej i systematyczne pozyskiwanie danych.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że skuteczna obrona przed cyberwywiadem wymaga nie tylko klasycznych mechanizmów prewencyjnych, ale również ciągłej analizy behawioralnej, dojrzałego threat huntingu oraz gotowości do równoczesnego usuwania wielu śladów obecności przeciwnika.

Źródła

The Hacker News — https://thehackernews.com/2026/03/three-china-linked-clusters-target.html
Palo Alto Networks Unit 42: Converging Interests: Analysis of Threat Clusters Targeting a Southeast Asian Government — https://unit42.paloaltonetworks.com/espionage-campaigns-target-se-asian-government-org/
Sophos News: Operation Crimson Palace — https://news.sophos.com/en-us/2024/06/05/operation-crimson-palace-sophos-threat-hunting-unveils-multiple-clusters-of-chinese-state-sponsored-activity-targeting-southeast-asia/
Sophos News: Crimson Palace returns: New Tools, Tactics, and Targets — https://news.sophos.com/en-us/2024/09/10/crimson-palace-new-tools-tactics-targets/
Bitdefender: Unfading Sea Haze: New Espionage Campaign in the South China Sea — https://www.bitdefender.com/en-gb/blog/labs/unfading-sea-haze-new-espionage-campaign-in-the-south-china-sea

Rosyjski toolkit CTRL atakuje Windows przez pliki LNK i przejmuje RDP z użyciem tuneli FRP

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa opisali wcześniej nieudokumentowany zestaw narzędzi post-exploitation o nazwie CTRL, powiązany z rosyjskojęzycznym operatorem. Framework jest dostarczany za pomocą spreparowanych skrótów systemu Windows w formacie LNK, które podszywają się pod zwykłe katalogi z kluczami prywatnymi. Celem kampanii jest uzyskanie trwałego dostępu do systemu, przechwycenie poświadczeń, uruchomienie keyloggera oraz przejęcie sesji zdalnego pulpitu przy użyciu tunelowania reverse proxy.

W skrócie

CTRL to niestandardowy toolkit napisany w .NET, przeznaczony do zdalnego dostępu i działań hands-on-keyboard.
Infekcja rozpoczyna się od złośliwego pliku LNK uruchamiającego ukryty PowerShell i kolejne komponenty.
Narzędzie wykorzystuje phishing interfejsu Windows Hello do wyłudzania kodu PIN oraz rejestruje naciśnięcia klawiszy.
Kluczowym elementem operacji jest użycie FRP do tworzenia tuneli zwrotnych dla dostępu RDP.
Całość została zaprojektowana z naciskiem na niski profil sieciowy i utrudnianie analizy śledczej.

Kontekst / historia

Analiza wskazuje, że toolkit został odnaleziony w otwartym katalogu udostępniającym artefakty malware w lutym 2026 roku. Badacze ustalili, że kampania korzystała z co najmniej jednego pliku LNK nazwanego tak, aby sugerował folder zawierający klucz prywatny. To klasyczny zabieg socjotechniczny: ofiara widzi ikonę katalogu i zakłada, że otwiera lokalny zasób, podczas gdy w rzeczywistości uruchamia wieloetapowy loader.

Tło operacji sugeruje, że nie chodzi o masowo dystrybuowany malware, lecz o prywatnie rozwijany zestaw narzędzi przeznaczony do ukierunkowanych działań po uzyskaniu wykonania kodu na stacji roboczej. Wskazują na to własny zestaw binariów, ograniczona widoczność w publicznych źródłach threat intelligence oraz architektura skoncentrowana na dostępie operatorskim zamiast klasycznym modelu beaconingu.

Analiza techniczna

Łańcuch ataku rozpoczyna się od pliku LNK, który uruchamia ukryte polecenie PowerShell. Następnie loader usuwa część istniejących mechanizmów persistence ze ścieżek startowych systemu Windows, dekoduje zakodowany blob i uruchamia kolejny etap bezpośrednio w pamięci. Stager sprawdza łączność TCP z infrastrukturą operatora, pobiera dalsze moduły i przygotowuje system do trwałej kompromitacji.

W kolejnych fazach malware modyfikuje reguły zapory, tworzy zadania harmonogramu, zakłada tylne konta lokalne oraz uruchamia serwer powłoki dostępny przez tunel FRP. Jeden z głównych komponentów, ctrl.exe, działa jako loader .NET i uruchamia osadzony moduł zarządzający. Platforma może pracować zarówno jako serwer na systemie ofiary, jak i jako klient po stronie operatora, zależnie od argumentów wiersza poleceń.

Istotnym elementem architektury jest komunikacja przez nazwane potoki Windows. Dzięki temu ruch sterujący nie musi opuszczać hosta w postaci klasycznych komunikatów C2. Z perspektywy sieci widoczna pozostaje głównie sesja RDP zestawiona przez tunel reverse proxy, co znacząco ogranicza możliwość wykrycia na podstawie typowych sygnatur beaconingu.

Funkcjonalnie CTRL obejmuje kilka modułów:

wyłudzanie poświadczeń z użyciem aplikacji WPF imitującej okno weryfikacji PIN Windows Hello,
keylogger zapisujący dane do lokalnego pliku,
przejęcie i rozszerzenie dostępu RDP, w tym obsługę wielu równoczesnych sesji,
tunelowanie reverse proxy z wykorzystaniem FRP,
generowanie fałszywych powiadomień systemowych podszywających się pod przeglądarki.

Szczególnie istotny jest moduł phishingowy. Interfejs podszywa się pod natywne okno logowania PIN, blokuje część skrótów klawiaturowych służących do zamknięcia okna i dodatkowo sprawdza poprawność wpisanego PIN-u przez automatyzację interfejsu systemowego. W praktyce oznacza to, że ofiara może pozostać przekonana, iż komunikuje się z autentycznym mechanizmem Windows, podczas gdy przechwycony PIN zostaje zapisany razem z danymi z keyloggera.

Badacze opisali również techniki utrudniające analizę. Artefakty zawierają zaszyfrowane lub kompresowane kolejne etapy, a znaczniki czasu plików wykonywalnych zostały sfałszowane. Wskazuje to na świadome działania mające utrudnić rekonstrukcję osi czasu incydentu oraz automatyczną klasyfikację próbki.

Konsekwencje / ryzyko

Ryzyko związane z CTRL jest wysokie, ponieważ toolkit łączy kilka klas zagrożeń w jednym spójnym zestawie operacyjnym. Uzyskanie PIN-u Windows, aktywacja keyloggera i zestawienie tunelu do RDP umożliwiają pełne przejęcie interaktywnej kontroli nad systemem użytkownika. Dla organizacji oznacza to możliwość eskalacji uprawnień, poruszania się bocznego, eksfiltracji danych oraz wykorzystania przejętego hosta jako punktu wejścia do dalszych działań.

Dodatkowym problemem jest niski profil sieciowy narzędzia. Jeżeli aktywność operatorska odbywa się głównie przez RDP przenoszone tunelem FRP, detekcja oparta wyłącznie na klasycznych wskaźnikach ruchu C2 może okazać się niewystarczająca. Obrona wymaga więc korelacji telemetrii endpoint, logów systemowych, zmian w konfiguracji kont lokalnych, harmonogramu zadań oraz anomalii związanych z usługami zdalnego dostępu.

Wysokie znaczenie ma także komponent socjotechniczny. Sam plik LNK nie wymaga wykorzystania luki w zabezpieczeniach, lecz bazuje na błędzie użytkownika. To sprawia, że nawet dobrze zarządzane środowiska pozostają podatne, jeśli pracownicy nie rozpoznają fałszywych skrótów i nazw sugerujących bezpieczny folder.

Rekomendacje

Organizacje powinny w pierwszej kolejności ograniczyć ryzyko uruchamiania złośliwych plików LNK poprzez blokowanie lub ścisłe monitorowanie skrótów pochodzących z poczty, komunikatorów i nieufnych lokalizacji. Warto także wdrożyć reguły detekcyjne dla nietypowych wywołań PowerShell uruchamianych przez explorer.exe lub przez same pliki skrótów.

Należy monitorować przede wszystkim:

tworzenie nowych lokalnych kont administracyjnych i dodawanie użytkowników do grup Remote Desktop Users,
nieautoryzowane zadania harmonogramu uruchamiające zakodowany PowerShell,
modyfikacje zapory systemowej i wyjątków dla Defendera,
pojawienie się plików keylogów lub nietypowych artefaktów w katalogach tymczasowych,
uruchamianie procesów powiązanych z FRP, wrapperami DLL i niestandardowymi komponentami .NET.

Środowiska korzystające z RDP powinny stosować zasadę minimalnych uprawnień, segmentację sieci oraz wymuszanie MFA wszędzie tam, gdzie to możliwe. Dodatkowo warto ograniczyć możliwość równoczesnych sesji RDP, monitorować zmiany w komponentach odpowiedzialnych za zdalny pulpit oraz wykrywać nietypowe tunele wychodzące do zewnętrznej infrastruktury.

Po stronie SOC i zespołów reagowania na incydenty zasadne jest przygotowanie playbooków obejmujących analizę nazwanych potoków, zrzuty pamięci, kontrolę zadań harmonogramu, analizę artefaktów WPF i inspekcję hostów pod kątem lokalnych narzędzi używanych do reverse tunnelingu. Warto również korelować zdarzenia logowania interaktywnego z nietypowymi zmianami konfiguracyjnymi systemu.

Podsumowanie

CTRL pokazuje rosnący trend w kierunku wyspecjalizowanych, prywatnie rozwijanych toolkitów do zdalnego dostępu, które stawiają na stealth, operacyjne bezpieczeństwo i pracę operatorską przez legalne mechanizmy systemowe. Połączenie złośliwego LNK, phishingu Windows Hello, keyloggera, hijackingu RDP i tuneli FRP tworzy skuteczny zestaw do trwałej kompromitacji stacji roboczych.

Z perspektywy obrony najważniejsze są trzy elementy: ograniczenie uruchamiania nieufnych skrótów, wzmocnione monitorowanie zmian lokalnych na hostach Windows oraz analiza anomalii związanych z RDP i reverse proxy. To właśnie korelacja wielu pozornie drobnych wskaźników może umożliwić wykrycie tego typu zagrożenia, zanim operator uzyska pełną kontrolę nad środowiskiem.

Źródła

Krytyczna luka w FortiClient EMS aktywnie wykorzystywana do zdalnego wykonania kodu

Wprowadzenie do problemu / definicja

FortiClient Enterprise Management Server (EMS) to centralna platforma do zarządzania agentami bezpieczeństwa, politykami endpointów oraz konfiguracją środowisk opartych na rozwiązaniach Fortinet. Ujawniona podatność CVE-2026-21643 została sklasyfikowana jako krytyczna, ponieważ umożliwia zdalne wykonanie kodu bez uwierzytelnienia. Problem wynika z błędu klasy SQL Injection w mechanizmie przetwarzania żądań HTTP, co czyni tę lukę szczególnie groźną dla organizacji utrzymujących EMS w ekspozycji na sieć publiczną.

W skrócie

CVE-2026-21643 ma ocenę 9.1 w skali CVSS.
Podatność dotyczy FortiClient EMS w wersji 7.4.4.
Producent zaleca aktualizację do wersji 7.4.5 lub nowszej.
Luka jest aktywnie wykorzystywana w rzeczywistych atakach.
Atak nie wymaga wcześniejszego logowania i może być realizowany zdalnie.

Kontekst / historia

Fortinet opublikował biuletyn bezpieczeństwa dotyczący CVE-2026-21643 w lutym 2026 roku, opisując problem jako podatność SQL Injection pozwalającą na wykonanie nieautoryzowanych poleceń za pomocą specjalnie spreparowanych żądań HTTP. Na etapie publikacji nie wskazywano jednak jednoznacznie, że luka jest już wykorzystywana w środowisku produkcyjnym.

Sytuacja zmieniła się pod koniec marca 2026 roku, gdy pojawiły się informacje o obserwowanych próbach realnej eksploatacji. Badacze zwrócili uwagę, że wektor ataku może być związany z manipulacją nagłówkiem HTTP „Site”. To ważny szczegół, ponieważ FortiClient EMS pełni funkcję centralnego systemu administracyjnego, a jego przejęcie może zapewnić napastnikowi uprzywilejowany dostęp do dalszych zasobów organizacji.

Sprawa wpisuje się także w szerszy kontekst wcześniejszych problemów bezpieczeństwa w tej klasie produktów. Platformy do centralnego zarządzania endpointami od lat pozostają atrakcyjnym celem dla operatorów ransomware oraz grup prowadzących działania post-exploitation.

Analiza techniczna

CVE-2026-21643 jest klasycznym przykładem nieprawidłowej neutralizacji danych wejściowych wykorzystywanych w zapytaniach SQL. W praktyce aplikacja serwerowa akceptuje dane z żądania HTTP w sposób, który może umożliwić wstrzyknięcie dodatkowych fragmentów zapytania do warstwy bazodanowej.

W tym przypadku skutki nie ograniczają się jedynie do odczytu lub modyfikacji danych. Według dostępnych informacji udana eksploatacja może prowadzić do wykonania nieautoryzowanego kodu lub poleceń systemowych na serwerze EMS. To sugeruje, że podatna ścieżka aplikacyjna może łączyć logikę bazy danych z dalszymi komponentami backendowymi, co znacząco podnosi wagę incydentu.

Atak nie wymaga uwierzytelnienia.
Wektor wejściowy może być osiągalny bezpośrednio przez HTTP.
Podatny system zwykle działa z szerokimi uprawnieniami administracyjnymi.
Centralna rola EMS zwiększa potencjalną skalę skutków po udanym ataku.

Dostępne informacje wskazują, że problem dotyczy wersji 7.4.4, natomiast rekomendowaną ścieżką naprawy jest przejście do wersji 7.4.5 lub nowszej. Doniesienia o wykorzystaniu nagłówka „Site” pokazują też, że organizacje nie powinny ograniczać monitoringu wyłącznie do parametrów GET i POST, ale analizować również nietypowe pola nagłówków HTTP.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2026-21643 należy ocenić jako krytyczne. Kompromitacja FortiClient EMS może oznaczać nie tylko przejęcie pojedynczego serwera, ale także uzyskanie przyczółka do dalszych działań w sieci przedsiębiorstwa.

możliwość ruchu lateralnego do innych systemów,
wdrożenie malware lub ransomware,
manipulację politykami bezpieczeństwa endpointów,
dostęp do danych operacyjnych i konfiguracji agentów,
wykorzystanie EMS jako punktu dystrybucji dalszych działań ofensywnych.

Dodatkowym problemem pozostaje ekspozycja publicznie dostępnych instancji EMS. Jeżeli system jest wystawiony bezpośrednio do Internetu, koszt automatyzacji ataku po stronie przeciwnika znacząco spada. To tworzy warunki do masowego skanowania i szybkiej kompromitacji podatnych hostów.

Rekomendacje

Organizacje korzystające z FortiClient EMS powinny potraktować tę podatność priorytetowo i wdrożyć działania naprawcze w trybie pilnym. Sama instalacja poprawki jest kluczowa, ale nie powinna być jedynym krokiem.

zidentyfikować wszystkie instancje FortiClient EMS w środowisku,
potwierdzić, czy wykorzystywana jest podatna wersja 7.4.4,
przeprowadzić aktualizację do wersji 7.4.5 lub nowszej,
usunąć publiczną ekspozycję EMS lub ograniczyć dostęp przez VPN i segmentację sieci,
przeanalizować logi HTTP pod kątem nietypowych wartości w nagłówkach, szczególnie „Site”,
monitorować host pod kątem nowych procesów, zmian konfiguracyjnych i nietypowej komunikacji wychodzącej,
przeprowadzić hunting w kierunku ruchu lateralnego i artefaktów malware,
przygotować procedurę izolacji serwera na wypadek oznak kompromitacji.

W środowiskach o wysokim profilu ryzyka warto przyjąć ostrożne założenie, że publicznie dostępne i niezałatane instancje mogły już zostać naruszone. Aktualizacja eliminuje podatność, ale nie usuwa skutków potencjalnego włamania, jeśli doszło do niego wcześniej.

Podsumowanie

CVE-2026-21643 to krytyczna podatność typu SQL Injection w FortiClient EMS, która może prowadzić do zdalnego wykonania kodu bez uwierzytelnienia. Ze względu na centralną rolę tego systemu w zarządzaniu endpointami skutki udanego ataku mogą objąć znaczną część infrastruktury organizacji. Najważniejsze działania obronne to pilna aktualizacja, ograniczenie ekspozycji do Internetu oraz aktywne poszukiwanie śladów kompromitacji.

Źródła

https://securityaffairs.com/190158/security/critical-fortinet-forticlient-ems-flaw-exploited-for-remote-code-execution.html
https://securityaffairs.com/187787/security/critical-fortinet-forticlientems-flaw-allows-remote-code-execution.html
https://fortiguard.fortinet.com/psirt/FG-IR-25-1142
https://dashboard.shadowserver.org/statistics/iot-devices/time-series/?dataset=count&date_range=365&group_by=geo&limit=100&model=forticlient+enterprise+management+server+%28ems%29&stacking=stacked&type=security-management&vendor=fortinet

OpenAI łata luki w ChatGPT i Codex: ryzyko wycieku danych oraz przejęcia tokenów GitHub

Wprowadzenie do problemu / definicja

OpenAI usunęło dwie istotne podatności bezpieczeństwa dotyczące swoich narzędzi opartych na sztucznej inteligencji. Pierwsza luka umożliwiała niejawny wyciek danych z rozmów prowadzonych w ChatGPT, w tym treści wiadomości i przesyłanych plików, z pominięciem standardowych mechanizmów ochronnych. Druga dotyczyła usługi Codex i mogła prowadzić do przejęcia tokenów GitHub na skutek błędu typu command injection.

Sprawa pokazuje, że nowoczesne platformy AI nie są już wyłącznie interfejsami do generowania odpowiedzi. Coraz częściej pełnią rolę środowisk wykonawczych dla kodu, analizy danych i automatyzacji, a to znacząco zwiększa powierzchnię ataku.

W skrócie

Według ujawnionych informacji badacze z Check Point odkryli w ChatGPT lukę zero-day pozwalającą na wynoszenie wrażliwych danych bez wiedzy użytkownika. Mechanizm miał wykorzystywać ukryty kanał komunikacji oparty na DNS w środowisku Linux używanym przez funkcje analizy danych i wykonywania kodu. OpenAI wdrożyło poprawkę 20 lutego 2026 roku i nie odnotowano dowodów na aktywne wykorzystanie błędu w rzeczywistych atakach.

Niezależnie od tego BeyondTrust ujawnił krytyczną podatność w Codex. Problem wynikał z niewystarczającej sanityzacji nazwy gałęzi GitHub podczas tworzenia zadań, co umożliwiało wstrzyknięcie poleceń do kontenera agenta i w konsekwencji kradzież tokenów dostępowych GitHub. Poprawka została wdrożona 5 lutego 2026 roku.

Kontekst / historia

Oba incydenty wpisują się w szerszy trend związany z bezpieczeństwem agentów AI i platform wykonujących działania w imieniu użytkownika. W praktyce oznacza to przesunięcie granicy zaufania: system nie tylko interpretuje polecenia, ale może również uruchamiać kod, przetwarzać pliki, korzystać z tokenów dostępowych i komunikować się z usługami zewnętrznymi.

W takim modelu tradycyjne zabezpieczenia, takie jak blokowanie klasycznych połączeń wychodzących czy filtrowanie odpowiedzi modelu, nie zawsze są wystarczające. Jeżeli w tle działają słabiej kontrolowane kanały komunikacji albo backendy przyjmują nieprawidłowo walidowane dane wejściowe, możliwe staje się obejście zabezpieczeń logicznych bez wyraźnych alertów po stronie użytkownika.

Analiza techniczna

W przypadku ChatGPT problem wynikał z możliwości wykorzystania bocznego kanału komunikacyjnego dostępnego w środowisku Linux, w którym uruchamiane są zadania związane z analizą danych i wykonywaniem kodu. Zamiast klasycznej transmisji danych atak mógł kodować informacje w zapytaniach DNS. Taki mechanizm pozwala dzielić dane na fragmenty i umieszczać je w nazwach domen lub subdomen, a następnie odczytywać po stronie kontrolowanej przez atakującego.

Z perspektywy architektury bezpieczeństwa to szczególnie niebezpieczny scenariusz, ponieważ część warstw kontrolnych mogła zakładać brak możliwości bezpośredniego transferu danych na zewnątrz. Jeśli jednak runtime nadal mógł generować zapytania DNS, ruch ten nie musiał być traktowany jak standardowa eksfiltracja wymagająca ostrzeżenia lub zgody użytkownika. W praktyce pojedynczy złośliwy prompt albo specjalnie przygotowany niestandardowy agent mógł inicjować proces wycieku danych niemal niewidoczny z poziomu interfejsu.

Opis techniczny wskazuje również, że ten sam kanał mógł potencjalnie służyć do uzyskania zdalnej interakcji z runtime’em Linux i wykonywania poleceń. Oznacza to, że zagrożenie nie ograniczało się wyłącznie do biernego wycieku treści konwersacji, ale obejmowało także możliwość aktywnego oddziaływania na środowisko uruchomieniowe.

Druga luka, dotycząca Codex, miała charakter command injection. Podatność była związana z parametrem nazwy gałęzi GitHub przekazywanym podczas tworzenia zadania przez backend API. Jeżeli wejście nie zostało odpowiednio oczyszczone, możliwe było przemycenie poleceń systemowych wykonywanych wewnątrz kontenera agenta. W takim scenariuszu atakujący mógł doprowadzić do ujawnienia tokenu GitHub użytkownika, którego Codex używał do autoryzacji, a następnie wykorzystać go do dalszego dostępu do repozytoriów.

Tego typu błąd jest szczególnie groźny w środowiskach współdzielonych i zautomatyzowanych przepływach pracy. Jeśli agent AI uczestniczy w code review, obsłudze pull requestów albo pracuje na wspólnym repozytorium, przejęcie tokenu może umożliwić ruch boczny, odczyt i modyfikację kodu, a nawet trwałe osadzenie złośliwych zmian w pipeline’ach deweloperskich.

Konsekwencje / ryzyko

Najważniejszym skutkiem pierwszej podatności jest utrata poufności danych przekazywanych do systemu AI. Mogą to być informacje biznesowe, fragmenty kodu źródłowego, dane klientów, dokumenty wewnętrzne, a także dane osobowe przesyłane do analizy. Szczególnie niebezpieczny jest scenariusz, w którym użytkownik nie otrzymuje żadnego jednoznacznego sygnału, że dane opuszczają zaufane środowisko.

W przypadku Codex ryzyko obejmuje nie tylko ujawnienie poświadczeń, ale również naruszenie procesu wytwarzania oprogramowania. Token GitHub z odpowiednimi uprawnieniami może otworzyć drogę do kradzieży własności intelektualnej, modyfikacji kodu, sabotażu buildów, kompromitacji sekretów przechowywanych w repozytorium oraz eskalacji do innych systemów zintegrowanych z platformą deweloperską.

Z punktu widzenia organizacji oba przypadki pokazują, że narzędzia AI należy traktować jak uprzywilejowane komponenty infrastruktury. Jeżeli mają dostęp do danych wrażliwych, repozytoriów, środowisk chmurowych i procesów CI/CD, ich kompromitacja może mieć skutki porównywalne z naruszeniem kluczowych systemów administracyjnych.

Rekomendacje

Organizacje powinny wdrożyć dodatkową warstwę kontroli bezpieczeństwa dla narzędzi AI, zamiast polegać wyłącznie na natywnych mechanizmach dostawcy. W praktyce oznacza to monitorowanie ruchu sieciowego związanego z runtime’ami AI, w tym nietypowych wzorców DNS, kontrolę dostępu do danych przesyłanych do modeli oraz inspekcję działań wykonywanych przez agentów.

Konieczne jest także ograniczanie uprawnień zgodnie z zasadą najmniejszych uprawnień. Tokeny używane przez agentów kodujących powinny mieć możliwie wąski zakres, krótki czas życia oraz separację między projektami. Warto wdrożyć mechanizmy rotacji poświadczeń, dodatkową autoryzację dla operacji wysokiego ryzyka oraz segmentację repozytoriów i środowisk wykonawczych.

blokowanie lub filtrowanie nieautoryzowanych niestandardowych agentów i rozszerzeń,
traktowanie prompt injection jako realnego wektora ataku,
walidacja i sanityzacja wszystkich danych wejściowych trafiających do backendów obsługujących agentów,
rejestrowanie działań wykonywanych przez AI w kontenerach i pipeline’ach,
regularne przeglądy uprawnień nadawanych integracjom z GitHub i innymi systemami deweloperskimi.

Z perspektywy użytkowników końcowych kluczowa pozostaje ostrożność wobec promptów obiecujących ukryte funkcje, odblokowanie dodatkowych możliwości lub nietypową optymalizację działania narzędzia. W środowisku firmowym warto również ograniczać możliwość przesyłania do chatbotów danych, które nie zostały wcześniej sklasyfikowane pod kątem poufności.

Podsumowanie

Załatane przez OpenAI podatności pokazują, że wraz z rozwojem agentów AI rośnie znaczenie klasycznych zagadnień bezpieczeństwa aplikacyjnego: izolacji środowisk, kontroli kanałów komunikacji, sanityzacji wejścia i ochrony poświadczeń. Przypadek ChatGPT ujawnia ryzyko ukrytej eksfiltracji danych przez kanały boczne, natomiast luka w Codex podkreśla, że agenci programistyczni stają się atrakcyjnym celem ze względu na dostęp do kodu i uprzywilejowanych tokenów.

Dla przedsiębiorstw najważniejszy wniosek jest prosty: AI nie może być traktowane jako zaufana czarna skrzynka. Narzędzia tego typu wymagają takiego samego poziomu nadzoru, twardych kontroli i modelowania zagrożeń jak każdy inny krytyczny element nowoczesnej infrastruktury IT.

Źródła

https://thehackernews.com/2026/03/openai-patches-chatgpt-data.html
https://openai.com/
https://research.checkpoint.com/
https://www.beyondtrust.com/