Wysyłasz komuś link do rozmowy z AI. Nie ma go w wyszukiwarce, adres zawiera losowy identyfikator, więc wygląda na taki, którego nikt obcy nie znajdzie. A jednak badacze odnajdują ponad 6800 takich adresów jednym wyszukiwaniem w danych DNS. Bez zgadywania identyfikatorów, bez włamania na serwer i bez konta w usłudze. Tak właśnie wyglądał problem z udostępnianiem rozmów przez Meta Muse.

18 października 2026 r. zespół Claroc opublikował raport „GhostShares”, a 20 października dopisał do niego istotny rozwój: Meta wstrzymała funkcję udostępniania rozmów. To historia o AI, ale jej najważniejszy mechanizm nie ma nic wspólnego z halucynacjami modelu ani atakiem prompt injection. Problem tkwił w sposobie tworzenia adresów internetowych i w myleniu trudno dostępnego linku z prawdziwą kontrolą dostępu.

Ponad 6800 adresów. Ale nie 6800 potwierdzonych wycieków

Muse, osobisty agent AI firmy Meta, został uruchomiony 8 września 2026 r. Pozwalał między innymi tworzyć i udostępniać materiały powstałe podczas rozmowy. Użytkownik mógł poprosić agenta o link, a osoba posiadająca ten adres mogła otworzyć udostępnioną stronę bez logowania.

WebsiteGarage / Usługi

Sprawdź nasze usługi.

Badacze Claroc zajrzeli do jednej komercyjnej bazy passive DNS, która gromadzi historycznie zaobserwowane nazwy domen. Po odfiltrowaniu przypadkowych wyników skanowania znaleźli ponad 6800 nazw hostów powiązanych z udostępnionymi materiałami Muse. Każda taka nazwa odpowiadała jednej stronie udostępnienia. Zespół otworzył tylko kilkaset pozycji. Większość okazała się zwyczajna lub nieszkodliwa, ale w części były dane, których trudno oczekiwać na ogólnodostępnej stronie.

To ważne rozróżnienie: 6800 oznacza znalezione adresy, a nie liczbę poufnych dokumentów, poszkodowanych osób czy potwierdzonych naruszeń danych osobowych. Nie wiemy również, ile wszystkich udostępnień Muse istniało poza obserwowaną bazą. Samo trafienie adresu do zbioru passive DNS nie oznacza, że ktoś już wykorzystał jego zawartość.

Co można było przeczytać po otwarciu znalezionych linków?

Claroc opisał sześć kategorii bardziej wrażliwych materiałów. Znalazły się wśród nich wewnętrzna analiza przychodów firmy przeznaczona dla jej prezesa, wniosek o kredyt małej działalności, plan sprzedaży nieruchomości, notatka o alercie bankowym z fragmentem numeru rachunku oraz całoroczny kalendarz urlopów pracowników. Inna strona dotyczyła poufnych przygotowań do rozmowy rekrutacyjnej na wysokim szczeblu w firmie rozwijającej zaawansowaną AI.

Nie chodzi wyłącznie o same kwoty czy nazwiska. Czasem najbardziej interesującą informacją jest to, że określone osoby mają odbyć niepubliczne spotkanie, nawet gdy reszta dokumentu wygląda na zbiór ogólnodostępnych faktów. Taka wiedza może ułatwić podszywanie się pod uczestników rozmowy, oszustwa lub bardzo wiarygodny phishing.

Autorzy raportu świadomie nie opublikowali rzeczywistych adresów, tytułów ani danych pozwalających zidentyfikować poszkodowanych. My również ich nie przytaczamy. Przy analizowaniu błędu prywatności nie trzeba dorzucać własnej cegiełki do rozpowszechniania cudzych informacji.

Jak to możliwe, że losowy identyfikator niczego nie ukrył?

Zacznijmy od krótkiego wyjaśnienia. DNS jest systemem, dzięki któremu przeglądarka ustala, gdzie znaleźć serwer obsługujący daną nazwę, na przykład www.example.com. W zapytaniu DNS pojawia się nazwa hosta, a nie pełna treść odwiedzanej strony ani cała ścieżka URL.

W Muse tytuł udostępnionej rozmowy oraz losowy identyfikator stawały się częścią nazwy hosta, pod domeną przeznaczoną do serwowania tych treści. Wyglądało to w uproszczeniu tak: raport-firmowy-losowyidentyfikator.example.com. To wymyślony przykład, nie adres rzeczywistej rozmowy. Sama nazwa podpowiadała, co może kryć strona, a identyfikator znajdował się dokładnie w tej części adresu, którą widzi DNS.

Kiedy ktoś otwierał udostępnioną stronę, jego urządzenie musiało rozwiązać nazwę hosta. Niektóre usługi monitorujące ruch DNS zapisują obserwowane odpowiedzi, a potem udostępniają historyczne dane do wyszukiwania. To właśnie passive DNS. Nie oznacza to, że wszystkie zapytania DNS każdego internauty są publikowane w jednej globalnej bazie. Wystarczy jednak, że konkretną nazwę zaobserwuje dostawca, którego zbiór można przeszukać.

W badanym przypadku osoba przeszukująca dane passive DNS otrzymywała cały host, razem z losowym identyfikatorem. Nie musiała go łamać ani odgadywać. Badacze mogli następnie dotrzeć do odpowiadającej mu strony udostępnienia, która otwierała się bez uwierzytelnienia. Losowy ciąg znaków chroni tylko wtedy, gdy naprawdę pozostaje nieznany.

Dlaczego robots.txt nie pomógł?

Muse ograniczał indeksowanie udostępnionych materiałów przez wyszukiwarki za pomocą pliku robots.txt. To przydatne narzędzie do zarządzania indeksowaniem i ruchem robotów, ale nie jest zamkiem w drzwiach. Nie sprawdza tożsamości odwiedzającego i nie zabrania mu otwarcia strony, której adres już zna.

Co istotne, Claroc wcale nie musiał pytać np. Google o rozmowy Muse. Badacze skorzystali z danych DNS, poza mechanizmem indeksowania stron. Wskazali również, że w serwisie urlscan.io istniało ponad 75 zapisanych skanów stron z udostępnieniami Muse. To dodatkowa droga, przez którą publiczne adresy mogą stać się łatwiejsze do odnalezienia.

Podobnie działa znacznik noindex: może powstrzymać wyszukiwarkę przed wyświetleniem strony w wynikach, ale nie ogranicza dostępu do samej treści. Dokumentacja Google Search Central wprost rozróżnia ograniczanie indeksowania od ochrony poufnych materiałów. Jeżeli coś ma być dostępne wyłącznie dla uprawnionych osób, potrzebna jest kontrola dostępu, a nie prośba skierowana do robotów.

To był incydent bezpieczeństwa, ale nie włamanie do systemów Meta

W tym przypadku użytkownicy świadomie używali funkcji udostępniania, a aplikacja tworzyła publiczną stronę. Problem polegał na tym, że strony te były znacznie łatwiejsze do masowego odnalezienia, niż mógł sugerować nieprzewidywalny adres. Autorzy raportu nie wykryli potrzeby przełamywania logowania, wykorzystywania podatności serwera czy przejmowania kont.

To jednocześnie realna ekspozycja części informacji i ograniczony zakres ustaleń. Badacze otworzyli w normalnej przeglądarce poufne materiały bez posiadania linku od autora i bez logowania. Nie przedstawili jednak dowodów, że przestępcy korzystali z tych adresów lub że dane zostały wykorzystane do oszustw. Nie należy więc nazywać tego potwierdzoną kampanią kradzieży danych.

Daty mają znaczenie: zgłoszenie, publikacja i reakcja Meta

  • 7-8 października 2026: Claroc przeprowadził główne sprawdzenie dostępności próbek i zawartości udostępnionych stron.
  • 8 października: badacze zgłosili problem do programu zgłaszania błędów Meta.
  • 18 października: opublikowano pierwszą wersję raportu GhostShares.
  • 20 października: po pytaniach redakcji Ars Technica Meta poinformowała o wstrzymaniu udostępniania i przeglądzie sposobu, w jaki można odnajdywać linki. Tego dnia Claroc ponownie sprawdził 40 wcześniej dostępnych stron i żadnej nie udało się otworzyć.

W odpowiedzi udzielonej Ars Technica Meta potwierdziła wstrzymanie funkcji na czas oceny zgłoszenia. Na 21 października nie oznacza to jeszcze opublikowania pełnego raportu z przyczyn incydentu ani trwałego wdrożenia nowego modelu udostępniania. Wynik próby na 40 adresach pokazuje, że kontrolowane przez Meta strony przestały się w tych przypadkach otwierać, a nie że cała historia adresów zniknęła.

Nazwy hostów, w tym zawarte w nich tytuły rozmów, nadal pozostawały w historycznych danych passive DNS. To kolejny ważny szczegół: wycofanie dostępu do treści nie usuwa automatycznie wszystkich informacji, które już opuściły system.

To dotyczy nie tylko asystentów AI. Podobnie działają podglądy projektów, linki do faktur, oferty PDF, pliki w chmurze, strony stagingowe i materiały udostępniane klientowi. Zanim uznasz adres za bezpieczny, warto odpowiedzieć na kilka konkretnych pytań.

  • Kto może otworzyć stronę? Czy potrzebne jest logowanie, uprawnienie do konkretnego dokumentu albo hasło, czy wystarczy sam link?
  • Co zdradza adres? Czy w nazwie hosta, ścieżce lub tytule nie ma nazw klientów, kwot, informacji o projektach czy innych danych, które nie powinny być publiczne?
  • Czy link można unieważnić? Udostępnienie powinno mieć możliwość cofnięcia dostępu, a przy wrażliwych treściach również rozsądny termin wygaśnięcia.
  • Co się stanie po wylogowaniu? Otwórz link w prywatnym oknie przeglądarki albo z innego konta. To prosty test zachowania mechanizmu, chociaż nie zastępuje audytu bezpieczeństwa.
  • Gdzie jeszcze może trafić adres? Sprawdź, czy link nie jest rozpowszechniany przez analitykę, osadzone skrypty, podglądy linków, logi albo usługi skanujące strony.
  • Czy ktoś faktycznie potrzebuje całej rozmowy? Czasem zamiast udostępniać zapis obejmujący dane źródłowe, lepiej wysłać krótkie podsumowanie bez informacji poufnych.

A jeśli firma już udostępniła wrażliwe informacje przez AI?

Najpierw trzeba ustalić, co rzeczywiście zostało udostępnione, komu i jak długo materiał pozostawał dostępny. Jeżeli platforma pozwala usunąć publiczne udostępnienie lub cofnąć link, warto z tego skorzystać. Przy hasłach, tokenach API i kluczach dostępu samo usunięcie strony nie wystarcza: należy zmienić odpowiednie dane uwierzytelniające.

Jeśli materiał zawierał dane klientów albo pracowników, trzeba ocenić zakres i skutki ujawnienia zgodnie z przyjętymi w firmie procedurami ochrony danych. Nie każde odkrycie publicznego adresu oznacza automatycznie ten sam obowiązek prawny. Znaczenie mają rodzaj danych, ryzyko dla osób i faktyczne okoliczności udostępnienia. W razie potrzeby należy zaangażować osobę odpowiedzialną za ochronę danych lub prawnika.

Przy projektowaniu nowego mechanizmu udostępniania warto potraktować uprawnienia jako część funkcji, nie jako kosmetyczny dodatek na końcu. W WordPressie nawet niewielki moduł przekazywania materiałów klientowi powinien jasno rozróżniać treści publiczne od prywatnych i kontrolować, kto może je otwierać. Gdy chodzi o konkretną, ograniczoną funkcję w istniejącym serwisie, jest to temat do zaplanowania w ramach [link WordPress Development Sprint]. Bardziej rozbudowane portale czy systemy z wieloma rolami wymagają już osobnego zakresu projektu.

Najważniejsza lekcja nie dotyczy wyłącznie AI

Meta Muse nie zostało tutaj opisane jako agent, który sam postanowił ujawnić cudze dane. Wykonało polecenie udostępnienia, a architektura tej funkcji sprawiła, że publiczne adresy były łatwiejsze do odnalezienia. To klasyczny błąd projektowy w nowym opakowaniu: system myli brak reklamy strony z jej prywatnością.

Dlatego przy każdej nowej funkcji „Udostępnij” warto zapytać nie tylko, jak szybko wygeneruje link, ale przede wszystkim, kto może go znaleźć, co da się z niego wyczytać i jak odebrać dostęp. O bezpieczeństwie nie decyduje długość losowego identyfikatora, lecz cały proces kontroli informacji.

Źródła i granice ustaleń

Stan informacji na 21 października 2026 r. Ponad 6800 to liczba nazw hostów znalezionych w jednym zbiorze passive DNS, nie liczba zweryfikowanych wycieków poufnych dokumentów. Dostęp do części wrażliwych materiałów potwierdzono podczas zwykłego przeglądania, ale nie ma dowodu na przestępcze wykorzystanie ich zawartości. Meta wstrzymała funkcję udostępniania; historyczne nazwy hostów pozostawały w zewnętrznych zbiorach.