Archiwa: AI - Strona 5 z 51 - Security Bez Tabu

Wyciek danych z MyLovely.AI ujawnia prywatne rozmowy, prompty i metadane ponad 100 tys. użytkowników

Wprowadzenie do problemu / definicja

Incydent bezpieczeństwa dotyczący platformy MyLovely.AI pokazuje, jak poważne konsekwencje może mieć naruszenie danych w usługach generatywnej AI przetwarzających treści intymne, wrażliwe i silnie spersonalizowane. W tym przypadku ujawniono nie tylko adresy e-mail, ale również prompty użytkowników, odnośniki do wygenerowanych obrazów, metadane oraz elementy powiązane z profilami kont.

Tego typu wyciek jest szczególnie groźny, ponieważ łączy klasyczne naruszenie danych osobowych z ekspozycją bardzo wrażliwego kontekstu behawioralnego. W praktyce oznacza to wyższe ryzyko szantażu, deanonymizacji i precyzyjnych ataków socjotechnicznych.

W skrócie

MyLovely.AI, platforma oferująca interakcje z generowanymi przez AI „partnerkami” oraz treści NSFW, padła ofiarą wycieku danych obejmującego ponad 100 tys. użytkowników. Ujawnione informacje miały zawierać adresy e-mail, prompty, linki do wygenerowanych obrazów, identyfikatory profili oraz dane zapisane w plikach JSON opisujących zasoby aplikacji.

Wyciek objął dane kont oraz treści tworzone przez użytkowników.
Wśród ujawnionych informacji znalazły się prompty NSFW i metadane zasobów.
Część danych można było powiązać z konkretnymi identyfikatorami użytkowników.
Ryzyko obejmuje szantaż, phishing, doxing i wtórną redystrybucję treści.

Kontekst / historia

Usługi oparte na generatywnej AI coraz częściej przechowują dane o wysokiej wrażliwości: historię rozmów, preferencje użytkownika, dane subskrypcyjne, wygenerowane multimedia oraz artefakty moderacyjne. W odróżnieniu od tradycyjnych platform społecznościowych, takie serwisy często gromadzą treści o charakterze emocjonalnym, intymnym lub seksualnym.

To sprawia, że skutki wycieku są znacznie poważniejsze niż w przypadku standardowej kompromitacji adresów e-mail czy nawet haseł. W analizowanym przypadku pojawiły się również przesłanki, że zestaw danych był dystrybuowany lub omawiany na forum cyberprzestępczym, co zwiększa ryzyko dalszej redystrybucji oraz wzbogacania zbioru o dodatkowe informacje z innych źródeł.

Analiza techniczna

Z technicznego punktu widzenia incydent wygląda na kompromitację zaplecza aplikacyjnego albo błędnie zabezpieczonego repozytorium danych, z którego pozyskano zarówno informacje profilowe, jak i treści generowane przez użytkowników. Ujawnione zbiory miały obejmować między innymi struktury opisane jako Profiles, Gallery_Items, Community_Items oraz Collections.

Taka nomenklatura sugeruje eksport lub zrzut pochodzący z warstwy aplikacyjnej, backendowego API albo magazynu dokumentowego. Kluczowe jest to, że incydent nie ograniczał się do prostych rekordów identyfikacyjnych, lecz obejmował szeroki zestaw danych kontekstowych.

prompty użytkowników, w tym treści NSFW,
linki do wygenerowanych obrazów,
metadane kolekcji i zasobów,
informacje o subskrypcjach,
adresy zasobów w pamięci obiektowej lub zewnętrznym storage,
elementy związane z moderacją treści.

To wskazuje na naruszenie logiki biznesowej platformy, a nie wyłącznie warstwy uwierzytelniania. Jeżeli odnośniki do materiałów multimedialnych pozostawały aktywne i dostępne bez dodatkowej autoryzacji albo korzystały z długowiecznych tokenów, rzeczywisty zasięg incydentu mógł być większy niż sam statyczny dump danych.

Najbardziej niepokojąca jest możliwość korelacji promptów z tożsamością użytkownika. Sam prompt może być kompromitujący, ale połączenie go z adresem e-mail, identyfikatorem konta, nazwą profilu czy informacją subskrypcyjną znacząco zwiększa wartość danych dla cyberprzestępców. W praktyce ułatwia to przygotowanie bardzo wiarygodnych wiadomości szantażowych i kampanii spear phishingowych.

Incydent uwidacznia także typowy problem w ekosystemie AI: nadmierną retencję danych. Długie przechowywanie promptów, wyników generowania, metadanych moderacyjnych i artefaktów kolekcji zwiększa skalę szkód po każdym naruszeniu, zwłaszcza gdy dane nie są odpowiednio segmentowane, szyfrowane lub pseudonimizowane.

Konsekwencje / ryzyko

Ryzyko dla użytkowników jest wyższe niż w przypadku klasycznych wycieków danych konsumenckich. Ujawnione treści mogą zostać wykorzystane nie tylko do ataków technicznych, ale również do nadużyć opartych na presji psychologicznej i reputacyjnej.

szantaż seksualny i wymuszenia,
kampanie phishingowe bazujące na intymnym kontekście,
próby przejęcia kont przez inżynierię społeczną,
deanonymizacja użytkowników działających pod pseudonimem,
profilowanie psychologiczne i reputacyjne,
wtórne wycieki obrazów i treści wygenerowanych przez platformę.

Dla organizacji rozwijających podobne usługi to sygnał ostrzegawczy, że dane promptów i rozmów nie powinny być traktowane wyłącznie jako materiał operacyjny czy telemetryczny. Z perspektywy prywatności są to dane wysokiego ryzyka, których naruszenie może prowadzić do strat wizerunkowych, roszczeń użytkowników, konsekwencji regulacyjnych oraz presji ze strony partnerów infrastrukturalnych i płatniczych.

Rekomendacje

Operatorzy platform AI powinni wdrożyć podejście „privacy by design” oraz „security by default”, szczególnie jeśli usługa przetwarza treści intymne. Ochrona takich danych musi obejmować zarówno architekturę aplikacji, jak i polityki retencji, dostępów oraz reagowania na incydenty.

minimalizacja retencji promptów, rozmów i wygenerowanych materiałów,
szyfrowanie danych w spoczynku oraz silne zarządzanie kluczami,
pseudonimizacja lub separacja identyfikatorów użytkownika od treści,
ograniczenie dostępu administracyjnego zgodnie z zasadą najmniejszych uprawnień,
regularne audyty konfiguracji storage, bucketów i backendowych API,
stosowanie krótkotrwałych, podpisywanych i rotowanych adresów URL do zasobów,
monitorowanie anomalii oraz eksportów danych o dużym wolumenie,
segmentacja środowisk i rozdzielenie danych produkcyjnych od analitycznych,
bezpieczne usuwanie treści oraz polityka retencji oparta na ryzyku,
przygotowanie procedur reakcji na incydenty i obowiązkowych powiadomień.

Użytkownicy, którzy mogli zostać objęci incydentem, również powinni podjąć działania ograniczające skutki wycieku.

zmienić hasła do powiązanych usług,
włączyć uwierzytelnianie wieloskładnikowe tam, gdzie to możliwe,
zachować ostrożność wobec wiadomości odwołujących się do prywatnych treści,
monitorować próby podszywania się i kampanie sextortion,
rozważyć zmianę aliasów, nazw użytkownika i adresów e-mail używanych w podobnych serwisach,
sprawdzić, czy ich dane nie pojawiły się w publicznych bazach powiadamiania o wyciekach.

Podsumowanie

Wyciek z MyLovely.AI pokazuje, że w incydentach dotyczących usług generatywnej AI największym problemem nie jest wyłącznie liczba rekordów, lecz charakter ujawnionych danych i możliwość ich powiązania z konkretnymi osobami. Prompty, obrazy, metadane i identyfikatory kont tworzą zestaw wyjątkowo atrakcyjny dla sprawców szantażu, profilowania i precyzyjnych ataków phishingowych.

Dla dostawców usług AI to kolejny dowód, że dane konwersacyjne i generatywne muszą być chronione z takim samym rygorem jak klasyczne dane wrażliwe. Dla użytkowników to przypomnienie, że każda platforma przechowująca intymne interakcje może stać się celem ataku o bardzo wysokiej wartości.

Źródła

Help Net Security — https://www.helpnetsecurity.com/2026/04/09/mylovely-ai-data-breach-user-conversations/
Have I Been Pwned — https://haveibeenpwned.com/

HackerOne wstrzymuje Internet Bug Bounty. AI ujawnia kryzys po stronie remediacji

Wprowadzenie do problemu / definicja

HackerOne wstrzymał przyjmowanie nowych zgłoszeń do programu Internet Bug Bounty, jednego z najbardziej rozpoznawalnych mechanizmów wspierających odpowiedzialne ujawnianie podatności w projektach open source. Decyzja ta pokazuje rosnące napięcie między gwałtownie rosnącą zdolnością do wykrywania luk a ograniczonymi możliwościami ich weryfikacji, priorytetyzacji i usuwania.

W praktyce oznacza to zmianę głównego wąskiego gardła w cyberbezpieczeństwie. Jeszcze niedawno największym wyzwaniem było samo znalezienie podatności. Dziś coraz częściej problemem staje się obsługa napływających raportów oraz skuteczna remediacja potwierdzonych błędów.

W skrócie

Internet Bug Bounty działał od 2013 roku jako inicjatywa wspierająca bezpieczeństwo kluczowych komponentów internetu i ekosystemu open source. Od 27 marca 2026 roku program przestał przyjmować nowe zgłoszenia, ponieważ liczba odkrywanych podatności zaczęła przewyższać możliwości ich skutecznej obsługi.

wykrywanie podatności stało się szybsze i tańsze dzięki automatyzacji oraz AI,
triage i remediacja nadal wymagają czasu, kompetencji i zasobów ludzkich,
część projektów zależnych od finansowania bounty, w tym Node.js, również zawiesiła wypłaty nagród,
sam proces zgłaszania problemów bezpieczeństwa nie został jednak całkowicie zatrzymany.

Kontekst / historia

Model bug bounty przez lata opierał się na prostym założeniu: najtrudniejsze jest znalezienie podatności, dlatego warto finansowo motywować badaczy do odpowiedzialnego zgłaszania błędów. Podejście to dobrze sprawdzało się w czasach, gdy większość analiz była wykonywana ręcznie, a wolumen zgłoszeń pozostawał relatywnie ograniczony.

Sytuacja zmieniła się wraz z rozwojem narzędzi automatyzujących analizę bezpieczeństwa. Następnym etapem było pojawienie się rozwiązań AI wspierających analizę kodu, generowanie hipotez o podatnościach, tworzenie proof-of-conceptów i przeszukiwanie dużych powierzchni ataku. W efekcie liczba potencjalnych ustaleń zaczęła rosnąć szybciej niż zdolność zespołów do ich praktycznego potwierdzania i naprawiania.

Problem szczególnie mocno dotyka projekty open source, które często są utrzymywane przez niewielkie zespoły lub wolontariuszy. Dla takich projektów nawet wartościowe zgłoszenia mogą stanowić duże obciążenie operacyjne, jeśli brakuje czasu, budżetu i osób odpowiedzialnych za proces bezpieczeństwa.

Analiza techniczna

Z technicznego punktu widzenia kryzys nie sprowadza się wyłącznie do większej liczby raportów. Kluczowe znaczenie ma pogorszenie relacji sygnału do szumu. Narzędzia AI potrafią przyspieszyć identyfikację potencjalnych słabości, ale nie gwarantują, że każda wskazana ścieżka prowadzi do realnej, eksploatowalnej podatności.

Wiele zgłoszeń wymaga kosztownej walidacji, ponieważ może opierać się na niepełnym kontekście, błędnych założeniach lub scenariuszach, które brzmią wiarygodnie, lecz nie przekładają się na praktyczne ryzyko. To oznacza, że zespoły triage muszą poświęcać coraz więcej czasu na ręczne odsiewanie raportów o niskiej jakości.

W konsekwencji maintainers i zespoły bezpieczeństwa tracą zasoby nie tylko na analizę prawdziwych problemów, ale również na obalanie błędnych hipotez. Jeśli dodatkowo program nagradza przede wszystkim sam fakt zgłoszenia, może to wzmacniać presję na ilość zamiast na jakość technicznej analizy.

Warto też podkreślić, że znalezienie podatności i usunięcie jej to dwa różne etapy. O ile AI może pomóc wykrywać wzorce błędów, o tyle przygotowanie bezpiecznej poprawki, testów regresyjnych, planu wydania i komunikacji do użytkowników wciąż wymaga wiedzy domenowej, doświadczenia i czasu. To właśnie na tym etapie kumulują się dziś największe koszty operacyjne.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem jest przeciążenie procesów bezpieczeństwa. Gdy liczba zgłoszeń rośnie szybciej niż zdolność do ich oceny, wydłuża się czas potwierdzenia, priorytetyzacji i wdrożenia poprawek. To automatycznie zwiększa okno ekspozycji na atak.

Drugim ryzykiem jest pogorszenie jakości samych programów bounty. Jeśli fundusze są konsumowane szybciej, niż organizacje są w stanie przekształcić raporty w realne poprawki bezpieczeństwa, cały model zaczyna tracić efektywność ekonomiczną.

Szczególnie narażony jest łańcuch dostaw oprogramowania. Wiele krytycznych bibliotek i frameworków stanowi fundament dla tysięcy produktów komercyjnych, a jednocześnie jest utrzymywanych przez niewielkie zespoły. Zalew zgłoszeń, zwłaszcza tych wspomaganych przez AI, może utrudnić odróżnienie problemów naprawdę krytycznych od automatycznie wygenerowanego szumu.

Na poziomie strategicznym branża staje przed niebezpieczną asymetrią: finansowany i skalowany jest etap wykrywania, natomiast etap usuwania błędów pozostaje chronicznie niedoinwestowany. Z perspektywy redukcji ryzyka jest to problem fundamentalny, ponieważ bezpieczeństwo poprawia się dopiero wtedy, gdy luka zostanie skutecznie załatana.

Rekomendacje

Organizacje prowadzące programy bug bounty powinny dostosować swoje modele operacyjne do realiów epoki AI. Kluczowe znaczenie mają mocniejsze mechanizmy filtrowania zgłoszeń, wielopoziomowy triage, ograniczanie duplikatów oraz lepsza ocena jakości raportów.

premiowanie raportów zawierających wiarygodny wpływ, warunki eksploatacji i pełną reprodukcję,
wprowadzenie scoringu jakości zgłoszeń i mechanizmów ograniczających spam,
budowa dedykowanych kompetencji po stronie security triage i PSIRT,
inwestowanie w automatyzację testów oraz procesy szybkiego wydawania poprawek,
większe wsparcie finansowe dla remediacji, a nie wyłącznie dla discovery.

Projekty open source i dostawcy oprogramowania powinni rozwijać zdolności remediacyjne równie intensywnie jak kanały przyjmowania zgłoszeń. Obejmuje to zarówno procedury bezpieczeństwa, jak i realne finansowanie osób odpowiedzialnych za analizę, naprawę i komunikację incydentów.

Po stronie odbiorców biznesowych potrzebne jest bardziej aktywne podejście do bezpieczeństwa łańcucha dostaw. Organizacje nie powinny zakładać, że społeczność samodzielnie zapewni pełną ochronę komponentów open source. Konieczne są własne procesy monitorowania podatności, priorytetyzacji krytycznych zależności oraz wsparcia dla projektów, od których biznes faktycznie zależy.

Podsumowanie

Wstrzymanie Internet Bug Bounty to ważny sygnał ostrzegawczy dla całej branży cyberbezpieczeństwa. Rozwój AI przyspieszył wykrywanie podatności, ale jednocześnie obnażył słabość procesów walidacji i remediacji, zwłaszcza w ekosystemie open source.

Najważniejszy wniosek jest prosty: większa liczba wykrytych luk nie oznacza automatycznie większego bezpieczeństwa. Bez odpowiednich zasobów do triage, potwierdzania i usuwania błędów nawet dojrzałe programy zgłaszania podatności mogą zacząć generować przeciążenie zamiast realnej redukcji ryzyka.

Źródła

Apple Intelligence: nowe obejście zabezpieczeń AI ujawnia ryzyko prompt injection na urządzeniach Apple

Wprowadzenie do problemu / definicja

Bezpieczeństwo systemów generatywnej sztucznej inteligencji zależy dziś nie tylko od jakości modeli, ale również od skuteczności mechanizmów ochronnych ograniczających niepożądane zachowania. Najnowsze ustalenia dotyczące Apple Intelligence pokazują, że nawet rozbudowane warstwy zabezpieczeń mogą zostać ominięte przez odpowiednio przygotowane dane wejściowe.

W opisywanym scenariuszu badacze połączyli adversarial prompt injection z manipulacją znakami Unicode. Taki atak może prowadzić nie tylko do wygenerowania niedozwolonych odpowiedzi, ale również do wpływania na sposób, w jaki model interpretuje polecenia, kontekst i dane dostępne w ramach integracji z systemem lub aplikacją.

W skrócie

Badania wskazują, że lokalne mechanizmy bezpieczeństwa Apple Intelligence mogły zostać ominięte z wysoką skutecznością. Atak łączy technikę Neural Execs, wykorzystującą nietypowe i pozornie bezsensowne ciągi znaków jako wyzwalacze określonych zachowań modelu, z manipulacją renderowaniem tekstu przy użyciu Unicode.

celem było obejście filtrów wejścia i wyjścia oraz wewnętrznych guardrails,
w testach uzyskano skuteczność na poziomie 76% dla 100 losowych promptów,
największe ryzyko dotyczy aplikacji zintegrowanych z Apple Intelligence i operujących na wrażliwym kontekście użytkownika.

Kontekst / historia

Apple Intelligence to zestaw funkcji AI zintegrowanych z iOS, iPadOS i macOS, łączący lokalne modele uruchamiane na urządzeniu z dodatkowymi mechanizmami obsługi bardziej złożonych zadań. Taka architektura jest promowana jako rozwiązanie wspierające prywatność, jednak lokalne przetwarzanie samo w sobie nie eliminuje ryzyka manipulacji modelem.

Nowoczesne systemy AI są zwykle chronione wielowarstwowo. Obejmuje to filtrowanie promptów wejściowych, kontrolę odpowiedzi, klasyfikację treści oraz dodatkowe polityki bezpieczeństwa narzucone przez producenta platformy. Problem polega na tym, że atakujący coraz częściej nie próbują łamać pojedynczego filtra wprost, lecz szukają sposobów na wywołanie rozjazdu między treścią widoczną dla człowieka, reprezentacją przetwarzaną przez model i logiką warstw ochronnych.

W tym przypadku badacze mieli zgłosić problem producentowi już w 2025 roku, a następnie wskazano, że odpowiednie zabezpieczenia zostały wdrożone w nowszych wersjach systemów. Nie ma publicznie potwierdzonych informacji o aktywnym wykorzystaniu tej techniki w realnych kampaniach, ale sam wektor ataku ma istotne znaczenie dla oceny odporności ekosystemów AI.

Analiza techniczna

Sednem ataku jest połączenie dwóch technik ofensywnych. Pierwsza z nich, określana jako Neural Execs, wykorzystuje semantycznie nieczytelne lub trudne do interpretacji ciągi wejściowe, które mogą działać jak uniwersalne wyzwalacze określonych reakcji modelu. To szczególnie problematyczne z punktu widzenia detekcji, ponieważ analiza oparta wyłącznie na jawnej treści promptu może nie rozpoznać złośliwej intencji.

Drugim elementem jest manipulacja Unicode, w tym użycie mechanizmów wpływających na kierunek renderowania tekstu, takich jak right-to-left override. Pozwala to zmienić sposób prezentacji treści bez zmiany jej logicznej struktury. W praktyce oznacza to możliwość ukrycia znaczenia danych wejściowych lub wyjściowych przed częścią filtrów bezpieczeństwa.

Połączenie tych metod tworzy atak wieloetapowy:

model otrzymuje nietypowe wejście, które nie wygląda jak klasyczny złośliwy prompt,
warstwa ochronna nie wykrywa zagrożenia na etapie analizy,
model wykonuje zachowanie zgodne z intencją atakującego,
wynik może zostać dodatkowo zakodowany w sposób utrudniający jego blokadę przez filtry wyjściowe,
ostatecznie treść lub polecenie może wpłynąć na funkcje aplikacyjne albo dane dostępne przez integrację.

Najważniejsze jest to, że problem nie ogranicza się do generowania zabronionych treści. Jeżeli model ma dostęp do wiadomości, zdjęć, kalendarza, danych zdrowotnych lub funkcji aplikacji trzecich, prompt injection staje się potencjalnym wektorem naruszenia poufności i integralności danych.

Konsekwencje / ryzyko

Ryzyko należy rozpatrywać na kilku poziomach. Po pierwsze, obejście guardrails podważa zaufanie do ochrony wdrażanej w systemach AI. Po drugie, zagrożenie rośnie wraz z zakresem uprawnień nadawanych komponentom AI przez aplikacje i system operacyjny.

Potencjalne konsekwencje obejmują:

generowanie niedozwolonych odpowiedzi mimo aktywnych filtrów,
obchodzenie polityk bezpieczeństwa opartych na klasyfikacji treści,
wpływ na logikę aplikacji zintegrowanych z AI,
ryzyko ekspozycji danych osobowych i innych informacji wrażliwych,
wykorzystanie modelu jako pośrednika do inicjowania działań, których użytkownik nie zamierzał wykonać.

Dla organizacji budujących rozwiązania oparte na systemowym AI kluczowe jest zrozumienie, że zagrożenie nie musi wynikać z klasycznych błędów, takich jak memory corruption czy zdalne wykonanie kodu. Coraz częściej problemem są błędne założenia dotyczące bezpieczeństwa warstwy semantycznej oraz zaufania do danych przetwarzanych przez model.

Rekomendacje

Deweloperzy i zespoły bezpieczeństwa powinni traktować modele AI jako komponenty nieufne, nawet jeśli działają lokalnie i pochodzą od renomowanego dostawcy. Oznacza to konieczność wdrożenia dodatkowych zabezpieczeń na poziomie aplikacji, logiki biznesowej i kontroli dostępu.

stosowanie zasady minimalnych uprawnień dla integracji AI,
oddzielanie instrukcji systemowych, danych użytkownika i kontekstu aplikacyjnego,
normalizacja oraz filtrowanie Unicode przed i po przetworzeniu przez model,
blokowanie automatycznego wykonywania wrażliwych działań wyłącznie na podstawie odpowiedzi modelu,
prowadzenie testów red team obejmujących prompt injection, output smuggling i manipulację kodowaniem znaków,
monitorowanie nietypowych wzorców wejść i wyjść, w tym sekwencji kontrolnych oraz pozornie losowych ciągów znaków.

Szczególne znaczenie ma również wdrożenie jawnej autoryzacji dla operacji na danych wrażliwych oraz niezależnych polityk decyzyjnych dla akcji inicjowanych przez komponenty AI. Tylko takie podejście ogranicza ryzyko nadużyć wynikających z błędnej interpretacji promptu lub zmanipulowanego kontekstu.

Podsumowanie

Nowe ustalenia dotyczące Apple Intelligence pokazują, że bezpieczeństwo AI nie kończy się na lokalnym przetwarzaniu danych i filtrach treści. Połączenie adversarial prompt injection z manipulacją Unicode umożliwiło obejście mechanizmów ochronnych z istotną skutecznością, a największe ryzyko dotyczy scenariuszy, w których model ma dostęp do danych użytkownika i funkcji aplikacyjnych.

Dla branży cybersecurity to kolejny dowód, że systemy AI należy projektować zgodnie z zasadą zero trust. Ochrona powinna obejmować walidację wejścia, ograniczanie uprawnień, kontrolę działań wykonywanych przez model oraz ciągłe testowanie odporności na nowe klasy ataków semantycznych.

Źródła

Apple Intelligence AI Guardrails Bypassed in New Attack — https://www.securityweek.com/apple-intelligence-ai-guardrails-bypassed-in-new-attack/
Neural Exec: Learning to Jailbreak LLMs with Adversarial Prompts — https://arxiv.org/abs/2407.11969
Unicode Standard Annex #9: Unicode Bidirectional Algorithm — https://www.unicode.org/reports/tr9/

Klucze Google API w aplikacjach Android mogą otwierać nieautoryzowany dostęp do Gemini

Wprowadzenie do problemu / definicja

Twardo zakodowane klucze Google API w aplikacjach Android od lat były postrzegane jako element o ograniczonej wrażliwości, zwłaszcza gdy służyły głównie do identyfikacji projektu. Najnowsze ustalenia pokazują jednak, że w określonych konfiguracjach te same klucze mogą zapewniać dostęp do usług Gemini, czyli środowiska generatywnej AI Google. W praktyce oznacza to, że dane osadzone w publicznie dostępnych pakietach APK mogą zostać użyte do nieautoryzowanych wywołań API, dostępu do zasobów oraz nadużyć kosztowych.

Problem jest szczególnie istotny dla twórców aplikacji mobilnych, ponieważ każde publicznie opublikowane APK może zostać poddane analizie statycznej. Jeśli klucz API pozostaje w kodzie lub plikach konfiguracyjnych, jego pozyskanie przez osobę trzecią jest zazwyczaj kwestią czasu, a nie zaawansowanych umiejętności.

W skrócie

Badacze wykazali, że klucze Google API osadzone w aplikacjach Android można łatwo wyodrębnić z pakietów APK.
W części przypadków te same klucze pozwalały na wywoływanie endpointów Gemini.
Problem objął dziesiątki kluczy znalezionych w popularnych aplikacjach o łącznej bazie użytkowników przekraczającej setki milionów.
Ryzyko obejmuje dostęp do plików, danych cache, wyczerpanie limitów API oraz generowanie kosztów po stronie właściciela projektu.
Zagrożenie wynika nie tylko z obecności klucza w aplikacji, ale także z konfiguracji usług aktywowanych później w tym samym projekcie chmurowym.

Kontekst / historia

Środowisko bezpieczeństwa od dawna podkreśla, że aplikacje Android są podatne na analizę reverse engineering. Po rozpakowaniu pakietu APK można przeszukiwać zasoby, manifest, ciągi znaków, pliki konfiguracyjne i zdekompilowany kod w poszukiwaniu sekretów lub tokenów. Dotąd część zespołów deweloperskich traktowała jednak klucze Google API jako identyfikatory techniczne, a nie pełnoprawne sekrety.

Sytuacja zmieniła się wraz z rozwojem usług AI i rosnącą integracją Gemini z projektami korzystającymi z ekosystemu Google. Klucz, który wcześniej miał ograniczone znaczenie bezpieczeństwa, może po aktywacji nowych usług zyskać realną wartość ofensywną. To właśnie ta zmiana kontekstu sprawia, że starsze praktyki projektowe przestają być wystarczające.

Nowe ustalenia pokazują, że zagrożenie nie ma charakteru czysto teoretycznego. W wielu przypadkach możliwe było przełożenie prostego pozyskania klucza z aplikacji na dostęp do zasobów Gemini powiązanych z tym samym projektem.

Analiza techniczna

Techniczny mechanizm zagrożenia opiera się na relacji między kluczem Google API a projektem, w którym aktywowano usługi Gemini. Jeżeli deweloper osadził klucz w aplikacji mobilnej, a następnie w tym samym projekcie uruchomił funkcje AI, klucz może zacząć działać jako ważny element umożliwiający komunikację z endpointami Gemini.

Typowy scenariusz ataku jest stosunkowo prosty. Napastnik pobiera publicznie dostępną aplikację Android, analizuje pakiet APK, wyodrębnia klucz rozpoznawalny po prefiksie „AIza”, a następnie wykorzystuje go do wywołań API związanych z Gemini. Jeśli po stronie projektu nie wdrożono dodatkowych ograniczeń, możliwe staje się wykonywanie operacji w imieniu cudzego środowiska.

Istotnym aspektem jest tu retroaktywna zmiana znaczenia klucza. Nie chodzi o klasyczne przejęcie uprawnień w urządzeniu użytkownika, lecz o sytuację, w której wcześniej osadzony i publicznie dostępny klucz zyskuje nowe możliwości po zmianie konfiguracji usług chmurowych. Deweloper może nie zauważyć, że wraz z aktywacją AI dotychczasowy model bezpieczeństwa przestał działać zgodnie z założeniami.

Z perspektywy atakującego najbardziej atrakcyjne są następujące możliwości:

wywoływanie modeli Gemini z wykorzystaniem cudzego projektu,
dostęp do przesłanych plików i danych pomocniczych,
odczyt zawartości cache powiązanej z operacjami AI,
generowanie kosztów rozliczeniowych,
wyczerpywanie quota i zakłócanie działania legalnej aplikacji.

Konsekwencje / ryzyko

Pierwszym obszarem ryzyka jest poufność danych. Jeśli aplikacja mobilna przesyła do usług AI treści użytkowników, dokumenty, obrazy lub inne pliki, nieautoryzowany dostęp do zasobów Gemini może prowadzić do ujawnienia części tych informacji. Nawet ograniczony dostęp do danych roboczych lub plików tymczasowych może oznaczać istotny incydent bezpieczeństwa.

Drugim wymiarem jest dostępność i integralność usług. Osoba nieuprawniona może generować arbitralne żądania do API, zużywać limity i powodować przeciążenie projektu. W praktyce skutkiem mogą być błędy po stronie legalnych użytkowników, opóźnienia działania funkcji AI lub czasowa niedostępność wybranych funkcji aplikacji.

Trzecie ryzyko ma charakter finansowy. Nadużycia związane z modelami generatywnej AI mogą bezpośrednio przekładać się na koszty, zwłaszcza przy intensywnym użyciu API lub przetwarzaniu dużych wolumenów danych. Organizacja może wykryć problem dopiero po analizie rachunków lub anomalii w logach wykorzystania.

Nie można też pominąć aspektu zgodności i odpowiedzialności. Jeżeli słabo zabezpieczone klucze doprowadzą do ekspozycji danych użytkowników, firma może stanąć przed koniecznością przeprowadzenia analizy naruszenia, zgłoszenia incydentu oraz aktualizacji procedur bezpiecznego wytwarzania oprogramowania.

Rekomendacje

Podstawową zasadą powinno być traktowanie każdego klucza osadzanego w aplikacji mobilnej jako potencjalnie publicznego. Oznacza to, że nie należy przypisywać takim kluczom uprawnień umożliwiających dostęp do danych, funkcji AI ani usług, które mogą generować koszty.

W praktyce organizacje powinny wdrożyć następujące działania:

usunąć klucze API z kodu aplikacji wszędzie tam, gdzie jest to możliwe,
przenieść wywołania wrażliwych usług AI do backendu kontrolowanego przez organizację,
stosować warstwę pośredniczącą z autoryzacją użytkownika i kontrolą dostępu,
rotować klucze, które były obecne w publicznych wersjach aplikacji,
ograniczać klucze do konkretnych API, aplikacji, sygnatur i scenariuszy użycia,
monitorować billing, quota oraz anomalie w wykorzystaniu usług AI,
skanować kod i artefakty CI/CD pod kątem sekretów i identyfikatorów,
regularnie przeglądać konfigurację projektów chmurowych po aktywacji nowych usług,
prowadzić testy reverse engineering jako element oceny bezpieczeństwa aplikacji mobilnych,
rozdzielać projekty i klucze pomiędzy różne środowiska oraz różne funkcje biznesowe.

Dobrym kierunkiem jest także segmentacja architektury. Jeżeli aplikacja wymaga publicznego identyfikatora dla jednej usługi, nie powinna współdzielić tego samego kontekstu projektowego z komponentami AI operującymi na danych użytkowników. Takie rozdzielenie zmniejsza promień rażenia w razie wycieku klucza.

Podsumowanie

Przypadek kluczy Google API w aplikacjach Android pokazuje, jak szybko zmienia się model zagrożeń w ekosystemie AI. Elementy wcześniej uznawane za niskiego ryzyka mogą wraz ze zmianą konfiguracji chmurowej zyskać nowe znaczenie bezpieczeństwa i stać się punktem wejścia do nadużyć.

Dla deweloperów i zespołów bezpieczeństwa to wyraźny sygnał, że integracje z generatywną AI wymagają innego podejścia niż tradycyjne użycie publicznych usług API. Ochrona powinna opierać się na backendzie, ścisłej kontroli dostępu, segmentacji projektów, monitoringu nadużyć oraz regularnym przeglądzie konfiguracji usług chmurowych.

Źródła

Kampania VENOM atakuje kadrę zarządzającą i przejmuje konta Microsoft 365 mimo MFA

Wprowadzenie do problemu / definicja

Na początku kwietnia 2026 roku opisano kampanię phishingową wykorzystującą nową platformę phishing-as-a-service o nazwie VENOM. Operacja jest wymierzona przede wszystkim w członków zarządów, dyrektorów finansowych oraz menedżerów wysokiego szczebla korzystających z Microsoft 365, a jej celem jest nie tylko kradzież poświadczeń, lecz także przejęcie sesji i utrzymanie dostępu do środowiska tożsamości ofiary.

To istotna zmiana w charakterze współczesnych ataków. W praktyce napastnicy nie muszą już ograniczać się do wyłudzenia hasła, ponieważ coraz częściej próbują przechwycić zaufaną sesję lub uzyskać tokeny pozwalające działać w ramach legalnego procesu uwierzytelniania.

W skrócie

VENOM to zamknięta platforma PhaaS używana do precyzyjnych kampanii przeciwko kadrze kierowniczej.
Ataki podszywają się pod powiadomienia SharePoint i wykorzystują kody QR zapisane znakami Unicode.
Mechanizm przenosi ofiarę na urządzenie mobilne, co pomaga ominąć część zabezpieczeń stacji roboczej.
Po wejściu w łańcuch ataku użytkownik może trafić do scenariusza AiTM albo phishingu opartego na device code.
Celem jest przejęcie sesji, tokenów oraz ustanowienie trwałego dostępu do konta Microsoft 365.

Kontekst / historia

Phishing ukierunkowany na środowiska Microsoft 365 od lat pozostaje jednym z głównych wektorów przejęcia tożsamości w firmach. W ostatnich latach obserwujemy przejście od prostych stron wyłudzających hasła do bardziej zaawansowanych zestawów adversary-in-the-middle, które pośredniczą w czasie rzeczywistym podczas logowania i przechwytują tokeny sesyjne.

Równolegle rośnie skala nadużyć związanych z mechanizmem device code. Ten model bazuje na legalnym procesie autoryzacji urządzenia, dlatego bywa trudniejszy do wykrycia niż klasyczny phishing formularzowy. VENOM wpisuje się w ten trend, ale wyróżnia się wysokim poziomem organizacji operacyjnej, własnym panelem zarządzania kampaniami oraz kontrolowanym, ograniczonym sposobem dystrybucji.

Analiza techniczna

Łańcuch ataku rozpoczyna się od wiadomości e-mail imitującej wewnętrzne powiadomienie SharePoint. Wiadomości są silnie spersonalizowane i skonstruowane tak, aby wyglądały jak realna korespondencja biznesowa. Dodatkowe elementy HTML, sztuczne klasy CSS, komentarze i rozbudowane wątki wiadomości mają utrudniać analizę treści oraz omijać mechanizmy detekcji oparte na sygnaturach.

Jednym z najbardziej charakterystycznych elementów kampanii jest użycie kodów QR zapisanych jako układ znaków Unicode osadzonych bezpośrednio w HTML. Taka technika zmniejsza skuteczność części rozwiązań skanujących obrazy i załączniki, a jednocześnie zachęca odbiorcę do zeskanowania kodu telefonem i kontynuowania interakcji poza firmowym endpointem.

Adres ofiary bywa ukrywany w fragmencie adresu URL zakodowanym podwójnym Base64. Ponieważ część po znaku kratki nie jest standardowo przesyłana do serwera w żądaniu HTTP, analiza i reputacyjne wykrywanie takich linków stają się trudniejsze. Po wejściu na stronę użytkownik trafia do warstwy filtrującej, która ma oddzielić realne cele od badaczy, automatycznych skanerów, sandboxów i systemów analitycznych.

Mechanizmy filtrujące wykorzystują między innymi ocenę User-Agent, reputację adresu IP, elementy honeypot i dodatkowe kontrole wskazujące na środowisko analityczne. Osoby lub systemy, które nie spełniają kryteriów, są przekierowywane do legalnych serwisów, co ogranicza ryzyko wzbudzenia podejrzeń.

Po przejściu przez filtr ofiara trafia do jednego z dwóch scenariuszy. W modelu AiTM fałszywa strona pośredniczy w prawdziwym logowaniu do Microsoft. Użytkownik widzi wiarygodny ekran logowania, często z poprawnym brandingiem organizacji i wstępnie uzupełnionym adresem e-mail, a operator ataku przechwytuje dane logowania, kody MFA i finalnie sesję.

Drugi wariant opiera się na device code phishing. W tym przypadku użytkownik otrzymuje instrukcję wprowadzenia kodu na legalnej stronie logowania urządzenia i zatwierdzenia dostępu. Ofiara nie wpisuje hasła w fałszywym formularzu, co znacząco utrudnia wykrycie ataku przez klasyczne zabezpieczenia antyphishingowe, ale skutkiem nadal jest wydanie tokenów napastnikowi.

Kluczowym etapem jest utrzymanie dostępu. W scenariuszu AiTM platforma może doprowadzić do zarejestrowania nowego urządzenia lub dodatkowej metody MFA na koncie ofiary jeszcze w trakcie aktywnej sesji. W wariancie device code trwałość zapewnia przejęty refresh token, dlatego sama zmiana hasła może nie wystarczyć do pełnego usunięcia dostępu intruza.

Konsekwencje / ryzyko

Ryzyko związane z kampanią VENOM jest szczególnie wysokie, ponieważ celem są osoby posiadające szerokie uprawnienia, dostęp do danych finansowych i strategicznych oraz możliwość autoryzowania wrażliwych działań biznesowych. Przejęcie konta członka zarządu lub dyrektora finansowego może prowadzić do oszustw BEC, wyłudzeń płatności, kradzieży dokumentów poufnych i dalszej kompromitacji organizacji.

Dodatkowym problemem jest skuteczność zastosowanych technik omijania zabezpieczeń. Unicode QR, ukrywanie danych w fragmencie URL oraz przekierowania do legalnych stron dla niepożądanych odwiedzających tworzą wielowarstwowy model utrudniający wykrywanie i analizę incydentu.

Kampania podważa również założenie, że samo MFA jest wystarczającą ochroną. Jeśli napastnik przejmie tokeny sesyjne lub skłoni ofiarę do zatwierdzenia legalnie wyglądającego procesu device code, może uzyskać dostęp bez klasycznego obchodzenia kontroli wieloskładnikowej. Z perspektywy obrońcy oznacza to konieczność ochrony nie tylko haseł, ale całego procesu tożsamości i sesji.

Rekomendacje

Organizacje powinny traktować tego typu kampanie jako atak na warstwę tożsamości. Priorytetem jest wdrożenie metod uwierzytelniania odpornych na phishing, takich jak FIDO2 i passkeys, zwłaszcza dla kadry kierowniczej, administratorów oraz kont uprzywilejowanych.

Warto przeanalizować, czy przepływ device code jest rzeczywiście potrzebny biznesowo. Jeśli nie, należy go ograniczyć lub wyłączyć. Jeżeli pozostaje wymagany, powinien zostać objęty ścisłym monitoringiem, politykami dostępu warunkowego i dodatkowymi kontrolami ryzyka.

Monitorować rejestrację nowych urządzeń i metod MFA.
Analizować nietypowe logowania do Entra ID oraz anomalie związane z tokenami odświeżania.
Wdrożyć alerty dla nietypowych lokalizacji, urządzeń i przepływów autoryzacyjnych.
Uwzględnić w procedurach IR unieważnianie aktywnych sesji oraz cofanie tokenów.
Regularnie przeglądać zarejestrowane metody MFA i listę zaufanych urządzeń.
Szkolić kadrę zarządzającą z rozpoznawania wiadomości z kodami QR i nietypowych żądań logowania na telefonie.

W reagowaniu na incydenty trzeba założyć, że reset hasła może być niewystarczający. W przypadku podejrzenia kompromitacji konieczne może być unieważnienie wszystkich aktywnych sesji, cofnięcie zgód tokenowych, przegląd metod MFA, usunięcie nieautoryzowanych urządzeń i szczegółowa analiza historii logowań oraz działań administracyjnych.

Podsumowanie

VENOM pokazuje, że współczesny phishing coraz częściej koncentruje się na przejęciu zaufanej tożsamości, a nie wyłącznie na kradzieży hasła. Połączenie personalizacji, technik unikania analizy, przeniesienia interakcji na urządzenia mobilne oraz nadużycia legalnych mechanizmów uwierzytelniania sprawia, że atak jest szczególnie groźny dla organizacji korzystających z Microsoft 365.

Dla firm oznacza to potrzebę przesunięcia strategii obrony z tradycyjnego antyphishingu na ochronę warstwy tożsamości, tokenów i sesji. Bez takiej zmiany nawet dobrze wdrożone MFA może nie zapewnić oczekiwanego poziomu odporności.

Źródła

Project Glasswing (Anthropic): AI, Które Znajduje I Exploituje Podatności Szybciej Niż Człowiek

Nie chodzi o model. Chodzi o zmianę zasad gry

Jeśli spojrzysz na Project Glasswing jak na kolejny launch modelu AI, przeoczysz sedno. Anthropic nie zrobiło publicznej premiery „nowego Claude’a do cybera”. Zrobiło coś dużo ciekawszego: zamknęło dostęp do modelu, uruchomiło program defensywny z udziałem AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA i Palo Alto Networks, rozszerzyło dostęp na ponad 40 kolejnych organizacji utrzymujących krytyczne oprogramowanie, dorzuciło do 100 mln USD kredytów oraz zapowiedziało publiczny raport z wnioskami i poprawkami w ciągu 90 dni. To nie wygląda jak marketing produktu. To wygląda jak zarządzanie ryzykiem wokół capability, które zaczynają mieć znaczenie systemowe dla bezpieczeństwa software’u.

Czytaj dalej

Grafana łata podatność „GrafanaGhost”. Błąd AI mógł prowadzić do wycieku danych użytkowników

Wprowadzenie do problemu / definicja

Grafana usunęła podatność określaną jako „GrafanaGhost”, związaną z komponentami AI wykorzystywanymi w platformie observability. Problem dotyczył klasy pośrednich ataków prompt injection, w których złośliwe instrukcje są ukrywane w treściach przetwarzanych później przez model i mogą wpływać na jego działanie bez klasycznego, bezpośredniego polecenia wydanego w interfejsie czatu.

W praktyce oznaczało to ryzyko, że asystent AI obsługujący dane w Grafanie potraktuje spreparowaną treść jako wiarygodny kontekst roboczy. W rezultacie mogło dojść do nieautoryzowanego ujawnienia informacji lub przesłania danych do zasobu kontrolowanego przez napastnika.

W skrócie

Podatność została ujawniona 7 kwietnia 2026 roku i dotyczyła sposobu interpretacji zewnętrznych treści przez komponenty AI w Grafanie. Badacze wskazali, że odpowiednio przygotowane znaczniki obrazów oraz ukryte instrukcje mogły posłużyć do obejścia części zabezpieczeń i uruchomienia scenariusza eksfiltracji danych.

Grafana potwierdziła problem oraz wdrożyła poprawkę, jednocześnie podkreślając, że skuteczne wykorzystanie błędu nie miało charakteru całkowicie bezobsługowego i wymagało interakcji użytkownika. Niezależnie od tej różnicy interpretacyjnej incydent pokazuje, jak wrażliwe na manipulację mogą być systemy GenAI osadzone w narzędziach operacyjnych.

Kontekst / historia

Grafana jest szeroko stosowana do wizualizacji logów, metryk, zdarzeń i danych operacyjnych, często w środowiskach o znaczeniu krytycznym dla biznesu. Z tego powodu każda podatność dotycząca mechanizmów renderowania treści lub warstwy AI ma podwyższoną wagę, ponieważ platforma bywa zintegrowana z wartościowymi źródłami informacji o infrastrukturze, użytkownikach i procesach.

Problem opisała firma Noma Security, która przedstawiła scenariusz pośredniego prompt injection prowadzącego do wycieku danych przedsiębiorstwa. Według badaczy złośliwy ładunek mógł zostać osadzony w treści, którą system później pobierał i analizował podczas zwykłej pracy użytkownika, na przykład przy przeglądaniu logów lub innych danych zawierających elementy zewnętrzne.

Istotą sporu między badaczami a dostawcą była skala automatyzacji ataku. Badacze akcentowali możliwość uruchomienia niebezpiecznego przepływu przy minimalnej świadomości ofiary, natomiast Grafana zaznaczyła, że nie był to scenariusz całkowicie „zero-click” i nie ma dowodów na aktywne wykorzystanie luki w realnych incydentach.

Analiza techniczna

Od strony technicznej problem znajdował się na styku przetwarzania kontekstu przez AI, renderowania Markdown oraz obsługi obrazów. Badacze wskazali, że mechanizmy ograniczające nadużycia związane z zewnętrznymi obrazami mogły zostać obejście poprzez odpowiednio przygotowane odwołania oraz instrukcje zakamuflowane jako pozornie bezpieczna treść.

To klasyczny przykład pośredniego prompt injection. Napastnik nie komunikuje się bezpośrednio z modelem, lecz umieszcza instrukcje w danych, które system uznaje za część kontekstu roboczego. Gdy komponent AI pobiera i analizuje taką treść, może nadać jej wysoki priorytet semantyczny i wykonać działania niezgodne z intencją operatora systemu.

W tego typu scenariuszu tradycyjne zabezpieczenia aplikacyjne nie zawsze są wystarczające. Nawet jeśli aplikacja ogranicza dostęp do niektórych zasobów lub filtruje określone wejścia, model AI może stać się warstwą interpretacyjną, która odczyta złośliwe instrukcje z nieufnych danych i potraktuje je jak legalne polecenie operacyjne.

Grafana poinformowała, że podatny element związany z rendererem obrazów w module Markdown został poprawiony. Wskazuje to, że źródłem problemu było połączenie logiki renderowania treści, walidacji zewnętrznych zasobów oraz sposobu, w jaki asystent AI budował i przetwarzał kontekst.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem takiej podatności jest możliwość eksfiltracji danych z platformy, która często agreguje informacje o wysokiej wartości biznesowej. W zależności od wdrożenia mogą to być logi aplikacyjne, metryki infrastruktury, wskaźniki operacyjne, dane klientów lub szczegóły środowisk produkcyjnych.

Ryzyko jest szczególnie istotne tam, gdzie funkcje GenAI uzyskały szeroki dostęp do źródeł danych i mogą inicjować operacje na podstawie analizowanego kontekstu. Tego rodzaju ataki są trudniejsze do wykrycia, ponieważ nie przypominają klasycznego przejęcia konta czy uruchomienia złośliwego kodu, lecz wykorzystują sam mechanizm rozumienia treści przez model.

Dodatkowym zagrożeniem jest ograniczona widoczność dla użytkownika końcowego. Osoba korzystająca z systemu może wykonać zwykłą, rutynową czynność, nie mając świadomości, że uruchamia łańcuch zdarzeń prowadzący do ujawnienia informacji poza organizację.

Rekomendacje

Organizacje korzystające z Grafany powinny w pierwszej kolejności upewnić się, że wdrożyły najnowsze poprawki bezpieczeństwa oraz przeanalizowały konfigurację komponentów AI i mechanizmów renderowania treści. Szczególne znaczenie ma ograniczenie relacji między nieufnymi danymi wejściowymi a zasobami, do których model ma dostęp.

zaktualizować instancje Grafany oraz powiązane komponenty AI do wersji zawierających poprawki,
ograniczyć pobieranie i renderowanie treści z niezaufanych źródeł,
wdrożyć segmentację dostępu między asystentem AI a wrażliwymi źródłami danych,
monitorować nietypowe połączenia wychodzące, zwłaszcza do nieznanych hostów,
rejestrować operacje wykonywane przez funkcje AI i audytować kontekst przekazywany do modeli,
stosować allowlisty dla domen i zasobów osadzanych w treści,
testować rozwiązania GenAI pod kątem pośrednich ataków prompt injection, a nie wyłącznie klasycznych podatności webowych.

Dobrą praktyką pozostaje traktowanie wszystkich danych wejściowych dla modeli jako potencjalnie nieufnych, nawet jeśli pochodzą z logów, dashboardów lub innych rutynowo wykorzystywanych źródeł wewnętrznych. W architekturach z AI izolacja uprawnień i kontrola semantyczna stają się równie ważne jak tradycyjna walidacja danych.

Podsumowanie

Przypadek „GrafanaGhost” pokazuje, że integracja AI w platformach observability otwiera nową powierzchnię ataku, w której prompt injection może prowadzić do realnego ryzyka wycieku danych. Nawet jeśli szczegóły dotyczące poziomu interakcji użytkownika pozostają przedmiotem dyskusji, sam incydent potwierdza potrzebę projektowania funkcji GenAI zgodnie z zasadą nieufnego kontekstu wejściowego.

Dla zespołów bezpieczeństwa to kolejny sygnał, że modelowanie zagrożeń dla systemów AI musi wykraczać poza klasyczne podatności aplikacyjne i API. Ochrona narzędzi takich jak Grafana wymaga dziś jednoczesnego spojrzenia na warstwę aplikacyjną, logikę renderowania oraz semantyczne zachowanie modeli.

Źródła

Dark Reading – https://www.darkreading.com/application-security/grafana-patches-ai-bug-leaked-user-data
Noma Security – https://noma.security/blog/grafana-ghost/
SecurityWeek – https://www.securityweek.com/grafanaghost-attackers-can-abuse-grafana-to-leak-enterprise-data/
Grafana Labs – https://grafana.com/docs/grafana/latest/panels-visualizations/visualizations/text/