3 godzin temu
Wprowadzenie do problemu / definicja
Dynamiczny rozwój generatorów aplikacji opartych na AI znacząco obniżył próg wejścia do tworzenia prostych narzędzi webowych. Jednocześnie zwiększył ryzyko tzw. shadow AI, czyli wdrażania rozwiązań poza formalnym nadzorem działów bezpieczeństwa i IT. Najnowszy przypadek dotyczący aplikacji budowanych w Grok pokazuje, iż błędne ustawienia publikacji oraz niewystarczające mechanizmy kontroli dostępu mogą prowadzić do masowego ujawnienia danych biznesowych, danych osobowych, a choćby sekretów uwierzytelniających.
W skrócie
Badacze bezpieczeństwa ustalili, iż spośród 37 571 aktywnych aplikacji utworzonych w Grok aż 35 578 było dostępnych publicznie bez logowania. Wśród ujawnionych zasobów znalazły się aplikacje zawierające dane organizacyjne, informacje kadrowe, materiały sprzedażowe, dane medyczne oraz przypadki przechowywania haseł w postaci jawnej. Problem nie ograniczał się do pojedynczych użytkowników — dotyczył także aplikacji powiązanych z pracownikami dużych organizacji.
- 35 578 aplikacji było publicznie dostępnych
- Ekspozycja objęła dane firmowe, osobowe i medyczne
- W części przypadków ujawniono hasła zapisane jawnym tekstem
- Istotnym wektorem rozpoznania okazały się dane pasywnego DNS
Kontekst / historia
Funkcja budowania aplikacji w Grok pozwala generować działające aplikacje na podstawie opisu tekstowego. Po opublikowaniu każda aplikacja otrzymuje osobny subdomenowy adres w domenie grok.me. W praktyce oznacza to szybkie przejście od pomysłu do wdrożenia, często bez udziału administratorów, procesu przeglądu bezpieczeństwa czy zatwierdzenia architektonicznego.
Według opisu badaczy to właśnie model dystrybucji oparty o indywidualne subdomeny stał się jednym z głównych wektorów ekspozycji. choćby jeżeli adres aplikacji nie jest łatwy do odgadnięcia, jego użycie powoduje powstanie śladu w infrastrukturze DNS. W rezultacie subdomeny mogą zostać odnalezione w pasywnych zbiorach DNS i następnie zweryfikowane z poziomu publicznego internetu.
Sama koncepcja aplikacji publikowanej jednym kliknięciem nie jest nowa, jednak incydent wokół Grok pokazuje skalę problemu w środowiskach AI-native, gdzie aplikacje powstają szybko, często ad hoc, i mogą zawierać dane znacznie bardziej wrażliwe niż początkowo zakładano.
Analiza techniczna
Z technicznego punktu widzenia problem składa się z kilku warstw. Pierwsza dotyczy modelu publikacji. W analizowanym scenariuszu opublikowana aplikacja otrzymywała publicznie osiągalny adres, a w badanym wariancie konta opcja szerokiego udostępnienia była domyślnie zaznaczona podczas procesu publikowania. To tworzyło wysokie ryzyko błędu użytkownika, szczególnie gdy aplikacja była traktowana jako tymczasowe narzędzie wewnętrzne.
Druga warstwa to identyfikowalność zasobów. Ponieważ każda aplikacja działała pod osobną subdomeną, samo jej otwarcie generowało zapytanie DNS. Dane tego typu mogą być agregowane przez operatorów pasywnego DNS i przeszukiwane według wzorca. Oznacza to, iż ukrycie aplikacji wyłącznie przez nieprzekazywanie linku nie stanowi realnego mechanizmu bezpieczeństwa.
Trzecia warstwa dotyczy logiki autoryzacji. Badacze opisali testowe aplikacje zbudowane w Grok. W jednej z nich brak logowania powodował, iż każdy użytkownik mógł nie tylko przeglądać, ale również modyfikować dane zapisane w aplikacji. W drugiej generator dodał mechanizm logowania przez zewnętrznych dostawców tożsamości, jednak logika kontroli członkostwa została zaimplementowana błędnie. W efekcie konto spoza organizacji mogło uzyskać dostęp do danych oraz wykonywać operacje modyfikujące.
Czwarta warstwa to ekspozycja danych po stronie klienta. W jednym z opisanych przypadków kod ładowany przez przeglądarkę miał zawierać konta użytkowników wraz z hasłami zapisanymi jawnym tekstem. Taki błąd oznacza naruszenie podstawowych zasad bezpiecznego projektowania aplikacji: sekrety nie powinny trafiać do kodu front-end, a hasła nie powinny być przechowywane ani dystrybuowane w postaci niezaszyfrowanej.
Konsekwencje / ryzyko
Skutki takiej ekspozycji są wielowymiarowe. Po pierwsze, dochodzi do naruszenia poufności danych firmowych, co może obejmować plany onboardingu, dane handlowe, materiały ofertowe, mapy kont klientów czy raporty operacyjne. Po drugie, ujawnienie danych osobowych i medycznych może prowadzić do poważnych konsekwencji regulacyjnych, prawnych i reputacyjnych.
Po trzecie, błędna autoryzacja otwiera drogę nie tylko do odczytu, ale również do modyfikacji lub usuwania danych. To zmienia charakter incydentu z pasywnego wycieku informacji w aktywne naruszenie integralności systemu. W praktyce może to oznaczać sabotaż danych operacyjnych, manipulację listami klientów, zmianę rekordów kadrowych lub usunięcie istotnych wpisów.
Po czwarte, ujawnienie haseł w kodzie może stać się punktem wyjścia do dalszej kompromitacji środowiska. o ile użytkownicy stosowali te same lub podobne dane logowania w innych systemach, incydent może prowadzić do eskalacji ataku, przejęcia kont oraz ruchu bocznego w organizacji.
Szczególnie istotne jest to, iż problem nie wynika wyłącznie z pojedynczego błędu konfiguracyjnego. To kombinacja architektury publikacji, niewłaściwych ustawień domyślnych, słabej walidacji dostępu oraz braku dojrzałych kontroli secure-by-default.
Rekomendacje
Organizacje powinny potraktować ten incydent jako sygnał ostrzegawczy dotyczący całego segmentu AI app builders. W pierwszej kolejności należy zidentyfikować, które zespoły korzystają z generatorów aplikacji AI i jakie dane są przez nie przetwarzane. Dotyczy to nie tylko Grok, ale również innych platform umożliwiających szybkie publikowanie aplikacji webowych.
- przeprowadzić inwentaryzację aplikacji tworzonych poza standardowym procesem SDLC,
- sprawdzić publicznie dostępne subdomeny powiązane z wykorzystywanymi platformami AI,
- zweryfikować ustawienia publikacji i wymusić zasadę najmniejszych uprawnień,
- testować autoryzację nie tylko pod kątem logowania, ale również rzeczywistej kontroli członkostwa i ról,
- analizować zasoby front-end pod kątem obecności sekretów, tokenów, kluczy API i danych osobowych,
- wycofać z publikacji aplikacje bez właściciela biznesowego lub technicznego,
- wdrożyć polityki DLP oraz monitorowanie ekspozycji danych w usługach generowanych przez AI,
- rozszerzyć program AppSec o ocenę rozwiązań no-code, low-code i AI-generated apps.
Z perspektywy dostawców platform dobrym kierunkiem byłoby ustawienie prywatności jako opcji domyślnej, ograniczenie publikacji do domen organizacyjnych, stosowanie trudniejszych do korelacji mechanizmów adresowania oraz automatyczne ostrzeganie użytkownika, gdy aplikacja zawiera bazę danych, dane wrażliwe lub mechanizmy logowania wymagające poprawnej listy uprawnionych użytkowników.
Podsumowanie
Incydent związany z aplikacjami tworzonymi w Grok pokazuje, iż automatyzacja developmentu przez AI nie eliminuje klasycznych problemów bezpieczeństwa — wręcz może je zwielokrotniać. Publiczna ekspozycja tysięcy aplikacji, możliwość ich odnalezienia przez pasywny DNS, błędy w logice autoryzacji oraz przypadki ujawnienia haseł wprost w kodzie dowodzą, iż bezpieczeństwo AI-generated apps musi być traktowane jak pełnoprawny obszar cyberbezpieczeństwa.
Źródła
- The Hacker News — Over 35,000 Grok-Built Apps Exposed Online, Some Leaking Confidential Data and Passwords — https://thehackernews.com/2026/11/over-35000-grok-built-apps-exposed.html
- Claroc Research — GhostShares 2: Grok Apps Exposed xAI’s Business Secrets and People’s Private Data — https://blog.claroc.io/ghostshares-grok-build-apps/
- SpaceXSI — Grok Build on web and mobile — https://x.ai/news/grok-build-for-everyone
