Archiwa: AI - Strona 55 z 99 - Security Bez Tabu

Ponad 1000 publicznie dostępnych instancji ComfyUI celem botnetu do cryptominingu

Wprowadzenie do problemu / definicja

ComfyUI to popularna platforma do budowy workflow opartych o modele generatywne, rozwijana w modelu rozszerzeń i tzw. custom nodes. Taka architektura zwiększa elastyczność środowiska, ale jednocześnie znacząco poszerza powierzchnię ataku. Najnowsze ustalenia pokazują, że publicznie wystawione instancje ComfyUI są aktywnie wykorzystywane przez operatorów botnetu do zdalnego uruchamiania kodu, instalacji koparek kryptowalut oraz tworzenia infrastruktury proxy.

W skrócie

Badacze zaobserwowali aktywną kampanię wymierzoną w internetowo dostępne instancje ComfyUI. Atakujący skanują zakresy adresów IP w chmurach publicznych, identyfikują podatne wdrożenia i wykorzystują niebezpieczne lub błędnie zabezpieczone custom nodes do osiągnięcia zdalnego wykonania kodu.

Celem kampanii są publicznie dostępne instancje ComfyUI.
Wektor wejścia opiera się na podatnych lub ryzykownych custom nodes.
Po skutecznym ataku wdrażane są komponenty do kopania Monero z użyciem XMRig.
Na przejętych hostach uruchamiane są również dodatkowe mechanizmy monetyzacji i elementy infrastruktury proxy.
Powierzchnia ataku obejmuje ponad tysiąc publicznie dostępnych instancji.

Kontekst / historia

ComfyUI zdobyło popularność jako elastyczne narzędzie do budowania graficznych pipeline’ów dla generatywnej AI. Kluczową cechą platformy jest obsługa niestandardowych węzłów, które mogą rozszerzać zarówno backend, jak i frontend aplikacji. W praktyce oznacza to, że bezpieczeństwo całego środowiska zależy nie tylko od rdzenia aplikacji, ale również od jakości oraz modelu zaufania wobec zewnętrznych dodatków.

Już wcześniej badacze bezpieczeństwa wskazywali, że ekosystem custom nodes może prowadzić do pełnego przejęcia serwera. Problem wynika między innymi z tego, że wybrane rozszerzenia przyjmują dane wejściowe umożliwiające uruchamianie kodu Pythona lub modyfikację sposobu instalacji pakietów. W środowiskach wystawionych bez odpowiedniej kontroli dostępu taka funkcjonalność staje się praktycznym wektorem RCE.

Obecna kampania wpisuje się w szerszy trend automatycznego wyszukiwania słabo zabezpieczonych usług internetowych i przekształcania ich w źródło przychodu. W tym modelu operatorzy nie muszą uzyskiwać trwałego, ręcznego dostępu do organizacji. Wystarczy masowe odnajdywanie podatnych usług, wdrażanie złośliwych komponentów i utrzymywanie infekcji tak długo, jak to możliwe.

Analiza techniczna

Z ustaleń badaczy wynika, że kampania opiera się na wyspecjalizowanych skanerach napisanych w Pythonie. Ich zadaniem jest przeszukiwanie publicznych zakresów IP, identyfikacja instancji ComfyUI oraz sprawdzanie, czy na serwerze zainstalowano podatne lub niebezpieczne rodziny custom nodes. Jeżeli odpowiedni węzeł jest obecny, atakujący wykorzystuje go do dostarczenia własnego ładunku wykonywalnego.

Szczególnie istotne jest to, że niektóre custom nodes pozwalają przekazywać surowy kod Pythona jako dane wejściowe i wykonywać go po stronie serwera. W praktyce zamienia to funkcję workflow w kanał egzekucji poleceń. Jeżeli na celu nie ma już podatnego komponentu, operatorzy sprawdzają obecność ComfyUI-Manager. Ten moduł upraszcza instalację nowych rozszerzeń i w określonych scenariuszach może zostać wykorzystany do doinstalowania złośliwego lub podatnego pakietu, a następnie ponowienia próby eksploatacji.

Mechanizm działania kampanii wskazuje na wysoki poziom automatyzacji. Po uzyskaniu RCE wdrażany jest skrypt powłoki odpowiedzialny za przygotowanie hosta do dalszego wykorzystania i monetyzacji.

Wyłączanie lub ograniczanie artefaktów utrudniających ukrycie aktywności.
Zatrzymywanie konkurencyjnych minerów.
Uruchamianie procesów kopiących kryptowaluty.
Ustanawianie mechanizmów trwałości.
Przygotowanie hosta do dalszego wykorzystania jako węzeł proxy.

W opisywanej operacji wykorzystywano między innymi XMRig do kopania Monero oraz lolMiner do dodatkowej monetyzacji. Badacze opisali również użycie technik ukrywania procesu z pomocą mechanizmów takich jak LD_PRELOAD oraz utrwalania infekcji poprzez ponowne pobieranie skryptu w regularnych odstępach czasu. Dodatkowo złośliwe pliki kopiowano do wielu lokalizacji zapasowych, a część artefaktów blokowano przed usunięciem przy użyciu atrybutów plików, co utrudniało remediację.

Ważnym elementem operacji było także czyszczenie historii promptów ComfyUI po skutecznym wykorzystaniu podatności, co miało ograniczyć widoczność śladów ataku. Zainfekowane hosty były następnie zarządzane centralnie z panelu C2 opartego o Flask, umożliwiającego przesyłanie poleceń i wdrażanie kolejnych komponentów. Jednym z nich był Hysteria V2, co sugeruje dodatkowy cel w postaci sprzedaży lub wykorzystania przejętych maszyn jako serwerów proxy.

Konsekwencje / ryzyko

Ryzyko dla organizacji korzystających z ComfyUI jest wielowarstwowe. Najbardziej oczywistym skutkiem jest cryptojacking, czyli nieautoryzowane wykorzystanie CPU i GPU do kopania kryptowalut. Prowadzi to do wzrostu kosztów energii i usług chmurowych, degradacji wydajności oraz skrócenia żywotności zasobów sprzętowych.

Znacznie poważniejsze są jednak skutki wtórne. Host przejęty przez operatora botnetu może zostać użyty jako:

punkt wyjścia do dalszej penetracji środowiska,
węzeł proxy do ukrywania ruchu przestępczego,
element infrastruktury C2 lub DDoS,
platforma do wdrożenia kolejnych ładunków malware.

W środowiskach chmurowych i laboratoryjnych instancje ComfyUI bywają uruchamiane szybko, bez segmentacji i bez reverse proxy z uwierzytelnianiem. To zwiększa prawdopodobieństwo ekspozycji usług administracyjnych bez jakiejkolwiek kontroli dostępu. Dodatkowym problemem jest niski próg wejścia po stronie atakującego: jeśli platforma akceptuje workflow lub dodatki od osób trzecich, podatne custom nodes mogą stać się naturalnym punktem wejścia.

Rekomendacje

Podstawowym działaniem obronnym jest natychmiastowe wyeliminowanie publicznej ekspozycji ComfyUI wszędzie tam, gdzie nie jest ona absolutnie niezbędna. Usługa nie powinna być dostępna bezpośrednio z internetu. Zalecane jest umieszczenie jej za reverse proxy z silnym uwierzytelnianiem, kontrolą dostępu oraz filtrowaniem źródeł ruchu.

Organizacje powinny również wdrożyć zestaw działań ograniczających ryzyko kompromitacji i utrudniających utrzymanie infekcji.

Przeprowadzić inwentaryzację wszystkich instancji ComfyUI i sprawdzić ich dostępność z internetu.
Zidentyfikować zainstalowane custom nodes oraz usunąć rozszerzenia o nieznanym pochodzeniu.
Ograniczyć lub całkowicie zablokować możliwość instalacji nowych node’ów z poziomu interfejsu.
Monitorować procesy XMRig, lolMiner i nietypowe połączenia wychodzące.
Sprawdzać obecność mechanizmów trwałości, zadań cyklicznych i nietypowych atrybutów plików.
Wdrożyć segmentację sieci, aby środowisko AI nie miało nadmiernych uprawnień do innych systemów.
Przeanalizować logi systemowe, historię procesów i zmiany w katalogach custom_nodes.
Traktować importowane workflow JSON i zewnętrzne dodatki jako niezaufane artefakty.

W praktyce bezpieczna eksploatacja ComfyUI wymaga takiego samego podejścia jak w przypadku innych platform pluginowych: minimalnego zaufania, przeglądu łańcucha dostaw oraz kontroli uprawnień wykonawczych. Jeżeli istnieje podejrzenie kompromitacji, samo usunięcie minera często nie wystarcza. Należy założyć możliwość pełnego przejęcia hosta i przeprowadzić pełne dochodzenie powłamaniowe, a w razie potrzeby odbudować system z zaufanego obrazu.

Podsumowanie

Kampania wymierzona w publicznie dostępne instancje ComfyUI pokazuje, że narzędzia AI stają się pełnoprawnym celem operacji malware i cryptojackingu. Kluczowym problemem nie jest wyłącznie pojedyncza luka, lecz model rozszerzeń umożliwiający wykonywanie niebezpiecznych operacji po stronie serwera. W połączeniu z błędną ekspozycją usługi do internetu daje to atakującym prostą drogę do RCE, trwałości i monetyzacji przejętych zasobów. Dla zespołów bezpieczeństwa oznacza to konieczność objęcia platform AI tymi samymi rygorami ochrony, które od lat stosuje się wobec paneli administracyjnych, serwerów aplikacyjnych i środowisk DevOps.

Źródła

The Hacker News – Over 1,000 Exposed ComfyUI Instances Targeted in Cryptomining Botnet Campaign — https://thehackernews.com/2026/04/over-1000-exposed-comfyui-instances.html
Snyk Labs – Don’t Get Too Comfortable: Hacking ComfyUI Through Custom Nodes — https://labs.snyk.io/resources/hacking-comfyui-through-custom-nodes/
ComfyUI Documentation – Custom Nodes — https://docs.comfy.org/development/core-concepts/custom-nodes
GitHub – ComfyUI-Manager — https://github.com/Comfy-Org/ComfyUI-Manager

GPUBreach: nowy atak RowHammer na GPU umożliwia eskalację uprawnień do root

Wprowadzenie do problemu / definicja

GPUBreach to nowo opisany atak sprzętowy, który wykorzystuje zjawisko RowHammer w pamięci GDDR6 kart graficznych. Badanie pokazuje, że kontrolowane błędy bitowe w pamięci GPU mogą prowadzić nie tylko do naruszenia integralności danych, ale również do przejęcia kontroli nad pamięcią akceleratora, a w dalszej kolejności do eskalacji uprawnień po stronie systemu hosta.

To ważny sygnał dla organizacji korzystających z GPU w środowiskach AI, HPC oraz infrastrukturze wielodostępnej. Dotychczas zagrożenia związane z akceleratorami często traktowano głównie jako problem stabilności obliczeń lub jakości wyników. GPUBreach pokazuje, że stawką może być pełne przejęcie systemu.

W skrócie

Nowy wariant ataku rozszerza wcześniejsze badania nad RowHammer na GPU i dowodzi, że bit-flipy w pamięci GDDR6 mogą zostać wykorzystane do naruszenia integralności tablic stron GPU. W efekcie proces nieuprzywilejowany może uzyskać arbitralny odczyt i zapis pamięci GPU.

Następnie atak może przejść z poziomu akceleratora do systemu hosta. Wykorzystanie zaufanych buforów sterownika oraz błędów bezpieczeństwa pamięci w sterowniku NVIDIA pozwala, według opisanego scenariusza, doprowadzić do eskalacji uprawnień i uruchomienia powłoki root. Szczególnie istotne jest to, że aktywne IOMMU nie musi zatrzymać takiego łańcucha ataku.

atak zaczyna się od bit-flipów w pamięci GDDR6,
prowadzi do przejęcia logicznej kontroli nad pamięcią GPU,
umożliwia naruszenie zaufanego stanu sterownika,
może zakończyć się eskalacją uprawnień do poziomu root.

Kontekst / historia

RowHammer od lat pozostaje jednym z najważniejszych problemów bezpieczeństwa pamięci DRAM. Mechanizm polega na intensywnym odwoływaniu się do wybranych wierszy pamięci, co wskutek zakłóceń elektrycznych może wywoływać niezamierzoną zmianę bitów w sąsiednich obszarach. Historycznie ataki tego typu były przede wszystkim kojarzone z pamięcią systemową i przełamywaniem izolacji między procesami, maszynami wirtualnymi lub komponentami jądra.

Z czasem pojawiły się mechanizmy obronne, takie jak ECC i techniki odświeżania wierszy pamięci, jednak literatura badawcza wielokrotnie pokazywała, że zabezpieczenia te nie eliminują ryzyka całkowicie. W 2025 roku opisano GPUHammer, który wykazał praktyczne wykorzystanie RowHammer przeciwko układom NVIDIA z pamięcią GDDR6. Tamten scenariusz skupiał się głównie na degradacji integralności danych i pogarszaniu wyników obciążeń uczenia maszynowego.

GPUBreach stanowi kolejny etap rozwoju tej klasy zagrożeń. Równolegle opisano także techniki GDDRHammer oraz GeForge, również koncentrujące się na korupcji struktur translacji adresów po stronie GPU. Na ich tle GPUBreach wyróżnia się tym, że nie kończy się na zakłóceniu obliczeń, lecz prowadzi do pełnej eskalacji uprawnień po stronie CPU.

Analiza techniczna

Techniczna istota ataku sprowadza się do wywołania kontrolowanych bit-flipów w pamięci GDDR6 i użycia ich do uszkodzenia tablic stron GPU. Jeśli atakujący zmieni krytyczne pola wpisów mapowania pamięci, może uzyskać znacznie szerszy dostęp do zasobów akceleratora, niż przewiduje model uprawnień. W praktyce daje to arbitralny odczyt i zapis pamięci GPU.

Na tym etapie atak nie zatrzymuje się na samej karcie graficznej. Przejęty logicznie GPU może wykonywać operacje DMA do obszarów pamięci hosta, które są dozwolone przez IOMMU, ponieważ należą do zaufanych buforów sterownika. To kluczowy element całego scenariusza: zamiast bezpośrednio omijać IOMMU, atak wykorzystuje legalnie dostępne ścieżki komunikacji i zaufane struktury pamięci.

Kolejny krok polega na naruszeniu stanu sterownika. Korupcja danych w zaufanych buforach może aktywować błędy bezpieczeństwa pamięci w sterowniku jądra NVIDIA, w tym zapisy poza dozwolony zakres. Gdy atakujący uzyska prymityw arbitralnego zapisu w przestrzeni jądra, możliwa staje się klasyczna eskalacja uprawnień i przejęcie kontroli nad systemem operacyjnym.

atak wychodzi poza prostą degradację danych i prowadzi do przejęcia kontroli,
obejmuje zarówno pamięć GPU, jak i pamięć hosta,
pokazuje ograniczenia ochrony opartej wyłącznie na IOMMU,
wskazuje na nowe znaczenie bezpieczeństwa sterowników GPU.

Badacze zwracają też uwagę na skutki uboczne tej klasy ataków. Obejmują one możliwość wycieku kluczy kryptograficznych z bibliotek obliczeniowych oraz sabotażu obciążeń AI poprzez obniżenie jakości wyników modeli.

Konsekwencje / ryzyko

Znaczenie GPUBreach wykracza poza laboratoria badawcze. Ryzyko dotyczy organizacji wykorzystujących GPU do trenowania modeli, inferencji, przetwarzania danych wrażliwych, kryptografii, symulacji naukowych oraz obliczeń wielodostępnych. W praktyce oznacza to zagrożenie zarówno dla nowoczesnych centrów danych, jak i środowisk chmurowych czy klastrów badawczych.

Najważniejszą konsekwencją jest możliwość eskalacji uprawnień z poziomu procesu nieuprzywilejowanego do poziomu root. Równie poważne są naruszenie poufności danych przetwarzanych przez GPU i host, ryzyko wycieku materiału kryptograficznego oraz degradacja integralności wyników obciążeń AI i HPC.

Szczególnie narażone są środowiska współdzielone, w których wielu użytkowników korzysta z tego samego akceleratora lub hosta z dostępem do GPU. W takich architekturach lokalny użytkownik albo uruchomiony kontener może potencjalnie przekroczyć granice izolacji. To zwiększa wagę problemu dla usług GPU-as-a-Service, chmury publicznej oraz środowisk produkcyjnych obsługujących modele sztucznej inteligencji.

Dodatkowym wyzwaniem pozostaje ograniczona skuteczność mitigacji. ECC może stanowić ważną warstwę ochronną, ale nie daje gwarancji pełnego bezpieczeństwa. W przypadku desktopowych i mobilnych GPU, gdzie ECC często nie jest dostępne, możliwości obrony są jeszcze mniejsze.

Rekomendacje

Organizacje korzystające z akceleratorów graficznych powinny potraktować GPUBreach jako realne zagrożenie infrastrukturalne. Problem nie dotyczy wyłącznie integralności obliczeń, lecz całego modelu zaufania wokół GPU, sterowników i pamięci hosta.

włączyć ECC tam, gdzie sprzęt i stos programowy to umożliwiają,
ograniczyć współdzielenie GPU pomiędzy różnymi poziomami zaufania,
rozdzielać obciążenia kryptograficzne i wrażliwe od kodu nieuprzywilejowanego,
aktualizować sterowniki GPU i komponenty jądra natychmiast po publikacji poprawek,
przeglądnąć konfigurację IOMMU, pamiętając, że nie rozwiązuje ona samodzielnie tej klasy problemu,
wdrożyć monitoring anomalii w zadaniach GPU i nietypowych błędów sterownika,
przeanalizować ryzyko dla środowisk CUDA, AI i HPC z perspektywy lokalnego atakującego,
ograniczyć możliwość uruchamiania niezweryfikowanego kodu na hostach z dostępem do akceleratorów.

W środowiskach chmurowych i badawczych warto dodatkowo stosować silniejszą segmentację najemców, rozważyć dedykowanie GPU dla krytycznych obciążeń oraz walidować integralność wyników modeli. Ataki sprzętowe na GPU powinny zostać włączone do modelu zagrożeń i scenariuszy red teamingowych.

Podsumowanie

GPUBreach pokazuje, że bezpieczeństwo GPU staje się integralną częścią bezpieczeństwa systemowego. Atak oparty na RowHammer w pamięci GDDR6 nie ogranicza się już do cichej korupcji danych czy pogorszenia jakości modeli AI. W opisanym scenariuszu możliwe jest przejęcie kontroli nad pamięcią GPU, wykorzystanie zaufanych ścieżek DMA oraz finalna eskalacja uprawnień do poziomu root.

Dla organizacji korzystających z akceleratorów w AI, chmurze i HPC oznacza to konieczność rewizji modelu zagrożeń, segmentacji środowisk oraz priorytetowego traktowania zabezpieczeń sprzętowo-systemowych. GPU przestaje być wyłącznie silnikiem obliczeniowym, a staje się pełnoprawnym elementem powierzchni ataku.

Źródła

https://thehackernews.com/2026/04/new-gpubreach-attack-enables-full-cpu.html
https://gpubreach.ca/
https://gddr.fail/
https://developer.nvidia.com/blog/introducing-nvidia-cupqc-for-gpu-accelerated-post-quantum-cryptography/
https://nvidia.custhelp.com/app/answers/detail/a_id/3571/

Krytyczna luka RCE w Flowise aktywnie wykorzystywana. Ponad 12 tys. instancji pozostaje narażonych

Wprowadzenie do problemu / definicja

Flowise to otwartoźródłowa platforma służąca do budowy przepływów AI, agentów oraz integracji z modelami językowymi i usługami zewnętrznymi. W centrum najnowszych ostrzeżeń bezpieczeństwa znalazła się podatność CVE-2025-59528, oceniona na 10.0 w skali CVSS, która umożliwia zdalne wykonanie kodu na serwerze aplikacji.

W praktyce oznacza to, że atakujący może przejąć kontrolę nad podatną instancją, uruchamiać polecenia systemowe, uzyskać dostęp do danych i sekretów, a także wykorzystać serwer jako punkt wyjścia do dalszej kompromitacji środowiska.

W skrócie

Podatność dotyczy platformy Flowise i została oznaczona jako CVE-2025-59528.
Luka prowadzi do zdalnego wykonania kodu w wyniku niebezpiecznej obsługi danych wejściowych.
Problem został usunięty w wersji 3.0.6 i nowszych.
Wektorem ataku jest komponent CustomMCP.
Do skutecznej eksploatacji wystarcza token API.
Odnotowano aktywne skanowanie i próby wykorzystania podatności.
Skala ekspozycji obejmuje ponad 12 tysięcy publicznie dostępnych instancji.

Kontekst / historia

Podatność została publicznie ujawniona we wrześniu 2025 roku wraz z informacją o jej krytycznym charakterze i dostępnej poprawce. W kwietniu 2026 roku pojawiły się jednak sygnały wskazujące, że zagrożenie nie ma już wyłącznie teoretycznego charakteru, lecz jest aktywnie wykorzystywane przeciwko systemom dostępnym z Internetu.

To nie pierwszy poważny problem bezpieczeństwa związany z Flowise. Wcześniej projekt był już łączony z innymi błędami umożliwiającymi m.in. zdalne wykonywanie poleceń systemowych oraz arbitralne przesyłanie plików. Rosnąca liczba incydentów pokazuje, że platformy do orkiestracji AI stają się pełnoprawnym elementem powierzchni ataku i powinny być chronione na poziomie porównywalnym z klasycznymi aplikacjami biznesowymi.

Analiza techniczna

Źródłem problemu jest węzeł CustomMCP, wykorzystywany do konfiguracji połączeń z zewnętrznym serwerem MCP. Mechanizm obsługi parametru mcpServerConfig dopuszczał wykonanie przekazanego wejścia jako kodu JavaScript bez odpowiedniej walidacji i zabezpieczeń.

Łańcuch ataku był stosunkowo prosty. Aplikacja przyjmowała dane przez endpoint API odpowiedzialny za ładowanie węzła CustomMCP, następnie przetwarzała je przez etap podstawiania zmiennych, a finalnie interpretowała ciąg wejściowy w sposób prowadzący do jego wykonania po stronie serwera.

Największym problemem było użycie mechanizmu dynamicznej ewaluacji danych. W rezultacie spreparowana wartość mogła uruchomić dowolny kod JavaScript w kontekście procesu Node.js. To otwierało drogę do wykonania poleceń systemowych, operacji na plikach, odczytu poufnych danych, a nawet utrwalenia obecności napastnika w systemie.

uruchamianie komend systemowych,
odczyt i modyfikacja plików,
eksfiltracja tokenów, kluczy i sekretów aplikacyjnych,
osadzenie backdoora,
ruch boczny do innych zasobów infrastruktury.

Szczególnie niebezpieczny jest fakt, że luka była osiągalna zdalnie przez interfejs sieciowy, a do jej wykorzystania wystarczał token API. To oznacza, że pojedynczy przejęty lub niewłaściwie chroniony sekret mógł otworzyć drogę do pełnej kompromitacji środowiska.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2025-59528 należy ocenić jako skrajnie wysokie. Maksymalna nota CVSS znajduje tu pełne uzasadnienie, ponieważ udane wykorzystanie luki może naruszyć poufność, integralność i dostępność systemu jednocześnie.

Dla organizacji korzystających z Flowise w środowiskach produkcyjnych zagrożenie wykracza poza sam serwer aplikacyjny. Platforma często integruje się z bazami danych, usługami SaaS, repozytoriami kodu oraz zewnętrznymi interfejsami API modeli AI. W efekcie atak może prowadzić do wycieku danych klientów, kradzieży poświadczeń, modyfikacji logiki agentów oraz eskalacji incydentu na kolejne systemy.

Dodatkowym czynnikiem zwiększającym ryzyko jest duża liczba publicznie wystawionych instancji. Tak szeroka ekspozycja sprzyja zautomatyzowanemu skanowaniu Internetu i masowym kampaniom opportunistycznym, które uderzają przede wszystkim w słabiej zarządzane wdrożenia.

Rekomendacje

Organizacje używające Flowise powinny potraktować tę podatność priorytetowo i wdrożyć działania naprawcze bez zwłoki. Samo zastosowanie poprawki może jednak nie wystarczyć, jeśli instancja była dostępna publicznie przez dłuższy czas.

niezwłocznie zaktualizować Flowise do wersji 3.0.6 lub nowszej,
ograniczyć dostęp do instancji do sieci wewnętrznych, VPN lub zaufanych adresów IP,
przeprowadzić rotację tokenów API oraz wszystkich sekretów przechowywanych w środowisku,
przeanalizować logi HTTP, logi aplikacyjne i zdarzenia systemowe pod kątem aktywności związanej z CustomMCP,
zweryfikować hosty pod kątem nietypowych procesów, zadań harmonogramu, plików tymczasowych i zmian konfiguracyjnych,
wdrożyć segmentację sieci oraz zasadę najmniejszych uprawnień dla procesu aplikacyjnego,
monitorować połączenia wychodzące z serwera, zwłaszcza do nieznanych adresów i usług chmurowych,
objąć Flowise pełnym procesem zarządzania podatnościami i ciągłym monitoringiem bezpieczeństwa.

Z perspektywy operacyjnej warto założyć, że każda publicznie dostępna i niezałatana instancja mogła zostać naruszona. W takim scenariuszu właściwą reakcją powinien być pełny incident response, a nie wyłącznie aktualizacja oprogramowania.

Podsumowanie

CVE-2025-59528 to jeden z najbardziej niebezpiecznych przykładów luki w ekosystemie narzędzi AI, gdzie błąd w obsłudze dynamicznej konfiguracji prowadzi bezpośrednio do zdalnego wykonania kodu. Aktywna eksploatacja oraz tysiące publicznie dostępnych instancji znacząco zwiększają prawdopodobieństwo incydentów.

Dla zespołów bezpieczeństwa priorytetem powinny być szybkie aktualizacje, ograniczenie ekspozycji usług, rotacja sekretów oraz weryfikacja, czy środowisko nie zostało już skompromitowane. Flowise, podobnie jak inne platformy AI, powinno być traktowane jako system wysokiego ryzyka wymagający dojrzałych procesów bezpieczeństwa.

Źródła

FBI: Amerykanie stracili rekordowe 21 mld dolarów na cyberprzestępczości

Wprowadzenie do problemu / definicja

Cyberprzestępczość pozostaje jednym z najpoważniejszych zagrożeń dla osób prywatnych, firm i instytucji publicznych. Najnowsze dane pokazują, że skala strat finansowych związanych z przestępstwami realizowanymi z użyciem internetu oraz usług cyfrowych nadal dynamicznie rośnie. Problem nie dotyczy już wyłącznie klasycznego phishingu czy ransomware, ale coraz częściej obejmuje oszustwa inwestycyjne, przejęcia komunikacji biznesowej, wycieki danych oraz nadużycia wykorzystujące sztuczną inteligencję.

W skrócie

W 2025 roku ofiary w Stanach Zjednoczonych zgłosiły niemal 21 mld dolarów strat związanych z cyberprzestępczością, co oznacza wzrost o 26% rok do roku. Liczba zgłoszeń do Internet Crime Complaint Center przekroczyła 1 milion. Najczęściej raportowanymi kategoriami incydentów były phishing, wymuszenia oraz oszustwa inwestycyjne, przy czym największe straty finansowe wygenerowały oszustwa związane z inwestycjami i kryptowalutami.

Straty przekroczyły 21 mld dolarów
Wzrost rok do roku wyniósł 26%
Liczba zgłoszeń przekroczyła 1 milion
Szczególnie narażone były osoby powyżej 60. roku życia
W raportach wyraźnie zaznaczono wzrost oszustw wspieranych przez AI

Kontekst / historia

Od kilku lat obserwowany jest systematyczny wzrost zarówno liczby zgłoszeń, jak i łącznej wartości strat przypisywanych cyberprzestępczości. Trend ten pokazuje, że ekosystem przestępczy dojrzewa operacyjnie i staje się coraz bardziej skuteczny w monetyzacji ataków. W poprzednim okresie raportowym straty przekroczyły 16 mld dolarów, a już rok później osiągnęły poziom bliski 21 mld.

Istotna zmiana polega również na przesunięciu ciężaru z incydentów typowo technicznych na operacje socjotechniczne wspierane technologią. Atakujący coraz rzadziej muszą przełamywać zaawansowane zabezpieczenia, jeśli mogą skutecznie zmanipulować ofiarę, podszyć się pod zaufany podmiot lub przejąć proces biznesowy. Z tego powodu w statystykach wysokie pozycje zajmują business email compromise, oszustwa inwestycyjne, fałszywe wsparcie techniczne oraz przestępstwa związane z kryptowalutami.

Na tle historycznym szczególnie istotne jest także formalne uwzględnienie incydentów związanych ze sztuczną inteligencją. To sygnał, że AI przestała być wyłącznie narzędziem eksperymentalnym, a stała się elementem realnych kampanii oszustw i nadużyć.

Analiza techniczna

Z technicznego punktu widzenia omawiane straty nie wynikają z jednego typu podatności, lecz z połączenia kilku klas zagrożeń. Najczęściej obserwowany mechanizm obejmuje socjotechnikę, podszywanie się pod legalne podmioty oraz wykorzystanie infrastruktury cyfrowej do zwiększenia wiarygodności ataku.

Phishing pozostaje podstawowym wektorem wejścia. Atakujący wykorzystują wiadomości e-mail, SMS, połączenia głosowe i komunikatory, aby nakłonić ofiarę do ujawnienia danych logowania, wykonania przelewu lub instalacji złośliwego oprogramowania. W przypadku business email compromise kluczowe znaczenie ma przejęcie lub skuteczne podszycie się pod skrzynkę pocztową pracownika, partnera handlowego albo członka kadry kierowniczej. Technicznie może to obejmować kradzież sesji, wyłudzenie poświadczeń, obejście MFA za pomocą proxy phishingowych lub wykorzystanie wcześniej ujawnionych danych dostępowych.

Wysokie straty generują także oszustwa inwestycyjne, szczególnie te związane z aktywami kryptograficznymi. Schemat ataku zwykle łączy wieloetapową manipulację psychologiczną z fałszywymi platformami inwestycyjnymi, kontrolowanymi portfelami oraz nieodwracalnym transferem środków. Po stronie technicznej przestępcy korzystają z profesjonalnie przygotowanych paneli, reklam, fałszywych dashboardów zysków oraz rozproszonej infrastruktury utrudniającej śledzenie przepływu środków.

Nowym i szybko rosnącym elementem są oszustwa wspierane przez AI. Klonowanie głosu umożliwia przeprowadzenie wiarygodnych połączeń podszywających się pod członków rodziny, przełożonych lub przedstawicieli instytucji. Deepfake wideo i generowane maszynowo dokumenty zwiększają skuteczność weryfikacji tożsamości po stronie ofiary. W praktyce oznacza to obniżenie kosztu przygotowania ataku oraz skalowanie kampanii, które wcześniej wymagały większego nakładu pracy.

W danych zwraca uwagę także obecność incydentów dotyczących naruszeń danych, ransomware i ataków na infrastrukturę krytyczną. Choć liczbowo nie zawsze dominują, mają istotny ciężar operacyjny, ponieważ prowadzą do przerw w działalności, kosztów obsługi incydentu, obowiązków regulacyjnych i ryzyka wtórnych nadużyć związanych z ujawnionymi danymi.

Konsekwencje / ryzyko

Najbardziej oczywistą konsekwencją są bezpośrednie straty finansowe, jednak ryzyko jest znacznie szersze. Dla użytkowników indywidualnych oznacza ono utratę oszczędności, przejęcie tożsamości, utrudniony dostęp do usług finansowych oraz długofalowe skutki prawne i psychologiczne. Szczególnie narażone są osoby starsze, które częściej stają się celem kampanii bazujących na presji czasu, zaufaniu do autorytetów i fałszywej pomocy technicznej.

W środowisku przedsiębiorstw cyberprzestępczość przekłada się na ryzyko operacyjne i strategiczne. Business email compromise może prowadzić do nieautoryzowanych przelewów, naruszenia łańcucha dostaw i eskalacji do kompromitacji kolejnych systemów. Naruszenia danych zwiększają prawdopodobieństwo sankcji regulacyjnych, roszczeń kontraktowych oraz kosztów obsługi incydentu. Dodatkowo wykorzystanie AI przez przestępców utrudnia tradycyjne procedury weryfikacyjne, ponieważ głos, obraz i treść wiadomości przestają być wystarczającym dowodem autentyczności.

Z perspektywy państwa i sektorów krytycznych rośnie ryzyko zakłóceń usług, utraty poufnych informacji i nadużyć wobec podmiotów o wysokim znaczeniu społecznym. Sektory takie jak ochrona zdrowia, produkcja, finanse, IT i administracja pozostają atrakcyjnym celem ze względu na dużą wartość danych oraz niski margines tolerancji na przestoje.

Rekomendacje

Organizacje powinny traktować oszustwa cyfrowe jako zagrożenie łączące cyberbezpieczeństwo, finanse i zarządzanie ryzykiem. W praktyce oznacza to konieczność wdrożenia wielowarstwowej ochrony.

Wzmocnienie ochrony poczty i tożsamości, w tym phishing-resistant MFA, monitoringu logowań oraz mechanizmów SPF, DKIM i DMARC
Wdrożenie niezależnych ścieżek weryfikacji dla przelewów, zmian rachunków i pilnych dyspozycji finansowych
Rozszerzenie szkoleń o scenariusze wykorzystujące klonowanie głosu, deepfake i fałszywe dokumenty
Zacieśnienie współpracy między zespołami SOC, fraud prevention, finansami i działem prawnym
Rozwijanie zdolności do szybkiego zgłaszania incydentów i zabezpieczania materiału dowodowego

Kluczowe znaczenie ma również założenie, że współczesne oszustwa nie muszą zawierać oczywistych błędów językowych ani technicznych. Ataki są coraz bardziej wiarygodne, wielokanałowe i dopasowane do ofiary, dlatego skuteczna obrona wymaga zarówno kontroli technicznych, jak i silnych procedur biznesowych.

Podsumowanie

Rekordowe 21 mld dolarów strat pokazuje, że cyberprzestępczość przeszła z etapu punktowych incydentów do skali przemysłowej. Dominują kampanie oparte na socjotechnice, oszustwach inwestycyjnych, przejęciach komunikacji oraz wykorzystaniu kryptowalut i AI. Dla obrońców oznacza to konieczność odejścia od wąskiego postrzegania cyberzagrożeń jako problemu wyłącznie technicznego. Skuteczna obrona wymaga połączenia kontroli bezpieczeństwa, procedur biznesowych, szybkiego reagowania i ciągłej edukacji użytkowników.

Źródła

https://www.bleepingcomputer.com/news/security/fbi-americans-lost-a-record-21-billion-to-cybercrime-last-year/
https://www.fbi.gov/news/press-releases/fbi-releases-annual-internet-crime-report

Rosnąca ekspozycja bezpieczeństwa w sieciach bezprzewodowych przedsiębiorstw

Wprowadzenie do problemu / definicja

Sieci bezprzewodowe w przedsiębiorstwach przestały być jedynie wygodnym kanałem dostępu do internetu dla laptopów i smartfonów. Obecnie stanowią fundament działania aplikacji biznesowych, urządzeń IoT i OT, systemów czasu rzeczywistego oraz środowisk wspierających analizę danych i procesy oparte na AI. Wraz ze wzrostem znaczenia infrastruktury Wi‑Fi rośnie także jej powierzchnia ataku oraz skala potencjalnych skutków incydentów bezpieczeństwa.

W praktyce oznacza to, że naruszenie bezpieczeństwa sieci bezprzewodowej może dziś wpływać nie tylko na poufność danych, ale również na ciągłość działania, produktywność zespołów, zgodność regulacyjną oraz stabilność procesów operacyjnych.

W skrócie

Najnowsze dane rynkowe pokazują, że incydenty bezpieczeństwa związane z sieciami bezprzewodowymi są powszechne w dużych organizacjach. Znaczna część przedsiębiorstw odnotowała co najmniej jeden taki incydent w ciągu ostatnich 12 miesięcy, a ponad połowa badanych wskazała na bezpośrednie straty finansowe.

Incydenty w sieciach bezprzewodowych stają się codziennym problemem operacyjnym.
W części organizacji koszty incydentów przekroczyły 1 mln USD rocznie.
Rosną obawy dotyczące przejęć urządzeń IoT i OT oraz nieautoryzowanego dostępu do systemów wewnętrznych.
Złożoność środowisk, niedobór specjalistów i presja związana z AI zwiększają ryzyko oraz utrudniają skuteczną reakcję.

Kontekst / historia

W ostatnich latach architektura sieci przedsiębiorstw wyraźnie się zmieniła. Coraz więcej użytkowników, urządzeń i usług działa poza klasycznym modelem przewodowym, a sieć Wi‑Fi obsługuje nie tylko pracę biurową, ale również logistykę, produkcję, telemetrię, komunikację maszynową i usługi lokalizacyjne. W efekcie warstwa bezprzewodowa stała się elementem krytycznym biznesowo.

Z danych przywoływanych w raporcie Cisco State of Wireless 2026 wynika, że organizacje zwiększały inwestycje w obszarze sieci bezprzewodowych przez ostatnie pięć lat i planują dalszy wzrost wydatków. Badanie objęło 6098 decydentów i specjalistów technicznych z organizacji zatrudniających co najmniej 250 pracowników w 30 krajach. Jednocześnie rozwój skali wdrożeń nie zawsze był równoważony wzrostem kompetencji, widoczności operacyjnej i poziomu automatyzacji.

Analiza techniczna

Problem bezpieczeństwa w sieciach bezprzewodowych nie wynika z jednej podatności ani pojedynczego scenariusza ataku. To raczej efekt kumulacji ryzyk związanych z heterogenicznością środowiska, rosnącą liczbą urządzeń i niedostateczną segmentacją.

Współczesna infrastruktura Wi‑Fi obsługuje wiele klas urządzeń: stacje robocze, smartfony, sensory IoT, terminale przemysłowe, kamery, skanery magazynowe, a także komponenty OT. Każda z tych grup ma inny profil ryzyka, odmienny cykl aktualizacji i różny poziom wsparcia dla nowoczesnych mechanizmów ochrony. W rezultacie firmy często utrzymują środowiska mieszane, w których nowoczesne urządzenia współistnieją z komponentami legacy.

Istotnym scenariuszem pozostaje nadużycie poświadczeń bezprzewodowych oraz obecność nieautoryzowanych punktów dostępowych. Takie sytuacje mogą otwierać drogę do nieuprawnionego dostępu do segmentów wewnętrznych, omijania klasycznych mechanizmów ochrony brzegowej oraz lateral movement w sieci kampusowej. Jeśli organizacja nie posiada odpowiedniej segmentacji, kontroli tożsamości urządzeń i monitoringu warstwy radiowej, sieć bezprzewodowa może stać się dogodnym punktem wejścia do systemów krytycznych.

Dodatkowe ryzyko dotyczy urządzeń IoT i OT powiązanych z incydentami bezprzewodowymi. W środowiskach, w których Wi‑Fi pełni funkcję kanału komunikacyjnego dla procesów operacyjnych, skutki incydentu mogą obejmować przestoje, zakłócenie telemetrii, utratę widoczności procesów oraz wpływ na ciągłość działania.

Na sytuację wpływa również rozwój AI. Z jednej strony organizacje wdrażają automatyzację do optymalizacji sieci, planowania pojemności i przyspieszania obsługi incydentów. Z drugiej strony rośnie ryzyko wykorzystania AI przez atakujących, między innymi do lepiej dopasowanych kampanii phishingowych, szybszej kradzieży poświadczeń oraz identyfikacji słabych punktów w rozbudowanych środowiskach hybrydowych.

Nie bez znaczenia pozostaje także ograniczona obserwowalność. Gdy organizacja nie ma pełnego wglądu w zachowanie klientów, aplikacji i ruchu pakietowego, incydenty są trudniejsze do wykrycia i poprawnej klasyfikacji. To wydłuża czas reakcji i zwiększa obciążenie zespołów IT oraz bezpieczeństwa.

Konsekwencje / ryzyko

Najbardziej bezpośrednią konsekwencją incydentów bezprzewodowych są straty finansowe. Mogą one wynikać z przestojów, działań naprawczych, kosztów usług zewnętrznych, spadku produktywności, odbudowy środowiska czy realizacji obowiązków notyfikacyjnych. W części organizacji skala tych kosztów przekraczała 1 mln USD rocznie.

Kolejnym obszarem ryzyka jest naruszenie integralności środowisk IoT i OT. Jeżeli sieć bezprzewodowa nie jest właściwie odseparowana od systemów operacyjnych i urządzeń specjalistycznych, atakujący może uzyskać dostęp do zasobów, które wcześniej były postrzegane jako bardziej odizolowane.

Nie można też pomijać konsekwencji regulacyjnych i zgodnościowych. Incydent może prowadzić do naruszenia danych, złamania polityk dostępu lub niespełnienia wymagań branżowych. W sektorach regulowanych oznacza to ryzyko kar, dodatkowych audytów i utraty zaufania partnerów biznesowych.

Wreszcie, problem ma także wymiar operacyjny. Zespoły IT coraz częściej działają reaktywnie, koncentrując się na gaszeniu bieżących problemów, zamiast rozwijać segmentację, hardening, automatyzację i nowoczesne polityki dostępu. Niedobór specjalistów tylko pogłębia ten stan.

Rekomendacje

Bezpieczeństwo sieci bezprzewodowych powinno być traktowane jako integralna część architektury cyberbezpieczeństwa przedsiębiorstwa. Oznacza to potrzebę połączenia polityk dostępu, monitoringu, segmentacji i zarządzania tożsamością w jeden spójny model operacyjny.

Wdrożenie silnej kontroli dostępu opartej na tożsamości użytkownika i urządzenia.
Segmentacja sieci dla pracowników, gości, urządzeń IoT, OT i stref o podwyższonym ryzyku.
Ciągła detekcja nieautoryzowanych punktów dostępowych, anomalii radiowych i nietypowego użycia poświadczeń.
Integracja monitoringu Wi‑Fi z ekosystemem SOC, SIEM i XDR.
Regularna inwentaryzacja urządzeń oraz ograniczanie ekspozycji systemów IoT i OT.
Izolowanie lub wycofywanie komponentów niewspierających współczesnych standardów ochrony.
Wykorzystanie automatyzacji do korelacji zdarzeń, klasyfikacji incydentów i wsparcia troubleshootingu.
Inwestowanie w kompetencje łączące wiedzę z zakresu sieci radiowych, bezpieczeństwa, automatyzacji i AI.

Podsumowanie

Rosnąca rola sieci bezprzewodowych w przedsiębiorstwach sprawia, że ich bezpieczeństwo staje się jednym z kluczowych tematów strategicznych i operacyjnych. Wzrost liczby urządzeń, zależność procesów biznesowych od Wi‑Fi, ekspansja środowisk IoT i OT oraz rozwój AI powodują, że nawet pojedynczy incydent może mieć szerokie konsekwencje dla całej organizacji.

Największym wyzwaniem nie jest już wyłącznie sama technologia, lecz połączenie złożoności środowiska, braków kompetencyjnych, ograniczonej widoczności i presji na szybkie działanie. Firmy, które potraktują warstwę bezprzewodową jako pełnoprawny obszar cyberbezpieczeństwa, będą lepiej przygotowane do ograniczania ryzyka i utrzymania ciągłości działania.

Źródła

Atak na łańcuch dostaw GitHub z użyciem AI: kampania „prt-scan” wykorzystuje błędną konfigurację GitHub Actions

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania coraz częściej koncentrują się nie tylko na samym kodzie, ale również na procesach CI/CD. Najnowsza kampania oznaczona jako „prt-scan” pokazuje, że błędna konfiguracja GitHub Actions może stać się bezpośrednim wektorem kompromitacji repozytorium, sekretów oraz procesu publikacji pakietów.

Kluczowym elementem nadużycia jest mechanizm pull_request_target, który przy niewłaściwej implementacji może uruchamiać workflow w kontekście głównego repozytorium także dla niezaufanych pull requestów z forków. W praktyce oznacza to ryzyko kradzieży tokenów, enumeracji sekretów i prób przejęcia dalszych etapów pipeline’u.

W skrócie

Kampania „prt-scan” była zautomatyzowaną operacją wymierzoną w projekty korzystające z podatnych workflow opartych o pull_request_target. Atakujący mieli utworzyć ponad 500 złośliwych pull requestów, wykorzystując wiele kont powiązanych z jednym operatorem oraz techniki automatyzacji wspierane przez AI.

Celem były repozytoria GitHub z niebezpieczną konfiguracją Actions.
Ładunki były dopasowywane do stosu technologicznego ofiary.
Potwierdzono kompromitację co najmniej dwóch pakietów npm.
W części incydentów doszło do wycieku krótkotrwałych poświadczeń i innych sekretów CI/CD.

Kontekst / historia

Zagrożenia wobec platform developerskich i narzędzi automatyzacji budowania rosną od kilku lat, jednak kampania „prt-scan” pokazała nowy poziom skali i personalizacji ataku. W centrum problemu znalazł się trigger pull_request_target, od dawna uznawany za funkcję wymagającą szczególnej ostrożności, ponieważ działa w kontekście repozytorium bazowego i może mieć dostęp do sekretów oraz szerszych uprawnień niż standardowy pull_request.

Według ustaleń badaczy aktywność związana z kampanią rozpoczęła się 11 marca 2026 roku i trwała falami do 2–3 kwietnia 2026 roku. Publiczne ujawnienie nastąpiło 2 kwietnia 2026 roku, choć późniejsze analizy wskazały wcześniejsze testy, kolejne iteracje technik i stopniowe zwiększanie skali operacji.

To istotny sygnał dla całego ekosystemu open source. Atak nie był pojedynczym eksperymentem, lecz częścią szerszego trendu, w którym przestępcy zaczynają systematycznie eksploatować błędy konfiguracyjne w GitHub Actions jako drogę do naruszenia software supply chain.

Analiza techniczna

Schemat działania był stosunkowo prosty, ale efektywny przy dużej liczbie prób. Operator wyszukiwał repozytoria wykorzystujące pull_request_target, forkując je i tworząc gałęzie o charakterystycznym nazewnictwie. Następnie przygotowywał pull requesty zawierające złośliwe modyfikacje w plikach, które miały wysoką szansę uruchomienia podczas CI.

Wśród wykorzystywanych plików pojawiały się między innymi conftest.py, package.json, Makefile, build.rs oraz elementy konfiguracji workflow. Zmiany były maskowane jako rutynowe poprawki związane z budowaniem, testami lub kompatybilnością projektu, co miało zmniejszyć czujność maintainerów.

Po uruchomieniu workflow złośliwy kod próbował najpierw zebrać zmienne środowiskowe i tokeny dostępne w kontekście pipeline’u. Następnie wykonywał rozpoznanie środowiska, obejmujące enumerację sekretów, workflow i potencjalnych integracji zewnętrznych. W kolejnych etapach malware podejmowało próby tworzenia tymczasowych workflow, obchodzenia kontroli bezpieczeństwa oraz opóźnionej eksfiltracji danych, na przykład przez logi lub komentarze do pull requestów.

Najbardziej niepokojącym elementem kampanii było dopasowywanie ładunku do technologii używanej przez ofiarę. Badacze odnotowali wzorce sugerujące użycie AI lub modeli LLM do automatycznego rozpoznawania języka, frameworka i procesu budowania projektu. Dzięki temu atakujący mogli generować pozornie naturalne, „idiomatyczne” zmiany dla repozytoriów Python, Node.js, Rust czy Go.

Jednocześnie sama operacja nie była perfekcyjna technicznie. W części analizowanych prób pojawiały się błędy logiczne, niewłaściwe założenia dotyczące modelu uprawnień GitHub oraz nietrafione wektory wstrzyknięcia. To ograniczyło skuteczność kampanii, ale nie zredukowało ryzyka do zera. Przy setkach zautomatyzowanych prób nawet niski odsetek powodzenia może prowadzić do realnych kompromitacji.

Konsekwencje / ryzyko

Najważniejszym skutkiem kampanii jest potwierdzenie, że błędna konfiguracja GitHub Actions może stać się praktycznym punktem wejścia do ataku na łańcuch dostaw. Nawet jeśli część udanych kompromitacji dotyczyła mniejszych projektów, skutki mogą rozlać się dalej przez zależności open source wykorzystywane w innych środowiskach.

Ryzyko ma kilka warstw. Po pierwsze, istnieje możliwość przejęcia krótkotrwałych poświadczeń workflow, które w określonych warunkach pozwalają na dalsze działania w repozytorium lub usługach zewnętrznych. Po drugie, zagrożone są sekrety CI/CD, takie jak tokeny publikacyjne, klucze API, poświadczenia do usług chmurowych czy tokeny wykorzystywane przez platformy wdrożeniowe. Po trzecie, kampanie tego typu zwiększają obciążenie maintainerów i utrudniają ręczną weryfikację pull requestów przy dużej skali ataku.

Dodatkowym problemem jest operacyjne wykorzystanie AI. Automatyzacja obniża próg wejścia dla mniej zaawansowanych aktorów, a jednocześnie zwiększa tempo i adaptacyjność ataków. To oznacza, że podobne kampanie prawdopodobnie będą się powtarzać, stając się z czasem bardziej precyzyjne i trudniejsze do wykrycia.

Rekomendacje

Organizacje utrzymujące repozytoria na GitHub powinny w pierwszej kolejności przeprowadzić audyt workflow korzystających z pull_request_target. Jeżeli ten mechanizm nie jest absolutnie niezbędny, należy zastąpić go bezpieczniejszymi wzorcami opartymi o pull_request lub ograniczyć jego użycie do ściśle kontrolowanych scenariuszy.

Kluczowe pozostaje wdrożenie zasady minimalnych uprawnień dla GITHUB_TOKEN oraz jawne definiowanie sekcji permissions w workflow. Nie należy dopuszczać do automatycznego wykonywania kodu z niezaufanych forków przy jednoczesnym dostępie do sekretów.

Wymuszanie ręcznego zatwierdzania workflow od first-time contributorów.
Ochrona branchy i obowiązkowe review przed uruchomieniem krytycznych zadań.
Stosowanie warunków ścieżkowych ograniczających aktywację workflow.
Separacja sekretów produkcyjnych od pipeline’ów build/test.
Monitorowanie logów workflow pod kątem anomalii i markerów eksfiltracji.
Regularna rotacja tokenów publikacyjnych oraz sekretów CI/CD.
Przegląd historii pull requestów i workflow pod kątem artefaktów kampanii.

Z perspektywy zespołów bezpieczeństwa szczególnie ważne jest wykrywanie repozytoriów, w których pull_request_target współistnieje z wykonywaniem kodu pochodzącego z forka. Taka kombinacja powinna być traktowana jako sygnał wysokiego ryzyka wymagający natychmiastowej korekty.

Podsumowanie

Kampania „prt-scan” pokazuje, że bezpieczeństwo GitHub Actions i pipeline’ów CI/CD stało się jednym z kluczowych elementów ochrony łańcucha dostaw oprogramowania. Sam wektor ataku nie jest nowy, ale połączenie go z automatyzacją wspieraną przez AI znacząco zwiększa skalę, szybkość i elastyczność działań przeciwnika.

Dla organizacji najważniejszy wniosek jest prosty: ochrona software supply chain nie kończy się na analizie kodu aplikacji. Równie istotne są konfiguracje workflow, model uprawnień, sposób uruchamiania zadań dla niezaufanych kontrybutorów oraz kontrola sekretów wykorzystywanych w procesie budowania i publikacji.

Źródła

Dark Reading — AI-Assisted Supply Chain Attack Targets GitHub — https://www.darkreading.com/application-security/ai-assisted-supply-chain-attack-targets-github
Wiz Blog — Six Accounts, One Actor: Inside the prt-scan Supply Chain Campaign — https://www.wiz.io/blog/six-accounts-one-actor-inside-the-prt-scan-supply-chain-campaign
GitHub Docs — About pull requests — https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
GitHub Docs — Events that trigger workflows — https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
Wiz Blog — Hardening GitHub Actions: Lessons from Recent Attacks — https://www.wiz.io/blog/github-actions-security-guide

OWASP aktualizuje wytyczne bezpieczeństwa GenAI i przedstawia nową matrycę narzędzi dla systemów agentowych

Wprowadzenie do problemu / definicja

OWASP zaktualizował projekt poświęcony bezpieczeństwu generatywnej sztucznej inteligencji, odpowiadając na rosnącą skalę wdrożeń modeli LLM, aplikacji GenAI oraz środowisk agentowych. Najważniejsza zmiana polega na wyraźnym rozdzieleniu zagadnień bezpieczeństwa klasycznych systemów GenAI i LLM od ryzyk właściwych dla agentic AI, czyli architektur, w których modele nie tylko generują odpowiedzi, ale również wykonują działania, korzystają z narzędzi i współpracują z innymi agentami.

To istotna zmiana perspektywy, ponieważ współczesne wdrożenia AI coraz częściej wykraczają poza prosty interfejs konwersacyjny. W praktyce oznacza to konieczność budowy nowych mechanizmów kontroli, obserwowalności i governance, które uwzględniają zarówno warstwę modeli, jak i rzeczywiste operacje wykonywane przez AI w systemach organizacji.

W skrócie

OWASP opublikował zaktualizowany krajobraz bezpieczeństwa AI z osobnymi ścieżkami dla GenAI/LLM oraz agentic AI.
Projekt identyfikuje 21 ryzyk związanych z generatywną AI oraz dodatkowe 21 zagrożeń dotyczących bezpieczeństwa danych w środowiskach AI.
Nowa matryca narzędzi mapuje rozwiązania komercyjne i open source do etapów cyklu życia AI na styku DevOps i SecOps.
Liczba monitorowanych dostawców i narzędzi wzrosła z około 50 do ponad 170, co pokazuje tempo rozwoju rynku bezpieczeństwa AI.

Kontekst / historia

Projekt OWASP dotyczący bezpieczeństwa GenAI wyrósł z wcześniejszych prac nad najważniejszymi ryzykami dla aplikacji opartych o duże modele językowe. Początkowo uwaga rynku koncentrowała się przede wszystkim na prompt injection, halucynacjach modeli, ujawnianiu danych oraz podstawowych błędach integracyjnych. Wraz z dojrzewaniem adopcji AI ten zakres okazał się jednak zbyt wąski.

Organizacje zaczęły wdrażać systemy, w których modele uzyskują dostęp do zewnętrznych źródeł danych, repozytoriów wiedzy, aplikacji SaaS, narzędzi automatyzacyjnych czy środowisk produkcyjnych. Taka ewolucja doprowadziła do wzrostu znaczenia zagadnień związanych z kontrolą działań agentów, bezpieczeństwem danych, obserwowalnością procesów oraz zgodnością z politykami organizacyjnymi.

OWASP sygnalizuje również przejście projektu na bardziej regularny, półroczny rytm publikacji. To sugeruje dojrzewanie obszaru bezpieczeństwa AI, choć tempo zmian technologicznych i liczba nowych klas ryzyk nadal pozostają bardzo wysokie.

Analiza techniczna

Najważniejszym elementem aktualizacji jest podział krajobrazu bezpieczeństwa na dwa główne obszary. Pierwszy obejmuje LLM i aplikacje GenAI, gdzie dominują zagrożenia takie jak prompt injection, niekontrolowane ujawnianie danych, niebezpieczne odpowiedzi modelu, słabości w architekturach RAG oraz błędy integracji modeli z procesami biznesowymi. Drugi obszar koncentruje się na agentic AI, czyli systemach zdolnych do wykonywania działań, używania narzędzi i współpracy z innymi komponentami lub agentami.

W środowiskach agentowych pojawiają się dodatkowe klasy zagrożeń. Należą do nich dryf celu, niebezpieczne wykonywanie poleceń przez narzędzia, koluzja między agentami, obchodzenie granic bezpieczeństwa w celu realizacji zadania oraz ryzyka związane z nowymi protokołami integracyjnymi. W praktyce oznacza to zwiększenie powierzchni ataku i potrzebę wdrażania osobnych mechanizmów kontroli dla warstwy wykonawczej.

Duże znaczenie ma także nowa matryca narzędzi, której celem jest uporządkowanie szybko rosnącego rynku rozwiązań ochronnych. Matryca odwzorowuje pełny cykl życia AI — od projektowania i budowy, przez testowanie i wdrożenie, po monitoring, governance i zgodność. To ważne, ponieważ bezpieczeństwo AI nie może ograniczać się jedynie do filtracji promptów. Konieczne stają się również mechanizmy odkrywania aktywności AI, klasyfikacji danych, egzekwowania polityk, walidacji zachowania agentów, testów red teamingowych oraz ciągłej obserwacji interakcji modeli z danymi i narzędziami.

OWASP podkreśla również odrębny wymiar ryzyk związanych z danymi. Obejmują one wyciek danych wrażliwych przez prompty i odpowiedzi modeli, zatruwanie danych treningowych lub pamięci osadzeń, kompromitację wynikającą z użycia zewnętrznych narzędzi i źródeł danych, nieautoryzowane przepływy generowane przez shadow AI oraz ekspozycję tożsamości agentów i używanych przez nie poświadczeń.

Konsekwencje / ryzyko

Dla organizacji oznacza to, że wdrażanie AI bez wyspecjalizowanego modelu bezpieczeństwa może prowadzić do incydentów trudnych do wykrycia i jeszcze trudniejszych do odtworzenia. Systemy GenAI i agentowe są dynamiczne, zależne od kontekstu, danych wejściowych, pamięci operacyjnej oraz zewnętrznych konektorów, co utrudnia klasyczne modelowanie zagrożeń i tradycyjne podejście AppSec.

Najpoważniejsze konsekwencje obejmują utratę poufności danych, nadużycie uprawnień przez agentów, wykonywanie nieautoryzowanych operacji, propagację błędnych decyzji w architekturach wieloagentowych oraz wzrost ryzyka kompromitacji przez zależności zewnętrzne. Dodatkowym wyzwaniem pozostaje skala, ponieważ w dużych organizacjach liczba interakcji AI może rosnąć do tysięcy lub dziesiątek tysięcy wywołań, co znacząco utrudnia ich ewidencję i kontrolę.

Ryzyko staje się szczególnie wysokie tam, gdzie AI jest bezpośrednio połączona z procesami biznesowymi, automatyzacją operacyjną, systemami SaaS, repozytoriami kodu, bazami wiedzy i infrastrukturą produkcyjną. W takich środowiskach nawet pojedynczy błąd logiczny lub skuteczny prompt injection może skutkować nie tylko wyciekiem informacji, ale również realnym wykonaniem działań w systemach organizacji.

Rekomendacje

Podstawowym krokiem powinno być zbudowanie pełnej widoczności użycia AI w środowisku organizacji. Obejmuje to inwentaryzację modeli, agentów, źródeł danych, konektorów, pamięci kontekstowych oraz narzędzi uruchamianych przez agentów. Bez takiej obserwowalności trudno mówić o skutecznej ochronie lub egzekwowaniu polityk bezpieczeństwa.

Konieczne jest również rozdzielenie kontroli bezpieczeństwa dla klasycznych systemów LLM/GenAI i dla agentic AI. Choć obie warstwy są ze sobą powiązane, różnią się sposobem działania oraz profilem ryzyka. W przypadku agentów potrzebne są dodatkowe zabezpieczenia, takie jak sandboxing narzędzi, ograniczanie uprawnień, walidacja celów, kontrola działań wykonawczych oraz monitoring decyzji podejmowanych autonomicznie.

Organizacje powinny także włączyć bezpieczeństwo AI do procesów DevSecOps i SecOps. W praktyce oznacza to testowanie promptów i przepływów agentowych, ocenę ryzyka dla danych wejściowych i wyjściowych, klasyfikację danych wrażliwych, kontrolę użycia zewnętrznych modeli i usług, a także ciągły monitoring zgodności działań AI z polityką organizacyjną.

Warto traktować bezpieczeństwo danych jako osobny filar programu ochrony AI. Ochrona przed wyciekami, poisoningiem, nieautoryzowanymi transferami oraz kompromitacją przez narzędzia stron trzecich powinna być wdrażana równolegle z zabezpieczeniami aplikacyjnymi. Uzupełnieniem tego podejścia powinien być red teaming dla agentów, analiza scenariuszy nadużyć wieloagentowych oraz kontrola łańcucha dostaw komponentów AI.

Podsumowanie

Aktualizacja projektu OWASP pokazuje, że bezpieczeństwo AI wchodzi w nowy etap. Rynek odchodzi od prostego zabezpieczania pojedynczych modeli LLM i przechodzi do ochrony złożonych środowisk agentowych, rozbudowanych przepływów danych i autonomicznych działań wykonywanych przez AI. Nowa matryca narzędzi porządkuje ten obszar, ale jednocześnie potwierdza, że tradycyjne podejście AppSec nie wystarcza.

Dla organizacji kluczowe stają się dziś widoczność, governance, ochrona danych i ścisła kontrola granic działania agentów. To właśnie te elementy będą decydować o tym, czy wdrożenia GenAI i agentic AI staną się bezpiecznym wsparciem biznesu, czy nowym źródłem trudnych do opanowania incydentów.

Źródła

https://www.darkreading.com/application-security/owasp-genai-security-project-update-matrix
https://genai.owasp.org/
https://genai.owasp.org/2026/03/17/owasp-genai-security-project-expands-ai-security-frameworks-ahead-of-rsa-2026-celebrates-continued-sponsor-support/
https://genai.owasp.org/2025/03/26/project-owasp-promotes-genai-security-project-to-flagship-status/