Tydzień od 16 do 22 lutego 2026 roku okazał się jednym z bardziej intensywnych w tym roku, nie tylko ze względu na liczbę incydentów, ale bardziej o ich charakter.

‍

Każde ze zdarzeń, które trafiło na pierwsze strony branżowych serwisów, ilustruje odrębną kategorię ryzyka: błąd wewnętrzny w procesie zarządzania zmianą, ofensywne wykorzystanie generatywnej sztucznej inteligencji (GenAI), skutecznie eksploatowane luki w infrastrukturze krytycznej i, co warto odnotować osobno, awarię dostępności wywołaną nie przez atakującego, lecz przez samą organizację.

‍

Z perspektywy zarządzania ryzykiem operacyjnym każda z tych historii prowadzi do innego wniosku, ale wszystkie mają wspólną myśl przewodnią:

‍

‍

Ochrona przed zagrożeniami zewnętrznymi nie zastąpi dyscypliny wewnętrznej.

‍

‍

PayPal i 165 dni otwartej podatności

‍

‍

Sprawa PayPala to klasyczny przykład incydentu, który formalnie nie był „naruszeniem systemów", ale dla osób, których dane wyciekły, ma to niewielkie znaczenie praktyczne.

‍

Błąd w aplikacji pożyczkowej PayPal WorkingCapital (PPWC) ujawnił dane osobowe klientów, w tym numery Social Security(odpowiednik PESEL w Stanach Zjednoczonych), daty urodzenia, adresy, numery telefonów i adresy e-mail. Podatność widniała w systemie od 1 lipca do 13 grudnia 2025 roku, a więc 165 dni,  zanim PayPal wykrył problem i wycofał wadliwą zmianę kodu następnego dnia. Za to pisma z powiadomieniem o naruszeniu trafiły do klientów dopiero 10 lutego 2026 r., czyli ponad dwa miesiące po zamknięciu incydentu!

‍

Skala klientów dotkniętych bezpośrednio incydentem była ograniczona – PayPal mówi o około stu osobach, ale kombinacja numer uubezpieczenia społecznego z pozostałymi danymi tworzy profil idealny do kradzieży tożsamości i przejęcia konta. Co istotne, kilka z tych kont odnotowało nieautoryzowane transakcje, co potwierdza, że dane zostały faktycznie wykorzystane. PayPal potwierdził zwrot środków poszkodowanym klientom.

‍

Na marginesie warto odnotować niespójność w komunikacji, która sama w sobie jest ilustracją problemu. Oficjalne powiadomienie złożone przez PayPala w urzędzie prokuratora generalnego stanu Massachusetts mówi o „unauthorized access to PayPal's systems" – nieautoryzowanym dostępie dosystemów PayPala. Rzecznik prasowy firmy, pytany przez media kilka dni później, stwierdził natomiast, że „PayPal's systems were not compromised" – systemyPayPala nie zostały naruszone. Obie wypowiedzi jednocześnie mog być prawdziwe i są możliwe do uzasadnienia, ale razem tworzą komunikat, który stawia audytorów i organy nadzoru w niekomfortowej sytuacji. Która wersja obowiązuje i jak to wpływa na obowiązki dotyczące powiadamiania? O wzorcowej komunikacji kryzysowej pisaliśmy już wcześniej - zachęcam do lektury.

‍

W polskich realiach, gdzie Urząd OchronyDanych Osobowych (UODO) i Komisja Nadzoru Finansowego (KNF) oczekują precyzji w zgłoszeniach incydentów, taka rozbieżność między dokumentem formalnym a komunikatem PR byłaby problematyczna sama w sobie.

‍

Z punktu widzenia zarządzania ryzykiem operacyjnym sprawa pokazuje, jak jeden błąd w procesie kontroli zmiany może stworzyć podatność, która przez kilka miesięcy pozostaje niewykryta.To wskazuje na zakres lub jakość audytu kodu i testów środowiskowych, które powinny obejmować oprócz badania funkcjonalności, także kontrolę dostępu do danych.

‍

W kontekście polskich regulacji, takich jak ustawa o Krajowym Systemie Cyberbezpieczeństwa (KSC) i unijne rozporządzenie ooperacyjnej odporności cyfrowej sektora finansowego (DORA, Digital OperationalResilience Act), obowiązek powiadamiania o incydentach i wymagania dotyczące zarządzania zmianą i kontrolą dostępu nabierają szczególnego znaczenia.

‍

‍

Wykorzystanie AI do budowy narzędzi ataku

‍

Przez lata mówiono o sztucznej inteligencji głównie w kontekście obrony – systemy wykrywania anomalii, korelacja zdarzeń,wsparcie analityków w centrach operacji bezpieczeństwa (SOC, Security Operations Center).

‍

W tygodniu od 16 do 22 lutego 2026 roku branżowe media potwierdziły odwrotny przypadek – sprawca wykorzystał komercyjne usługi GenAI do przejęcia ponad 600 urządzeń FortiGate – firewalli i bram sieciowych używanych przez duże organizacje na całym świecie. To, co wcześniej wymagało wyspecjalizowanego zespołu, stało się dostępne dla podmiotu dysponującego budżetem i dostępem do interfejsu programistycznego (API, Application Programming Interface).

‍

Niemal równolegle opublikowano analizę frameworku złośliwego oprogramowania dla systemów Linux o nazwie VoidLink,który według badaczy został napisany przy pomocy agenta kodującego opartego namodelu językowym. Dowody znaleziono w binarnym pliku produkcyjnym w postaci etykiet „Phase X:" i rozbudowanego logowania diagnostycznego, których nikt nie usunął przed wdrożeniem.

‍

VoidLink celuje w środowiska chmurowe Amazon Web Services, Google Cloud Platform, Microsoft Azure, Alibaba Cloud i TencentCloud, a przy tym posiada zdolności rootkita – złośliwego oprogramowania działającego na poziomie jądra systemu operacyjnego (o wykorzystaniu AI do tworzenia złośliwego oprogramowania wspominaliśmy też wcześniej.)

‍

Dla organizacji posiadających rozproszoną infrastrukturę chmurową, a takich w polskim sektorze finansowym i energetycznym nie brakuje, oba przypadki wymagają przeglądu modelu zagrożeń (threat model, mapa potencjalnych scenariuszy ataku i ich skutków). Narzędzia ofensywne budowane z pomocą GenAI nie są jeszcze wszechobecne, ale tempo ich dojrzewania nie pozostawia złudzeń co do kierunku rozwoju.

‍

‍

BeyondTrust, Ivanti i Chrome, czyli tydzień awaryjnych łatek

‍

Tygodniowy raport telemetryczny GreyNoise wskazał na skoncentrowany atak na krytyczną lukę zdalnego wykonania kodu (RCE, Remote Code Execution) w urządzeniach BeyondTrust. Osiemdziesiąt trzy procent prób pochodziło z jednego adresu IP. Jest to dowód na to, jak z jednego miejsca można spowodować incydent o potencjalnie globalnym zasięgu.

‍

Z perspektywy zespołów bezpieczeństwa ważniejsza jest jednak sama podatność. Atakujący otwierali połączenia WebSocket (protokół komunikacji dwukierunkowej w czasie rzeczywistym) i przesyłali zniekształcone wartości parametrów, by osiągnąć wykonanie kodu po stronie serwera. Jeden aktywny adres IP oznacza, że informacja o luce nie rozeszła się szerzej, a więc organizacje, które nie zdążyły wdrożyć łatki, miały po prostu szczęście.

‍

Z metodycznego punktu widzenia taki incydent warto traktować jako zdarzenie potencjalnie katastrofalne, któremu zapobiegł przypadek (okoliczność zewnętrzna), a nie własne środki kontroli. Większość analiz post mortem koncentruje się na tym, co faktycznie wystąpiło: przyczyna, wektor ataku, rzeczywisty wpływ. Pytanie „co by się stało, gdyby atakujący był mniej dyskretny?" formalnie pojawia się rzadko. W praktyce większość raportów po incydentach zamyka się w granicach tego, co było, a szczęśliwy przypadek zostaje wbudowany w ocenę jako domyślny element kontrolny, zamiast być traktowany jako sygnał ostrzegawczy, który wymaga uwzględnienia w planie postępowania z ryzykiem.

‍

W tym samym tygodniu Google wydało awaryjną aktualizację przeglądarki Chrome naprawiającą lukę przepełnienia bufora sterty (heap buffer overflow) sklasyfikowaną jako poważną w wysokim stopniu. Ivanti EPMM,Splunk Enterprise i Windows Admin Center również otrzymały krytyczne łatki, przy czym kilka z nich dotyczyło podatności już aktywnie eksploatowanych przez przestępców.

‍

Dla firm operujących zgodnie z wymaganiami NIS2 lub przygotowujących się do certyfikacji ISO 27001 taki tydzień to konkretny test procesu zarządzania podatnościami (vulnerability management). Warto sprawdzić przy tej okazji, czy cykl od publikacji identyfikatora podatności CVE (Common Vulnerabilities and Exposures) do wdrożenia łatki faktycznie mieści się w przyjętych parametrach? Czas reakcji na podatności urządzeń brzegowychto jeden z parametrów decydujących o tym, czy organizacja pozostaje nierentownym celem dla przestępcy. Czy przeglądarki pracowników są aktualizowane automatycznie, czy zależy to od indywidualnej inicjatywy pracownika?

‍

‍

Hellcat i Ascom, czyli infostealer jako brama wejściowa

‍

Grupa ransomware Hellcat naruszyła bezpieczeństwo infrastruktury technicznej firmy Ascom, eksfiltrując około 44 GBdanych, w tym kod źródłowy, szczegóły projektów, faktury i dokumenty poufne.Wektorem wejścia były dane uwierzytelniające do systemu Jira, wcześniej skradzione przez złośliwe oprogramowanie wykradające dane (infostealer).

‍

To schemat, który obserwujemy od kilku lat i który konsekwentnie jest niedoceniany w modelach ryzyka – złośliwe oprogramowanie działające na urządzeniu pracownika przez dni lub tygodnie, zbierające hasła, tokeny sesji i pliki konfiguracyjne, zanim przejęte dane zostaną sprzedane lub wykorzystane do włamania.

‍

Z perspektywy ciągłości działania (BCM, Business Continuity Management) eksfiltracja kodu źródłowego i dokumentacji projektowej to oprócz ryzyka reputacyjnego także zagrożenie dla przyszłych projektów, ujawnienie architektury systemów i informacja wywiadowcza dla konkurencji lub kolejnych atakujących - także atakujcych Twoich klientów.

‍

Ograniczenie tego ryzyka wymaga widoczności na poziomie urządzenia końcowego – narzędzia klasy EDR (Endpoint Detection and Response) wykrywają charakterystyczne zachowania infostealerów zanim skradzione dane trafią na sprzedaż – oraz skrócenia czasu życia tokenów sesji, które dla operatorów tego oprogramowania są równie wartościowe co hasła.

‍

‍

Niedostępność Cloudflare

‍

Zdarzenie, które domknęło tydzień, miało inne źródło. 21 lutego 2026 roku Cloudflare – jeden z największych dostawców usług sieciowych i bezpieczeństwa na świecie –doświadczył sześciogodzinnej globalnej awarii. Przyczyną był kaskadowy błąd wywołany rotacją haseł, który przełożył się na niedostępność wielu linii produktowych dla klientów na całym świecie.

‍

To zdarzenie jest warte osobnej analizy z perspektywy zarządzania ryzykiem stron trzecich (TPRM, Third Party Risk Management). Cloudflare w każdej standardowej ocenie dostawcy uzyskałby najwyższą notę. Ma dojrzałe procesy, certyfikacje, redundancja jest napoziomie infrastruktury globalnej. Jednak mimo to przez sześć godzin był niedostępny z powodu jednego błędu operacyjnego, który uruchomił kaskadę awarii. Rzadko który arkusz oceny TPRM to przewidział, bo rzadko kto pyta o scenariusz, w którym dostawca sam sobie wyrządza szkodę. Tymczasem Cloudflare ma już historię awarii „na własne życzenie".

‍

To wskazuje na lukę, która zaskakująco często pojawia się w ocenie ryzyka pod kątem ciągłości działania. Kluczowi dostawcy, dla których nie mamy alternatywy, są traktowani jako elementy stałe –bezpieczne z definicji, bo teoretycznie są znakomicie zabezpieczone. Tymczasem scenariusz niedostępności powinien być zawsze uwzględniany w planach, niezależnie od poziomu zabezpieczeń. Może go spowodować błąd ludzki, awaria procesu, nieszczęśliwy zbieg okoliczności. Dla planowania BCM oznacza to konkretną zasadę:

‍

Jeśli niedostępność dostawcy generuje katastrofalne skutki dla organizacji, scenariusz jego niedostępności musi znaleźć się w planie – niezależnie od przyczyny. Jeśli wpływ zdarzenia jest nieakceptowalny, prawdopodobieństwo jego wystąpienia nie może być kryterium do jego uwzględnienia w planie.

‍

Organizacje korzystające z Cloudflare do ochrony przed atakami DDoS (Distributed Denial of Service, rozproszone ataki odmowy usługi), do przyspieszonego dostarczania treści lub do zarządzania ruchem sieciowym nagle przekonały się, że ich zależność od jednego dostawcy może być „single point of failure”, niezależnie od jakości jego zabezpieczeń. W kontekście budowania odporności operacyjnej to argument za regularnym przeglądem zależności od dostawców usług krytycznych.

‍

Lessons learned

‍

Każdy z pięciu opisanych incydentów wymagałinnych działań prewencyjnych, ale kilka wspólnych mianowników narzuca się samo.

‍

Na przykładzie PayPala należy uznać, że istnienie podatności przez 165 dni bez wykrycia to argument za wprowadzeniem ciągłego monitoringu kontroli dostępu do danych na poziomie aplikacji. Testy funkcjonalne wykonywane przy każdej zmianie nie są wystarczające.

‍

Modele zagrożeń powinny uwzględniać scenariusze ataku wspomaganego przez sztuczną inteligencję, bo próg wejścia dla zaawansowanych ataków systematycznie spada. Procesy zarządzania podatnościami muszą działać w dniach, nie tygodniach.

‍

Takie tygodnie, jak ostatni – z pięcioma krytycznymi CVE jednocześnie – będą zdarzać się coraz częściej. Plany ciągłości działania powinny zawierać oprócz scenariuszy ataków zewnętrznych, także scenariusze całkowitej niedostępności kluczowych dostawców – w tym dostawców usług infrastrukturalnych.

‍

Żaden z tych wniosków nie jest nowy, ale każdy tydzień, który przynosi tak rozległą listę incydentów, jest dobrym momentem, by sprawdzić, czy wnioski faktycznie przełożyły się na wdrożone i działające środki kontroli. Najlepszą formą nauki jest wszak nauka na cudzych błędach.

‍

‍

‍

‍