Krytyczna luka w linkach udostępnianych w ChatGPT mogła ujawniać prywatne rozmowy

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa ujawnili krytyczną podatność w mechanizmie publicznego udostępniania rozmów ChatGPT. Luka mogła doprowadzić do wykonania złośliwego kodu w kontekście zalogowanej sesji użytkownika, a następnie do odczytu prywatnych konwersacji oraz wykonywania działań w imieniu ofiary.

Problem dotyczył webowej warstwy aplikacji i nie wynikał z jednego klasycznego błędu, lecz z połączenia kilku funkcji, które osobno wyglądały na bezpieczne. To właśnie taki łańcuch zależności stworzył warunki do przejęcia uprawnień sesji w przeglądarce.

W skrócie

• Atak mógł zostać uruchomiony po otwarciu specjalnie przygotowanego publicznego linku do rozmowy.
• Nie było potrzeby instalowania dodatkowego oprogramowania ani korzystania z zewnętrznych narzędzi.
• W najgroźniejszym scenariuszu wystarczało samo otwarcie linku przez zalogowanego użytkownika.
• Możliwe było pobranie listy rozmów, odczyt prywatnych konwersacji oraz wykonywanie operacji dostępnych dla sesji ofiary.
• Podatność zgłoszono 18 października 2026 r., a poprawkę wdrożono 26 października 2026 r.

Kontekst / historia

Incydent pokazuje, że nowoczesne aplikacje AI i usługi SaaS stają się coraz bardziej złożonym środowiskiem wykonawczym. W takich platformach ryzyko nie zawsze wynika z pojedynczej luki typu XSS, lecz z nieoczywistej interakcji między komponentami odpowiedzialnymi za renderowanie treści, izolację kontekstu oraz komunikację między ramkami.

W analizowanym przypadku badacze połączyli dwie funkcje dostępne w obrębie jednej rozmowy: interaktywny wykres oraz podgląd HTML. Producent usługi potwierdził problem, odtworzył scenariusz ataku i wdrożył poprawki po swojej stronie. Według ujawnionych informacji nie potwierdzono aktywnego wykorzystywania tej podatności przed jej usunięciem.

Analiza techniczna

Istota problemu sprowadzała się do przełamania granicy pomiędzy odizolowanym podglądem HTML a główną aplikacją działającą w zaufanym kontekście domeny. Funkcja Preview uruchamiała treści HTML w osobnym środowisku, co było poprawnym założeniem bezpieczeństwa. Jednak w tej samej rozmowie można było osadzić interaktywny wykres wykorzystujący bibliotekę MathLive, która rejestrowała odbiornik komunikatów postMessage w głównym oknie aplikacji.

Kluczowy błąd polegał na niewystarczającej walidacji nadawcy wiadomości. W efekcie niezaufana zawartość działająca w podglądzie mogła wysłać komunikat do głównej strony i przekazać dane zawierające surowy HTML. Taka treść była następnie renderowana po stronie zaufanego dokumentu, co umożliwiało utworzenie nowej ramki bez odpowiedniego sandboxingu.

Nowo utworzony kontekst dziedziczył tożsamość domeny aplikacji, a więc uzyskiwał dostęp do uwierzytelnionej sesji ofiary. W praktyce oznaczało to możliwość wywoływania wewnętrznych interfejsów API jako zalogowany użytkownik. W kontrolowanym scenariuszu badacze pokazali, że możliwe było:

• pobranie listy ostatnich konwersacji,
• odczyt treści prywatnej rozmowy, która nie była wcześniej udostępniona,
• przesłanie wybranych danych na zewnętrzny serwer.

W łańcuchu ataku istotną rolę odegrało także obejście polityki Content Security Policy. Zabezpieczenie blokowało kod inline, ale dopuszczało ładowanie skryptów z wybranych zaufanych źródeł. Badacze wykorzystali ten element jako końcowy etap wykonania JavaScript, podkreślając jednak, że źródłem podatności była przede wszystkim możliwość przeniesienia niezaufanego HTML do głównego dokumentu i utworzenia niesandboxowanej ramki w zaufanym kontekście.

Z technicznego punktu widzenia był to złożony łańcuch obejmujący obejście sandboxa, błędną walidację komunikatów międzykontekstowych oraz wykonanie kodu w przeglądarce w kontekście zaufanej domeny. Skutkiem mogło być pełne przejęcie możliwości webowej sesji użytkownika.

Konsekwencje / ryzyko

Ryzyko związane z tą luką należy ocenić jako bardzo wysokie, ponieważ atakujący mógł działać z uprawnieniami ofiary. Największym zagrożeniem nie była sama manipulacja interfejsem, lecz dostęp do poufnych danych przetwarzanych w rozmowach oraz możliwość wykonywania akcji w ramach aktywnej sesji.

W środowiskach firmowych potencjalne skutki mogły obejmować wyciek wrażliwych promptów, ujawnienie prywatnych rozmów zawierających informacje handlowe lub techniczne, a także nieautoryzowane operacje wykonywane z poziomu legalnie zalogowanego konta. To szczególnie istotne w organizacjach, które wykorzystują narzędzia AI do pracy z danymi operacyjnymi, kodem, analizami lub dokumentacją.

Wektor ataku był przy tym wyjątkowo prosty z perspektywy socjotechniki. Złośliwy link mógł wyglądać jak zwykłe udostępnienie rozmowy i zostać przesłany e-mailem, komunikatorem, systemem zgłoszeń lub przez media społecznościowe. Użytkownik nie musiał pobierać pliku, instalować rozszerzenia ani logować się do fałszywego panelu.

Rekomendacje

Dla użytkowników końcowych kluczowe jest to, że poprawka została wdrożona po stronie dostawcy usługi, więc ręczna aktualizacja nie była wymagana. Mimo to incydent pokazuje, że publiczne linki do narzędzi AI powinny być traktowane jako potencjalny wektor ataku, zwłaszcza w środowiskach biznesowych.

Z perspektywy operacyjnej warto wdrożyć następujące działania:

• ograniczyć otwieranie publicznych linków do rozmów AI z niezweryfikowanych źródeł,
• monitorować wykorzystanie narzędzi AI w środowiskach firmowych,
• traktować treści przesyłane do chatbotów jako dane potencjalnie narażone na ekspozycję,
• stosować separację kont i przeglądarek dla zadań wysokiego ryzyka,
• rozważyć izolację sesji webowych w przeglądarkach korporacyjnych lub środowiskach VDI,
• uwzględniać aplikacje AI w testach bezpieczeństwa, politykach DLP i modelach zagrożeń.

Dla zespołów AppSec i inżynierów bezpieczeństwa ten przypadek przynosi również ważne wnioski projektowe:

• każdy odbiornik postMessage powinien rygorystycznie weryfikować origin oraz źródłowe okno nadawcy,
• niezaufane dane nie powinny trafiać do mechanizmów renderujących HTML bez skutecznej sanitacji,
• dokumenty tworzone dynamicznie powinny pozostawać sandboxowane, jeśli ich treść może być kontrolowana pośrednio przez użytkownika,
• Content Security Policy należy traktować jako warstwę pomocniczą, a nie jedyną ochronę przed wykonaniem kodu.

Podsumowanie

Ujawniona podatność w mechanizmie udostępniania rozmów ChatGPT pokazuje, jak groźne mogą być zależności między pozornie niezależnymi funkcjami aplikacji webowej. Połączenie podglądu HTML, interaktywnego wykresu, błędnie obsłużonej komunikacji międzykontekstowej i niewłaściwego sandboxingu doprowadziło do scenariusza, w którym możliwe było wykonanie kodu w sesji zalogowanego użytkownika.

To ważny sygnał dla dostawców platform AI oraz zespołów bezpieczeństwa: komponenty osadzone, komunikacja między ramkami i mechanizmy renderowania treści muszą być analizowane nie tylko osobno, ale także jako całość. W nowoczesnych aplikacjach największe ryzyko często pojawia się właśnie na styku funkcji, które indywidualnie wydają się bezpieczne.

Źródła

1. A Shared ChatGPT Link Could Run Attacker Code in Your Session and Read Private Chats — https://thehackernews.com/2026/10/a-shared-chatgpt-link-could-run.html
2. Do the Math: How We Took Over ChatGPT Accounts — https://www.parameter.ai/labs/we-found-a-gap-at-openai