Archiwa: AI - Strona 138 z 183

Anthropic uruchamia Project Glasswing: AI do obrony cybernetycznej pod ścisłą kontrolą

Wprowadzenie do problemu / definicja

Anthropic ogłosił uruchomienie Project Glasswing, inicjatywy łączącej zaawansowany model AI z praktycznymi zastosowaniami w obronie cybernetycznej. Projekt koncentruje się na wzmacnianiu bezpieczeństwa oprogramowania oraz ochronie krytycznej infrastruktury cyfrowej, przy jednoczesnym ograniczeniu ryzyka nadużyć wynikających z ofensywnego wykorzystania tej samej technologii.

To ważny sygnał dla całej branży: modele generatywne są już postrzegane nie tylko jako narzędzie produktywności, ale także jako technologia podwójnego zastosowania. Oznacza to, że mogą przyspieszać zarówno wykrywanie podatności i audyty bezpieczeństwa, jak i automatyzację działań ofensywnych.

W skrócie

Project Glasswing to program wykorzystujący model Claude Mythos Preview do defensywnych zastosowań w cyberbezpieczeństwie.
Anthropic nie udostępnia modelu publicznie, ograniczając dostęp do wybranych partnerów.
Celem projektu jest wspieranie analizy kodu, wykrywania podatności i ochrony krytycznego oprogramowania.
Inicjatywa wpisuje się w trend „defense-first AI”, czyli kontrolowanego wdrażania najmocniejszych modeli najpierw w środowiskach obronnych.

Kontekst / historia

W ostatnich latach narzędzia AI zaczęły odgrywać coraz większą rolę w analizie bezpieczeństwa kodu, triage podatności oraz wspomaganiu procesów secure development. Początkowo były traktowane głównie jako wsparcie dla programistów i zespołów AppSec, jednak ich rosnąca skuteczność szybko ujawniła również potencjał ofensywny.

Project Glasswing jest odpowiedzią na ten nowy etap rozwoju rynku. Zamiast klasycznego modelu publicznej komercjalizacji Anthropic stawia na ograniczoną dystrybucję, nadzorowane testy i współpracę z wybranymi partnerami. To podejście ma zmniejszyć prawdopodobieństwo, że zaawansowane capability AI zostaną użyte do szybszego odkrywania i eksploatacji luk typu zero-day.

Analiza techniczna

Od strony technicznej Glasswing koncentruje się na wykorzystaniu modelu Claude Mythos Preview do zadań związanych z defensywną analizą bezpieczeństwa. Chodzi przede wszystkim o przegląd dużych repozytoriów kodu, identyfikację potencjalnych klas podatności, wsparcie audytów secure coding oraz priorytetyzację ryzyka w krytycznych komponentach oprogramowania.

Kluczowym elementem projektu jest kontrola sposobu użycia modelu. Anthropic ogranicza dostęp do zamkniętego grona organizacji i stawia na monitorowanie wykorzystania, polityki użycia oraz nadzór nad wynikami. Taki model przypomina architekturę gated access, w której najbardziej ryzykowne możliwości nie trafiają do otwartego obiegu, lecz pozostają w środowisku ewaluacyjnym.

Jeśli deklarowana skuteczność przełoży się na praktykę, modele tego typu mogą istotnie skrócić czas od wykrycia podatności do wdrożenia poprawki. To szczególnie ważne w środowiskach, gdzie analiza kodu źródłowego, zależności i łańcucha dostaw wymaga dużej skali działania oraz szybkiej oceny wpływu błędów.

Znaczenie ma również skład partnerów uczestniczących w inicjatywie. Obecność dostawców technologii, bezpieczeństwa i organizacji związanych z utrzymaniem krytycznego oprogramowania sugeruje, że projekt ma nie tylko wartość demonstracyjną, ale także praktyczny wymiar operacyjny dla infrastruktury cyfrowej o wysokim znaczeniu.

Konsekwencje / ryzyko

Najważniejszą konsekwencją Project Glasswing jest potwierdzenie, że zaawansowane modele AI są już traktowane jako element strategiczny w cyberbezpieczeństwie. Po stronie obrony oznacza to szansę na szybsze wykrywanie błędów, lepszą analizę kodu i skuteczniejsze wzmacnianie bezpieczeństwa aplikacji.

Jednocześnie ryzyko pozostaje realne. Te same mechanizmy, które pomagają blue teamom i zespołom AppSec, mogłyby zostać użyte do automatyzacji rekonesansu, identyfikacji słabych punktów i przyspieszenia przygotowania exploitów. To właśnie tłumaczy decyzję o niepublicznym wdrożeniu modelu.

Nie można też pominąć problemu jakości wyników. Nawet bardzo zaawansowany system AI może generować fałszywe alarmy, błędne rekomendacje lub niepełną ocenę kontekstu technicznego. W praktyce oznacza to konieczność utrzymania człowieka w pętli decyzyjnej, szczególnie przy walidacji podatności i planowaniu działań naprawczych dla systemów krytycznych.

Rekomendacje

Dla organizacji obserwujących rozwój podobnych inicjatyw to sygnał, że strategia cyberbezpieczeństwa powinna zostać zaktualizowana pod kątem współpracy z AI. Nie chodzi wyłącznie o wdrożenie nowych narzędzi, ale o zmianę procesów, governance i modelu odpowiedzialności.

Rozszerzyć secure SDLC o procedury współpracy z narzędziami AI, bez pełnej automatyzacji decyzji w krytycznym kodzie.
Wzmocnić bezpieczeństwo łańcucha dostaw oprogramowania, w tym kontrolę zależności, SBOM, podpisywanie artefaktów i pipeline’y CI/CD.
Przygotować SOC, PSIRT i AppSec na skrócenie okna reakcji poprzez lepszy patch management i szybszą walidację podatności.
Wdrożyć silne governance dla narzędzi AI: kontrolę dostępu, rejestrowanie użycia, klasyfikację zadań i przegląd wyników.
Zachować człowieka w pętli wszędzie tam, gdzie wynik modelu może wpływać na decyzje o wysokim ryzyku operacyjnym.

Podsumowanie

Project Glasswing pokazuje, że przyszłość AI w cyberbezpieczeństwie będzie zależeć nie tylko od możliwości modeli, ale również od sposobu ich dystrybucji i kontroli. Anthropic wyraźnie sygnalizuje, że najbardziej zaawansowane capability mogą wymagać ograniczonego dostępu, jeśli ich publiczne udostępnienie zwiększa ryzyko nadużyć.

Dla branży oznacza to jednocześnie szansę i wyzwanie. Z jednej strony AI może znacząco przyspieszyć wykrywanie podatności oraz ochronę krytycznego oprogramowania, z drugiej wymusza dojrzalsze zarządzanie ryzykiem, szybsze procesy reakcji i nowe standardy nadzoru nad wykorzystaniem modeli.

Źródła

Project Glasswing — https://www.anthropic.com/project/glasswing
Project Glasswing: Securing critical software for the AI era — https://www.anthropic.com/glasswing
Anthropic debuts preview of powerful new AI model Mythos in new cybersecurity initiative — https://techcrunch.com/2026/04/07/anthropic-mythos-ai-model-preview-security/
Anthropic is worried hackers could abuse its Claude Mythos AI model – so it’s asking big tech partners to test it behind closed doors — https://www.itpro.com/technology/artificial-intelligence/project-glasswing-anthropic-announces-big-tech-consortium-to-test-claude-mythos-ai-model-that-could-reshape-cybersecurity
Anthropic launches Project Glasswing to secure critical software — https://www.investing.com/news/company-news/anthropic-launches-project-glasswing-to-secure-critical-software-93CH-4601221

Czy akcelerator GPU za 30 tys. dolarów naprawdę przyspiesza łamanie haseł?

Wprowadzenie do problemu / definicja

Rosnąca popularność akceleratorów GPU i układów przeznaczonych do obciążeń AI ponownie wywołała dyskusję o ich przydatności w łamaniu haseł. Z perspektywy bezpieczeństwa organizacji to istotne zagadnienie, ponieważ ataki offline na skróty haseł nadal pozostają jednym z najgroźniejszych scenariuszy po wycieku baz danych, przejęciu kontrolera domeny lub kompromitacji systemów uwierzytelniania.

W praktyce pytanie nie brzmi wyłącznie, czy bardzo drogi sprzęt jest szybki, ale czy jego koszt przekłada się na realną przewagę operacyjną. Najnowsze porównania pokazują, że odpowiedź nie jest oczywista.

W skrócie

Test wydajności trzech układów — Nvidia H200, AMD MI300X oraz konsumenckiego Nvidia RTX 5090 — wskazuje, że najdroższy sprzęt AI nie musi być najlepszym narzędziem do łamania haseł. W badanych benchmarkach Hashcat to właśnie RTX 5090 osiągał najwyższe wyniki dla wszystkich analizowanych algorytmów.

Akcelerator AI za około 30 tys. dolarów nie zapewnił przełomu w crackingu haseł.
Topowy GPU konsumencki okazał się szybszy od rozwiązań klasy enterprise.
Największym problemem pozostają słabe, krótkie i ponownie używane hasła, a nie sam rodzaj sprzętu używanego przez atakującego.

Kontekst / historia

Łamanie haseł od lat opiera się na tej samej zasadzie: im szybciej system potrafi obliczać skróty, tym więcej prób może wykonać w jednostce czasu. Z tego powodu narzędzia takie jak Hashcat są powszechnie używane zarówno przez zespoły red team, jak i specjalistów prowadzących audyty odporności haseł.

Znaczenie ma jednak nie tylko moc obliczeniowa, ale też rodzaj algorytmu. Starsze funkcje skrótu, takie jak MD5 czy NTLM, są bardzo szybkie i przez to znacznie bardziej podatne na brute force oraz ataki słownikowe. Mechanizmy takie jak bcrypt zostały zaprojektowane tak, aby zwiększać koszt obliczeń i utrudniać skuteczne odzyskiwanie haseł po przejęciu hashy.

Historia pokazuje również, że atakujący nie potrzebują egzotycznych platform obliczeniowych, aby osiągać wysoką wydajność. Już kilka lat temu klastry zbudowane z wielu kart konsumenckich zapewniały bardzo wysokie tempo łamania starszych algorytmów, co dziś nadal pozostaje istotnym punktem odniesienia.

Analiza techniczna

W opisywanym teście porównano trzy układy przy użyciu benchmarków Hashcat dla pięciu algorytmów: MD5, NTLM, bcrypt, SHA-256 i SHA-512. Wyniki pokazały, że Nvidia RTX 5090 była najszybsza we wszystkich badanych scenariuszach.

Dla MD5 RTX 5090 osiągnął 219,5 GH/s, podczas gdy AMD MI300X uzyskał 164,1 GH/s, a Nvidia H200 124,4 GH/s. W przypadku NTLM wartości wyniosły odpowiednio 340,1 GH/s dla RTX 5090, 268,5 GH/s dla MI300X oraz 218,2 GH/s dla H200.

Równie interesujące są wyniki dla bcrypt, czyli algorytmu zaprojektowanego z myślą o spowalnianiu ataków offline. Także tutaj akceleratory klasy enterprise nie uzasadniły swojej ceny przewagą nad sprzętem konsumenckim: RTX 5090 osiągnął 375,3 kH/s, H200 304,8 kH/s, a MI300X 142,3 kH/s.

W testach SHA-256 i SHA-512 najlepszy ponownie okazał się RTX 5090 z wynikami odpowiednio 27 681,6 MH/s i 10 014,2 MH/s. To pokazuje, że architektury projektowane głównie pod trening i inferencję modeli AI nie muszą być optymalnym wyborem dla obciążeń charakterystycznych dla crackingu haseł.

Z technicznego punktu widzenia nie jest to szczególnie zaskakujące. Wydajność w Hashcat zależy od konkretnych wzorców obliczeniowych, sposobu wykorzystania pamięci i optymalizacji sterowników, a nie tylko od ogólnej klasy urządzenia. Dlatego topowe karty gamingowe często oferują bardzo korzystny stosunek ceny do wydajności w zadaniach silnie zrównoleglonych.

Warto też spojrzeć na dane historyczne. IBM opisywał już w 2017 roku klaster złożony z ośmiu kart GTX 1080, który osiągał około 334 GH/s dla NTLM. Oznacza to, że pojedynczy współczesny RTX 5090 oferuje dziś poziom wydajności zbliżony do dawnych wielokartowych konfiguracji i porównywalny z bardzo drogimi nowoczesnymi akceleratorami AI w tym konkretnym zastosowaniu.

Konsekwencje / ryzyko

Najważniejszy wniosek dla organizacji jest prosty: zagrożenie nie wynika z pojawienia się egzotycznych akceleratorów AI, lecz z faktu, że skuteczne łamanie słabych haseł od dawna jest możliwe przy użyciu relatywnie dostępnego sprzętu. Jeśli napastnik uzyska dostęp do hashy, krótkie i przewidywalne hasła mogą zostać odzyskane bardzo szybko.

Ryzyko jest szczególnie wysokie w środowiskach korzystających ze starszych algorytmów, słabo chronionych repozytoriów poświadczeń oraz tam, gdzie użytkownicy ponownie wykorzystują te same hasła w wielu systemach. W takiej sytuacji problemem staje się nie tylko cracking offline, ale również credential stuffing i przejmowanie kont na podstawie wcześniej ujawnionych danych logowania.

Błędne jest także założenie, że skuteczny atak wymaga budżetu liczonego w dziesiątkach tysięcy dolarów. Próg wejścia pozostaje znacznie niższy, a to oznacza, że zagrożenie jest dostępne dla dużo szerszej grupy przeciwników niż tylko wyspecjalizowane zespoły dysponujące infrastrukturą klasy enterprise.

Rekomendacje

Organizacje powinny projektować ochronę tożsamości przy założeniu, że przeciwnik dysponuje bardzo wydajnym środowiskiem do testowania hashy. Oznacza to konieczność wzmacniania nie tylko polityki haseł, ale całego modelu uwierzytelniania.

Wymuszaj długie hasła lub passphrase zamiast skupiać się wyłącznie na złożoności znaków.
Ograniczaj użycie słabych algorytmów i regularnie weryfikuj konfigurację systemów uwierzytelniania.
Monitoruj wycieki poświadczeń i blokuj hasła znajdujące się w znanych bazach kompromitacji.
Wdróż MFA dla systemów krytycznych, kont uprzywilejowanych, VPN, RDP i dostępu zdalnego.
Regularnie przeprowadzaj audyty odporności haseł i testy kontrolowanego odzyskiwania skrótów.

Z perspektywy dobrych praktyk warto również przyjąć podejście oparte na ograniczaniu skutków kompromitacji. Nawet jeśli dojdzie do wycieku hashy, odpowiednio dobrane algorytmy, MFA oraz szybka reakcja na ujawnione poświadczenia znacząco zmniejszają ryzyko przejęcia kont.

Podsumowanie

Porównanie wydajności pokazuje, że akcelerator AI kosztujący około 30 tys. dolarów nie stanowi automatycznie najlepszego narzędzia do łamania haseł. W analizowanych testach wyraźnie lepiej wypadł znacznie tańszy RTX 5090, co podważa popularne założenie, że najdroższy sprzęt zawsze daje największą przewagę.

Dla obrońców najważniejszy wniosek pozostaje jednak niezmienny: prawdziwym problemem są słabe i ponownie używane hasła, brak MFA oraz niewystarczająca kontrola nad ekspozycją poświadczeń. To właśnie te czynniki, a nie sam typ GPU, decydują dziś o realnej odporności organizacji na ataki wymierzone w tożsamość.

Źródła

Is a $30,000 GPU Good at Password Cracking? — https://www.bleepingcomputer.com/news/security/is-a-30-000-gpu-good-at-password-cracking/
Hashcat — https://hashcat.net/hashcat/
IBM builds cluster to crack passwords faster — https://www.ibm.com/think/x-force/how-an-eight-gpu-powered-system-gave-us-a-faster-password-cracker
NIST Digital Identity Guidelines — https://pages.nist.gov/800-63-4/
OWASP Authentication Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

FBI: cyberprzestępczość kosztowała Amerykanów rekordowe 21 mld USD w 2025 roku

Wprowadzenie do problemu / definicja

Cyberprzestępczość przestała być wyłącznie problemem technicznym i coraz częściej stanowi bezpośrednie zagrożenie finansowe dla osób prywatnych, firm oraz instytucji. Najnowsze dane FBI pokazują, że w 2025 roku zgłoszone straty wynikające z cyberprzestępstw i oszustw wspieranych cyfrowo sięgnęły niemal 21 mld USD, ustanawiając nowy rekord.

Do tej kategorii zaliczają się nie tylko klasyczne incydenty bezpieczeństwa, takie jak ransomware czy naruszenia danych, ale również phishing, przejęcia kont, oszustwa inwestycyjne, fałszywe wsparcie techniczne oraz kompromitacja komunikacji biznesowej. W praktyce oznacza to, że granica między cyberatakiem a fraudem staje się coraz mniej wyraźna.

W skrócie

W 2025 roku straty zgłoszone do FBI wyniosły blisko 21 mld USD.
Oznacza to wzrost o 26% rok do roku.
Liczba zgłoszeń przekroczyła 1 milion.
Największe szkody powodowały oszustwa inwestycyjne, BEC, fałszywe wsparcie techniczne i naruszenia danych.
Szczególnie wysokie straty odnotowano w grupie osób powyżej 60. roku życia.
FBI wyraźnie wskazało również na rosnącą rolę oszustw wykorzystujących AI, w tym klonowanie głosu i deepfake.

Kontekst / historia

Trend wzrostowy utrzymuje się od kilku lat. W danych za 2024 rok FBI raportowało straty przekraczające 16 mld USD przy ponad 859 tys. zgłoszeń. Już wtedy wśród najczęstszych i najbardziej kosztownych kategorii dominowały phishing, wymuszenia, naruszenia danych oraz oszustwa inwestycyjne, szczególnie powiązane z kryptowalutami.

Publikacja danych za 2025 rok potwierdza dalsze przyspieszenie tego zjawiska. Rosną zarówno liczba incydentów, jak i ich skuteczność finansowa, co wskazuje na coraz bardziej zorganizowany charakter działań przestępczych. Atakujący korzystają dziś z automatyzacji, gotowej infrastruktury przestępczej, kampanii socjotechnicznych prowadzonych na dużą skalę oraz narzędzi AI zwiększających wiarygodność oszustw.

Analiza techniczna

Z perspektywy technicznej rekordowe straty nie wynikają wyłącznie z zaawansowanych włamań, lecz z połączenia technologii, socjotechniki i słabości procesowych. Jednym z najczęściej zgłaszanych wektorów pozostaje phishing, czyli podszywanie się pod zaufane podmioty w celu wyłudzenia danych uwierzytelniających, informacji finansowych lub nakłonienia ofiary do wykonania określonej akcji.

W środowiskach firmowych phishing często pełni rolę punktu wejścia do dalszego przejęcia kont, eskalacji dostępu albo manipulacji procesami płatniczymi. Szczególnie kosztowną kategorią pozostaje Business Email Compromise, w której przestępca przejmuje skrzynkę pocztową lub skutecznie podszywa się pod pracownika, menedżera czy dostawcę. Celem jest zwykle zmiana numeru rachunku, wymuszenie pilnej płatności lub przejęcie obiegu faktur.

Największe straty nadal generują oszustwa inwestycyjne, w tym schematy wykorzystujące kryptowaluty. Ich skuteczność opiera się na długotrwałym budowaniu zaufania, używaniu fałszywych platform inwestycyjnych, spoofingu tożsamości oraz trudności w odzyskaniu przekazanych środków. Cyberprzestępcy wykorzystują fakt, że transakcje cyfrowe są szybkie, międzynarodowe i trudne do odwrócenia.

Istotną zmianą jakościową jest rosnące wykorzystanie AI do wzmacniania oszustw. Klonowanie głosu, deepfake wideo, syntetyczne profile oraz realistycznie generowane dokumenty zwiększają skuteczność podszywania się pod członków rodziny, kadrę zarządzającą, konsultantów technicznych czy przedstawicieli instytucji finansowych. To sprawia, że tradycyjne sygnały ostrzegawcze, takie jak nietypowy ton wiadomości czy nienaturalny język, stają się mniej widoczne.

W raportowanych przypadkach pojawiały się również ransomware, naruszenia danych oraz incydenty dotykające infrastruktury krytycznej. Pokazuje to, że cyberprzestępczość jest dziś szerokim ekosystemem, w którym techniczna kompromitacja systemu bardzo często służy przede wszystkim osiągnięciu zysku finansowego.

Konsekwencje / ryzyko

Bezpośrednim skutkiem takich incydentów są oczywiście straty finansowe, ale skala ryzyka jest znacznie większa. Dla osób prywatnych oznacza to utratę oszczędności, kradzież tożsamości, problemy kredytowe oraz długotrwałe konsekwencje prawne i organizacyjne. Dla przedsiębiorstw dochodzą do tego koszty przestojów, obsługi incydentu, obowiązków regulacyjnych oraz odbudowy reputacji.

Szczególnie niepokojące są dane dotyczące seniorów, którzy należą do grup o najwyższych zgłoszonych stratach. To wskazuje, że obecne mechanizmy edukacyjne i ostrzegawcze nie są wystarczająco skuteczne wobec osób bardziej podatnych na manipulację lub mniej oswojonych z metodami działania nowoczesnych oszustów.

Na poziomie organizacyjnym rośnie również ryzyko błędnej oceny autentyczności komunikacji. Jeśli głos, obraz lub wiadomość mogą zostać wiarygodnie podrobione, samo zaufanie do znanego kanału kontaktu nie może już być traktowane jako wystarczający mechanizm bezpieczeństwa.

Rekomendacje

Organizacje powinny przyjąć wielowarstwowe podejście do ochrony przed cyberoszustwami i przejęciem tożsamości. Podstawą pozostaje silne uwierzytelnianie wieloskładnikowe dla poczty elektronicznej, systemów chmurowych, narzędzi finansowych i dostępu zdalnego. Ogranicza to skutki kradzieży haseł oraz prostych przejęć kont.

Równie ważne są formalne procedury weryfikacji płatności i zmian danych kontrahenta. Każda prośba o pilny przelew, zmianę rachunku lub przekazanie wrażliwych danych powinna być potwierdzana poza pierwotnym kanałem komunikacji, najlepiej przez niezależny kontakt zwrotny.

W praktyce warto wdrożyć:

monitoring anomalii logowania i aktywności kont pocztowych,
kontrolę reguł automatycznego przekazywania wiadomości,
detekcję nietypowych zmian uprawnień i delegacji,
aktualne szkolenia security awareness obejmujące scenariusze AI-assisted fraud,
wspólne playbooki reagowania dla zespołów bezpieczeństwa, finansów i compliance.

Dla użytkowników indywidualnych najważniejsze pozostają podstawowe zasady ostrożności: nie działać pod presją czasu, nie ufać pojedynczej wiadomości lub rozmowie telefonicznej, weryfikować prośby innym kanałem oraz jak najszybciej zgłaszać incydent do banku i właściwych instytucji.

Podsumowanie

Rekordowe niemal 21 mld USD strat zgłoszonych w 2025 roku pokazuje, że cyberprzestępczość stała się jednym z najpoważniejszych źródeł ryzyka finansowego w gospodarce cyfrowej. Największe zagrożenie nie wynika już wyłącznie z technicznych włamań, lecz z połączenia socjotechniki, przejęcia tożsamości, oszustw inwestycyjnych i coraz skuteczniejszego wykorzystania AI.

Dla firm i użytkowników oznacza to konieczność przejścia od modelu opartego na zaufaniu do modelu ciągłej weryfikacji. Bezpieczne procesy, wieloskładnikowe uwierzytelnianie, kontrola płatności i szybkie reagowanie stają się dziś kluczowymi elementami ograniczania realnych strat.

Źródła

Krytyczna luka RCE w Flowise już wykorzystywana w atakach. Zagrożone są wdrożenia AI dostępne z internetu

Wprowadzenie do problemu / definicja

Flowise, popularna platforma open source do budowy aplikacji opartych na dużych modelach językowych oraz agentach AI, znalazła się w centrum uwagi po ujawnieniu krytycznej podatności zdalnego wykonywania kodu. Luka oznaczona jako CVE-2025-59528 pozwala na wstrzyknięcie i uruchomienie kodu JavaScript bez odpowiedniej walidacji, co może prowadzić do wykonania poleceń systemowych i uzyskania dostępu do systemu plików.

Problem jest szczególnie istotny dla organizacji, które udostępniają instancje Flowise do internetu i wykorzystują tę platformę w środowiskach produkcyjnych, integrując ją z modelami AI, bazami danych, systemami SaaS oraz wewnętrznymi źródłami wiedzy.

W skrócie

CVE-2025-59528 to krytyczna podatność RCE w komponencie CustomMCP platformy Flowise.
Błąd wynika z niebezpiecznej ewaluacji danych wejściowych w parametrze konfiguracyjnym serwera MCP.
Poprawka została udostępniona w wersji Flowise 3.0.6.
W kwietniu 2026 roku odnotowano aktywne próby wykorzystania tej luki w rzeczywistych atakach.
Zagrożone są szczególnie publicznie dostępne i niezałatane instancje wykorzystywane do wdrożeń AI.

Kontekst / historia

Flowise zdobył popularność jako platforma low-code do projektowania przepływów pracy opartych na LLM. Dzięki interfejsowi typu drag-and-drop narzędzie jest wykorzystywane zarówno przez zespoły programistyczne, jak i przez działy biznesowe, operacyjne oraz wsparcia klienta, które chcą szybko tworzyć chatboty, asystentów AI i rozwiązania automatyzujące pracę z dokumentami.

Podatność CVE-2025-59528 została opublikowana w bazie NVD 22 września 2025 roku, natomiast poprawka pojawiła się wcześniej w wydaniu Flowise 3.0.6 z 15 września 2025 roku. Wraz z upublicznieniem szczegółów technicznych ryzyko gwałtownie wzrosło, a w 2026 roku pojawiły się potwierdzenia, że luka jest już aktywnie wykorzystywana przez napastników.

To kolejny przykład sytuacji, w której oprogramowanie open source wdrażane w środowiskach produkcyjnych staje się celem szybkich kampanii skanowania i oportunistycznych ataków tuż po ujawnieniu podatności oraz publikacji dostępnych informacji o wektorze eksploatacji.

Analiza techniczna

Źródłem problemu jest węzeł CustomMCP, używany do konfiguracji połączeń z zewnętrznym serwerem Model Context Protocol. Mechanizm ten przetwarza parametr mcpServerConfig w sposób niebezpieczny, wykonując kod JavaScript bez uprzedniej kontroli bezpieczeństwa. W praktyce prowadzi to do klasycznego scenariusza code injection i umożliwia zdalne wykonanie kodu.

Jeżeli atakujący może dostarczyć odpowiednio spreparowaną konfigurację, jest w stanie uruchomić nieautoryzowany kod w kontekście procesu aplikacji. Skutki zależą od sposobu uruchomienia Flowise, uprawnień procesu, konfiguracji kontenera oraz dostępnych integracji.

wykonanie poleceń w systemie operacyjnym,
odczyt i modyfikacja plików lokalnych,
kradzież sekretów aplikacyjnych i tokenów API,
manipulacja przepływami AI i logiką agentów,
wykorzystanie serwera do dalszego ruchu bocznego w sieci.

To szczególnie niebezpieczne w środowiskach, w których Flowise przechowuje klucze dostępu do modeli, baz wektorowych, usług chmurowych, repozytoriów dokumentów lub systemów firmowych. Udane wykorzystanie RCE może więc oznaczać nie tylko kompromitację samej aplikacji, ale również przejęcie powiązanych usług i danych.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2025-59528 należy traktować jako krytyczne, zwłaszcza gdy Flowise jest dostępny z internetu, działa na nieaktualnej wersji i posiada dostęp do wrażliwych zasobów. Im więcej integracji z systemami zewnętrznymi i wewnętrznymi, tym większy potencjalny zasięg incydentu.

Najpoważniejszym skutkiem może być pełne przejęcie aplikacji. W praktyce oznacza to możliwość utraty poufności danych, naruszenia integralności procesów biznesowych, podmiany logiki automatyzacji, wdrożenia tylnej furtki oraz użycia zainfekowanego hosta do dalszych działań ofensywnych.

Dla organizacji korzystających z Flowise do obsługi klientów, automatyzacji pracy z dokumentami lub orkiestracji agentów AI, skutki mogą obejmować zarówno incydent bezpieczeństwa, jak i poważne zakłócenia operacyjne. Platformy AI powinny być więc traktowane jako pełnoprawny element powierzchni ataku przedsiębiorstwa.

Rekomendacje

Podstawowym działaniem jest natychmiastowa aktualizacja Flowise co najmniej do wersji 3.0.6, a najlepiej do nowszego, wspieranego wydania. Samo wdrożenie poprawki nie powinno jednak kończyć procesu reakcji, ponieważ w części środowisk mogło już dojść do prób kompromitacji.

zweryfikować wszystkie publicznie dostępne instancje Flowise i ustalić ich wersje,
ograniczyć ekspozycję usługi do internetu, jeśli zdalny dostęp nie jest konieczny,
wdrożyć segmentację sieci i dodatkowe kontrole dostępu do paneli administracyjnych,
przeprowadzić rotację kluczy API, tokenów i innych poświadczeń przechowywanych w aplikacji,
przeanalizować logi pod kątem zmian konfiguracji, podejrzanych żądań i nietypowych procesów,
zastosować zasadę najmniejszych uprawnień dla kontenerów, hostów i wolumenów,
wdrożyć reguły detekcyjne dla prób wstrzyknięcia kodu i anomalii w konfiguracjach MCP,
objąć platformy AI regularnym procesem zarządzania podatnościami i monitoringu bezpieczeństwa.

W praktyce organizacje powinny założyć, że środowiska AI przechowują cenne sekrety oraz szerokie integracje. Dlatego po wykryciu podatnej instancji konieczne jest nie tylko patchowanie, ale także ocena potencjalnej kompromitacji i zakresu dostępu, jaki mógł uzyskać napastnik.

Podsumowanie

Aktywna eksploatacja CVE-2025-59528 pokazuje, że platformy do budowy agentów AI stają się atrakcyjnym celem cyberprzestępców. Luka w Flowise umożliwia niebezpieczne wykonanie kodu przez błędną obsługę konfiguracji CustomMCP, a skutki udanego ataku mogą wykraczać daleko poza samą aplikację.

Dla zespołów bezpieczeństwa najważniejsze działania to szybka aktualizacja, ograniczenie ekspozycji do internetu, weryfikacja logów oraz rotacja sekretów. W środowiskach produkcyjnych Flowise powinien być traktowany jak krytyczny komponent infrastruktury aplikacyjnej, a nie jedynie pomocnicze narzędzie dla zespołów rozwijających rozwiązania AI.

Źródła

Max severity Flowise RCE vulnerability now exploited in attacks — https://www.bleepingcomputer.com/news/security/max-severity-flowise-rce-vulnerability-now-exploited-in-attacks/
NVD – CVE-2025-59528 — https://nvd.nist.gov/vuln/detail/CVE-2025-59528
Flowise Releases — https://github.com/FlowiseAI/Flowise/releases
FlowiseAI/Flowise Repository — https://github.com/FlowiseAI/Flowise

React2Shell atakuje aplikacje Next.js. Zautomatyzowana kampania kradnie poświadczenia i sekrety chmurowe

Wprowadzenie do problemu / definicja

React2Shell to krytyczna podatność typu pre-auth RCE związana z mechanizmami React Server Components, która może prowadzić do zdalnego wykonania kodu bez wcześniejszego uwierzytelnienia. W praktyce zagrożenie dotyczy przede wszystkim publicznie dostępnych aplikacji webowych, zwłaszcza opartych na Next.js, gdzie odpowiednio spreparowany ładunek przesłany do endpointu funkcji serwerowej może doprowadzić do przejęcia procesu Node.js.

Najnowsze obserwacje pokazują, że luka nie jest już wyłącznie problemem teoretycznym ani badawczym. Została wykorzystana w zautomatyzowanej kampanii nastawionej na masowe pozyskiwanie poświadczeń, kluczy API, sekretów środowiskowych i danych dostępowych do usług chmurowych.

W skrócie

Atakujący wykorzystują React2Shell do przejmowania publicznie dostępnych aplikacji Next.js i podobnych wdrożeń.
Po kompromitacji uruchamiany jest zautomatyzowany łańcuch zbierania sekretów, kluczy SSH, tokenów chmurowych i artefaktów Kubernetes.
Operacja ma charakter masowy i obejmuje setki hostów w różnych regionach oraz u wielu dostawców chmury.
Wykradzione dane trafiają do panelu operatorskiego, gdzie mogą być dalej analizowane i wykorzystywane w kolejnych etapach ataku.

Kontekst / historia

React2Shell bardzo szybko stał się jednym z ważniejszych tematów bezpieczeństwa w ekosystemie JavaScript, ponieważ łączy nowoczesny model aplikacyjny z wyjątkowo niebezpiecznym skutkiem w postaci zdalnego wykonania kodu jeszcze przed logowaniem użytkownika. To sprawia, że podatność jest szczególnie atrakcyjna dla grup nastawionych na automatyczne skanowanie internetu i szybkie przejmowanie podatnych instancji.

W przypadku aplikacji Next.js problem jest szczególnie istotny ze względu na architekturę opartą na komponentach serwerowych oraz funkcjach wykonywanych po stronie backendu. Każda ekspozycja takiej aplikacji do internetu zwiększa powierzchnię ataku, a dobrze przygotowany exploit może umożliwić nie tylko wejście na host, ale również natychmiastowe rozpoczęcie eksfiltracji danych.

Analizy kampanii wskazują, że atakujący nie koncentrują się na jednej branży, kraju czy typie ofiary. Wzorzec działania sugeruje szerokie, zautomatyzowane poszukiwanie podatnych systemów, po którym następuje niemal w pełni bezobsługowy proces kompromitacji i zbierania informacji.

Analiza techniczna

Techniczny mechanizm nadużycia React2Shell opiera się na przetwarzaniu i deserializacji danych wejściowych kierowanych do endpointów Server Function. Jeśli aplikacja korzysta z podatnej implementacji React Server Components lub frameworka budowanego wokół tego modelu, napastnik może dostarczyć złośliwy serializowany ładunek HTTP. Po jego obsłużeniu dochodzi do arbitralnego wykonania kodu w procesie serwera Node.js.

Po uzyskaniu dostępu uruchamiany jest lekki dropper, którego zadaniem jest pobranie i wykonanie właściwego skryptu kolekcjonującego. Badacze obserwowali użycie katalogu /tmp, losowych ukrytych nazw plików oraz narzędzia nohup, co pozwala utrzymać działanie procesu również po rozłączeniu sesji i utrudnia szybką identyfikację incydentu.

Zbieranie danych przebiega etapowo i obejmuje szerokie spektrum informacji z hosta, procesów oraz środowiska wykonawczego. Atakujący koncentrują się nie tylko na standardowych sekretach aplikacyjnych, ale również na materiałach, które umożliwiają ruch lateralny, eskalację uprawnień oraz przejęcie infrastruktury chmurowej.

zrzut zmiennych środowiskowych procesów,
ekstrakcję informacji o środowisku uruchomieniowym JavaScript,
zbieranie kluczy prywatnych SSH i wpisów authorized_keys,
wyszukiwanie tokenów i sekretów w plikach oraz pamięci procesu,
pobieranie historii poleceń powłoki,
odpytywanie usług metadanych AWS, GCP i Azure,
odczyt tokenów kont serwisowych Kubernetes,
enumerację kontenerów Docker,
listowanie argumentów uruchomionych procesów.

Po każdej fazie dane są przesyłane do infrastruktury dowodzenia i kontroli, gdzie trafiają do panelu operatorskiego określanego jako NEXUS Listener. Taki panel umożliwia przegląd przejętych hostów, podział danych według kategorii oraz ocenę skuteczności kampanii. Szczególnie alarmujący jest fakt, że w analizowanych przypadkach znajdowano tam klucze API platform AI, sekrety systemów płatności, dane dostępowe do AWS i Azure, tokeny GitHub oraz GitLab, ciągi połączeń do baz danych zawierające hasła, a także tokeny botów i webhooków.

Konsekwencje / ryzyko

Skutki takiej kampanii daleko wykraczają poza jednorazowe przejęcie serwera aplikacyjnego. Gdy napastnik uzyskuje dostęp do sekretów środowiskowych, może przejąć konta w usługach zewnętrznych, uzyskać dostęp do repozytoriów kodu, systemów płatności, baz danych czy zasobów chmurowych. W środowiskach public cloud skala zagrożenia zależy od uprawnień przypisanych rolom instancji, ale nawet umiarkowane uprawnienia mogą wystarczyć do dalszej ekspansji.

Szczególne ryzyko wiąże się z kluczami SSH i tokenami Kubernetes. Pierwsze mogą posłużyć do ruchu lateralnego pomiędzy systemami, które ufają tej samej tożsamości kryptograficznej, drugie zaś mogą otworzyć drogę do kontenerów, workloadów i sekretów klastra. W praktyce oznacza to, że incydent zaczynający się od aplikacji webowej może bardzo szybko przerodzić się w naruszenie całego środowiska operacyjnego.

Nie można też pominąć wymiaru supply chain. Jeśli z hostów wykradzione zostaną tokeny do platform deweloperskich, rejestrów pakietów lub systemów CI/CD, atakujący mogą próbować opublikować złośliwe komponenty pod zaufaną tożsamością organizacji albo wykorzystać zdobyte dane do kolejnych kampanii ukierunkowanych.

Rekomendacje

Organizacje korzystające z Next.js i React Server Components powinny potraktować ryzyko związane z React2Shell priorytetowo. Sama poprawka aplikacji może być niewystarczająca, jeśli doszło już do eksfiltracji sekretów. Konieczne jest połączenie działań naprawczych, dochodzeniowych i prewencyjnych.

przeprowadzenie pilnego przeglądu wszystkich publicznie dostępnych aplikacji pod kątem podatnych komponentów i endpointów Server Function,
natychmiastowe wdrożenie poprawek bezpieczeństwa oraz aktualizacji zależności,
pełna rotacja poświadczeń w przypadku nawet częściowego podejrzenia ekspozycji, w tym kluczy API, tokenów chmurowych, haseł baz danych, webhooków i kluczy SSH,
ograniczenie uprawnień ról instancji i usług zgodnie z zasadą najmniejszych uprawnień,
weryfikacja konfiguracji kontenerów i środowisk Kubernetes pod kątem nadmiarowego dostępu do sekretów oraz zbyt szerokich ról RBAC,
segmentacja środowisk i rezygnacja ze współdzielenia kluczy SSH między systemami,
wdrożenie monitoringu wykrywającego procesy uruchamiane z /tmp, użycie nohup, nietypowe połączenia wychodzące HTTP/S i odwołania do usług metadanych,
zastosowanie reguł WAF lub ochrony runtime dopasowanej do wzorców ataków na aplikacje Next.js,
audyt zmiennych środowiskowych oraz ograniczenie liczby sekretów dostępnych dla procesów aplikacyjnych.

Z perspektywy detekcji warto szukać artefaktów takich jak losowo nazwane skrypty w katalogach tymczasowych, niestandardowe zadania wykonywane poza typowym pipeline’em aplikacyjnym, wzmożone odczyty historii poleceń oraz ślady dostępu do tokenów Kubernetes i metadanych instancji chmurowych.

Podsumowanie

Kampania wykorzystująca React2Shell pokazuje, jak szybko nowoczesne podatności w ekosystemie JavaScript mogą zostać przekształcone w przemysłowy model ataku. Celem nie jest wyłącznie przejęcie pojedynczego hosta, lecz zbudowanie zautomatyzowanego łańcucha pozyskiwania sekretów, który otwiera drogę do infrastruktury chmurowej, repozytoriów kodu, systemów płatności i środowisk kontenerowych.

Dla zespołów bezpieczeństwa i administratorów oznacza to konieczność traktowania każdego incydentu związanego z React2Shell jako potencjalnego naruszenia tożsamości, chmury i zaplecza developerskiego jednocześnie. Szybkie łatanie, pełna rotacja sekretów oraz dokładna analiza śladów kompromitacji powinny być absolutnym minimum reakcji.

Źródła

Cybersecurity Dive – React2Shell vulnerability helps hackers steal credentials, AI platform keys and other sensitive data — https://www.cybersecuritydive.com/news/credential-harvesting-campaign-react2shell-cisco/816726/
Cisco Talos – UAT-10608: Inside a large-scale automated credential harvesting operation targeting web applications — https://blog.talosintelligence.com/uat-10608-inside-a-large-scale-automated-credential-harvesting-operation-targeting-web-applications/

Anthropic Claude Mythos Preview automatyzuje wykrywanie i eksploatację podatności zero-day

Wprowadzenie do problemu / definicja

Rozwój modeli językowych coraz mocniej wpływa na cyberbezpieczeństwo, nie tylko w obszarze analizy danych czy automatyzacji pracy zespołów SOC, ale również w praktycznym wyszukiwaniu błędów bezpieczeństwa. Najnowsze informacje dotyczą modelu Claude Mythos Preview, który według opublikowanej oceny technicznej potrafi autonomicznie identyfikować podatności zero-day i przygotowywać działające exploity dla głównych systemów operacyjnych oraz przeglądarek.

To jakościowa zmiana w krajobrazie zagrożeń. Dotychczas największą barierą nie było samo wskazanie podejrzanego fragmentu kodu, lecz przejście od hipotezy do stabilnego, powtarzalnego wykorzystania podatności. Jeśli model AI potrafi wykonać ten etap samodzielnie, organizacje muszą założyć znacznie krótsze okno między odkryciem błędu a jego praktyczną eksploatacją.

W skrócie

Claude Mythos Preview ma wykazywać zdolność do samodzielnego znajdowania i wykorzystywania nieznanych wcześniej podatności w rzeczywistych projektach open source oraz popularnych komponentach systemowych. W testach wewnętrznych model osiągał wyraźnie lepsze rezultaty niż wcześniejsze generacje, także w scenariuszach obejmujących memory corruption, eskalację uprawnień i łańcuchy exploitów dla przeglądarek.

Model ma znajdować podatności wysokiego i krytycznego ryzyka.
W części przypadków wykrycia zostały zweryfikowane przez zewnętrznych specjalistów.
Narzędzie nie zostało udostępnione publicznie i trafia wyłącznie do ograniczonej grupy partnerów.
Największe obawy budzi automatyzacja przejścia od analizy kodu do gotowego exploita.

Kontekst / historia

Automatyczne wykrywanie podatności nie jest nowym zjawiskiem. Branża od lat korzysta z fuzzerów, analizatorów statycznych, technik symbolic execution i narzędzi wspierających badania bezpieczeństwa. Problem polegał jednak na tym, że nawet trafne wykrycie błędu nie zawsze prowadziło do szybkiego przygotowania skutecznego exploita.

Wcześniejsze modele generatywne pomagały przy analizie kodu, triage zgłoszeń czy budowie prostych proof-of-conceptów, lecz ich skuteczność w autonomicznym exploit development była ograniczona. Opis najnowszego wariantu sugeruje jednak znaczący skok możliwości. Oznacza to, że AI zaczyna odgrywać rolę nie tylko asystenta badacza bezpieczeństwa, ale potencjalnie także samodzielnego operatora realizującego kolejne etapy ofensywnego łańcucha działań.

Analiza techniczna

Mechanizm działania modelu opiera się na schemacie agentowym. Claude Mythos Preview pracuje w odizolowanym środowisku z dostępem do kodu źródłowego analizowanego projektu, bada pliki, formułuje hipotezy o możliwych podatnościach, uruchamia program, korzysta z debugerów i dodatkowej instrumentacji, a następnie przygotowuje raport wraz z proof-of-concept. Dzięki temu proces nie kończy się na wykryciu anomalii, lecz obejmuje także iteracyjne potwierdzanie, czy dany błąd rzeczywiście nadaje się do wykorzystania.

Szczególnie istotne są wyniki dotyczące klas błędów związanych z bezpieczeństwem pamięci. W opisywanych testach model miał wielokrotnie tworzyć działające exploity dla podatności związanych z silnikiem JavaScript w przeglądarce Firefox, podczas gdy wcześniejsze generacje osiągały sukcesy jedynie sporadycznie. W benchmarkach opartych o OSS-Fuzz nowy wariant uzyskiwał też więcej przypadków prowadzących do poważnych naruszeń integralności wykonania, w tym do przejęcia przepływu sterowania.

Na uwagę zasługują również przykłady rzeczywistych znalezisk. Wśród nich wskazano wieloletnią podatność denial-of-service w implementacji TCP SACK w OpenBSD oraz zdalną podatność typu remote code execution w serwerze NFS systemu FreeBSD, która miała umożliwiać nieautoryzowane uzyskanie uprawnień roota. Producent opisał też zdolność modelu do wykrywania problemów w aplikacjach webowych, bibliotekach kryptograficznych i środowiskach wirtualizacji.

Z perspektywy obrońców szczególnie alarmujące jest przyspieszenie eksploatacji podatności typu N-day. W testach dotyczących błędów jądra Linuksa z lat 2024–2025 model miał wybierać najbardziej obiecujące przypadki i dla znaczącej części budować skuteczne ścieżki eskalacji uprawnień. Taki scenariusz oznacza, że publiczne ujawnienie podatności może szybciej niż dotąd prowadzić do pojawienia się działających narzędzi atakujących.

Konsekwencje / ryzyko

Najważniejszą konsekwencją jest obniżenie kosztu i progu wejścia dla zaawansowanych działań ofensywnych. Jeśli model potrafi samodzielnie analizować kod, wybierać perspektywiczne wektory ataku, testować hipotezy i budować exploity, to czas między publikacją informacji o błędzie a jego operacyjnym wykorzystaniem może istotnie się skrócić.

Ryzyko dotyczy jednocześnie kilku obszarów. Rosnąca automatyzacja uderzy przede wszystkim w projekty open source, komponenty infrastrukturalne, przeglądarki, biblioteki kryptograficzne i jądra systemowe. Dodatkowo organizacje powinny zakładać wzrost liczby półautomatycznych kampanii, które będą industrializować exploity dla popularnych stosów technologicznych.

Krótsze okno na wdrożenie poprawek po publikacji podatności.
Wyższe ryzyko szybkiej eksploatacji błędów w powszechnie używanych komponentach.
Większa presja na zespoły AppSec, SOC i administrację infrastruktury.
Potencjalny wzrost liczby zgłoszeń i analiz wspieranych przez AI.

W dłuższej perspektywie podobne systemy mogą także działać na korzyść obrońców, jeśli zostaną wykorzystane do masowego wyszukiwania i usuwania błędów jeszcze przed wdrożeniem kodu do produkcji. Największym problemem pozostaje jednak okres przejściowy, w którym zdolności modeli rosną szybciej niż dojrzałość procesów bezpieczeństwa w organizacjach.

Rekomendacje

Organizacje powinny przyjąć założenie, że automatyzacja exploit development stanie się trwałym elementem krajobrazu zagrożeń. W praktyce oznacza to konieczność przyspieszenia patch management, skrócenia czasu reakcji na nowe CVE oraz podniesienia priorytetu aktualizacji dla komponentów sieciowych, jąder systemowych, bibliotek kryptograficznych i przeglądarek.

Warto też równolegle wdrażać modele językowe do procesów defensywnych. AI może wspierać secure code review, triage podatności, analizę zmian w zależnościach, walidację proof-of-conceptów oraz ocenę wpływu błędu na środowisko produkcyjne. Kluczowe jest jednak korzystanie z takich narzędzi w środowiskach kontrolowanych, z odpowiednim audytem, segmentacją i polityką ochrony danych.

Skrócić czas wdrażania poprawek i automatyzować aktualizacje tam, gdzie to możliwe.
Traktować poprawki bezpieczeństwa w zależnościach jako zmiany pilne.
Rozwijać pipeline’y automatycznej detekcji i reakcji na incydenty.
Wzmacniać monitoring prób eksploatacji po publicznym ujawnieniu podatności.
Regularnie przeglądać powierzchnię ataku w komponentach open source.
Aktualizować procedury coordinated vulnerability disclosure z uwzględnieniem zgłoszeń wspieranych przez AI.

Zespoły blue team i AppSec powinny również przygotować scenariusze reagowania na gwałtowną falę exploitów dla podatności typu N-day. To właśnie ten obszar może zostać najszybciej przyspieszony przez nowe narzędzia oparte na modelach językowych.

Podsumowanie

Claude Mythos Preview sygnalizuje ważny punkt zwrotny w cyberbezpieczeństwie. Nie chodzi już wyłącznie o modele wspierające analizę czy dokumentację podatności, ale o systemy zdolne do autonomicznego wykrywania błędów i budowy praktycznych exploitów. Taka zmiana zwiększa presję na organizacje, by skracały czas reakcji, automatyzowały obronę i aktywnie wykorzystywały AI po stronie defensywnej.

W najbliższych latach przewagę zyskają te podmioty, które najszybciej zintegrują nową klasę narzędzi z procesami zarządzania podatnościami, bezpiecznym wytwarzaniem oprogramowania i reagowaniem na incydenty. Jednocześnie branża będzie musiała wypracować nowe standardy odpowiedzialnego wykorzystania modeli zdolnych do prowadzenia zaawansowanych działań ofensywnych.

Źródła

https://www.helpnetsecurity.com/2026/04/08/anthropic-claude-mythos-preview-identify-vulnerabilities/
https://red.anthropic.com/2026/mythos-preview/

GrafanaGhost: nowy wektor wycieku danych przez komponenty AI w Grafanie

Wprowadzenie do problemu / definicja

GrafanaGhost to technika ataku pokazująca, w jaki sposób komponenty AI zintegrowane z Grafaną mogą zostać wykorzystane do nieautoryzowanego ujawnienia danych przedsiębiorstwa. Nie chodzi wyłącznie o klasyczną podatność aplikacyjną, lecz o połączenie pośredniego prompt injection, odwołań do zewnętrznych zasobów oraz błędów w mechanizmach walidacji. W efekcie narzędzie analityczne, które ma szeroki dostęp do danych operacyjnych i biznesowych, może stać się kanałem cichej eksfiltracji informacji.

To istotny przykład nowej klasy ryzyk związanych z wdrażaniem funkcji AI w systemach mających dostęp do wrażliwych danych. W praktyce zagrożenie nie musi objawiać się widocznym błędem ani awarią — może przebiegać w tle, podczas rutynowego korzystania z dashboardów i analiz.

W skrócie

Badacze opisali scenariusz, w którym atakujący przygotowuje złośliwy kontekst dla funkcji AI działających w Grafanie. Odpowiednio skonstruowane dane wejściowe i ukryte instrukcje mogą skłonić model do wykonania żądania do zewnętrznego serwera, a tym samym do wyniesienia danych poza organizację.

atak wykorzystuje komponenty AI analizujące nieufne dane,
kluczową rolę odgrywa prompt injection ukryty w kontekście,
żądanie do zewnętrznego zasobu może służyć do eksfiltracji informacji,
najbardziej narażone są środowiska z szerokim dostępem Grafany do danych i otwartą komunikacją wychodzącą.

Kontekst / historia

Grafana od lat jest jedną z najpopularniejszych platform do wizualizacji i analityki danych. W środowiskach enterprise często łączy metryki, logi, dane infrastrukturalne, telemetryczne, a niekiedy również informacje biznesowe i operacyjne. Taka centralizacja zwiększa wygodę pracy zespołów DevOps, SecOps i SRE, ale jednocześnie podnosi wartość samej platformy z perspektywy atakującego.

GrafanaGhost wpisuje się w szerszy trend zagrożeń związanych z integracją modeli językowych z narzędziami operacyjnymi. Coraz częściej obserwuje się scenariusze, w których model AI nie jest celem samym w sobie, lecz pośrednikiem wykonującym polecenia ukryte w logach, dokumentach, treści stron lub innych zewnętrznych danych. To przesuwa punkt ciężkości z tradycyjnych podatności na ryzyka architektoniczne i logiczne.

W tym przypadku szczególnie niebezpieczne jest to, że atak nie wymaga klasycznego phishingu ani jawnego nakłaniania użytkownika do uruchomienia podejrzanej akcji. Wystarczy, że komponent AI przetworzy odpowiednio przygotowany kontekst i uzna go za instrukcję dopuszczalnego działania.

Analiza techniczna

Mechanizm ataku opiera się na kilku warstwach. Punktem wejścia są funkcje AI w Grafanie, które analizują treści powiązane z danymi widocznymi dla użytkownika. Atakujący dostarcza złośliwy kontekst zawierający ukryty prompt, którego zadaniem jest wpłynięcie na zachowanie modelu.

Prompt injection nie jest kierowany bezpośrednio do operatora, lecz do systemu AI. Instrukcja może nakazywać zignorowanie guardrails, potraktowanie działania jako dozwolonego lub odwołanie się do zewnętrznego zasobu, na przykład obrazu albo innego elementu renderowanego spoza organizacji. Jeżeli aplikacja podejmie próbę pobrania takiego zasobu, żądanie sieciowe może stać się nośnikiem danych przekazywanych poza granice środowiska.

Istotną rolę odgrywa także obejście mechanizmów walidacji. Jeśli kontrola zewnętrznych adresów lub treści renderowanych przez aplikację zawiera błąd logiczny, atakujący może ominąć założone ograniczenia. W praktyce oznacza to, że nawet obecność zabezpieczeń na poziomie interfejsu i modelu nie gwarantuje skutecznej ochrony, jeżeli poszczególne warstwy systemu nie zostały zaprojektowane zgodnie z zasadą ograniczonego zaufania.

warstwa danych dostarcza złośliwy kontekst,
warstwa AI interpretuje go jako instrukcję operacyjną,
warstwa aplikacyjna wykonuje żądanie sieciowe,
warstwa sieciowa umożliwia opuszczenie granicy zaufania,
warstwa prezentacji staje się nośnikiem eksfiltracji.

Najbardziej niepokojące jest to, że cały łańcuch może wyglądać jak zwykłe użycie produktu. Dla zespołu operacyjnego analiza logów, praca z dashboardem i aktywność funkcji AI mogą nie odbiegać od standardowego wzorca działania.

Konsekwencje / ryzyko

Skala zagrożenia zależy od architektury wdrożenia, zakresu uprawnień Grafany, sposobu skonfigurowania funkcji AI oraz kontroli ruchu wychodzącego. Im większy dostęp platformy do danych i usług zewnętrznych, tym większy potencjalny wpływ incydentu.

wyciek danych operacyjnych i telemetrycznych,
ujawnienie informacji o architekturze i zasobach infrastruktury,
ekspozycja danych klientów, wskaźników biznesowych lub informacji finansowych,
naruszenie poufności danych wykorzystywanych przez zespoły techniczne i bezpieczeństwa,
cicha eksfiltracja bez jednoznacznych symptomów po stronie użytkownika.

Z perspektywy obrońcy problem jest trudny, ponieważ tradycyjne mechanizmy bezpieczeństwa nie zawsze wykrywają nadużycia logiki biznesowej wspieranej przez AI. Jeżeli organizacja skupia się wyłącznie na ochronie interfejsu użytkownika lub klasycznych sygnaturach ataku, może przeoczyć fakt, że model został zmanipulowany do wykonania pozornie legalnej operacji.

Rekomendacje

Organizacje korzystające z Grafany powinny traktować komponenty AI jako uprzywilejowany element przetwarzania danych. Oznacza to konieczność objęcia ich nie tylko kontrolami aplikacyjnymi, ale również politykami sieciowymi, zasadami minimalnych uprawnień i monitoringiem behawioralnym.

niezwłocznie wdrożyć poprawki i zalecenia producenta,
sprawdzić, czy funkcje AI są aktywne i czy są niezbędne w środowisku produkcyjnym,
ograniczyć dostęp Grafany do minimalnego zakresu danych,
wprowadzić ścisłą kontrolę ruchu wychodzącego z serwerów aplikacyjnych,
blokować lub filtrować odwołania do nieautoryzowanych domen,
monitorować nietypowe żądania HTTP generowane przez komponenty renderujące treści,
traktować logi, dokumenty i zewnętrzny kontekst jako dane potencjalnie wrogie,
stosować walidację i sanityzację danych wejściowych przekazywanych do funkcji AI,
wdrożyć mechanizmy detekcji prompt injection i anomalii w działaniu modeli,
regularnie przeglądać architekturę pod kątem kanałów eksfiltracji przez obrazy, znaczniki i zewnętrzne odwołania.

W praktyce trzy obszary mają kluczowe znaczenie: wyłączenie zbędnych funkcji AI, segmentacja dostępu do danych oraz kontrola połączeń wychodzących. Jeżeli aplikacja nie ma swobodnego dostępu do internetu, skuteczność podobnych scenariuszy ataku wyraźnie maleje.

Podsumowanie

GrafanaGhost pokazuje, że bezpieczeństwo nowoczesnych narzędzi analitycznych z funkcjami AI nie może być oceniane wyłącznie przez pryzmat tradycyjnych podatności. Nawet przy obecności guardrails i mechanizmów ochronnych możliwe jest zbudowanie łańcucha prowadzącego do cichej eksfiltracji danych.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że modele AI przetwarzające nieufne dane powinny być kontrolowane równie rygorystycznie jak komponenty wykonawcze, integracyjne i sieciowe. W praktyce kluczowe staje się nie tylko to, jakie informacje system może zobaczyć, ale również to, co może zrobić z przetworzonym kontekstem.

Źródła

https://www.securityweek.com/grafanaghost-attackers-can-abuse-grafana-to-leak-enterprise-data/
https://noma.security/grafanaghost/
https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/