Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
OpenAI usunęło dwie istotne podatności bezpieczeństwa dotyczące swoich narzędzi opartych na sztucznej inteligencji. Pierwsza luka umożliwiała niejawny wyciek danych z rozmów prowadzonych w ChatGPT, w tym treści wiadomości i przesyłanych plików, z pominięciem standardowych mechanizmów ochronnych. Druga dotyczyła usługi Codex i mogła prowadzić do przejęcia tokenów GitHub na skutek błędu typu command injection.
Sprawa pokazuje, że nowoczesne platformy AI nie są już wyłącznie interfejsami do generowania odpowiedzi. Coraz częściej pełnią rolę środowisk wykonawczych dla kodu, analizy danych i automatyzacji, a to znacząco zwiększa powierzchnię ataku.
W skrócie
Według ujawnionych informacji badacze z Check Point odkryli w ChatGPT lukę zero-day pozwalającą na wynoszenie wrażliwych danych bez wiedzy użytkownika. Mechanizm miał wykorzystywać ukryty kanał komunikacji oparty na DNS w środowisku Linux używanym przez funkcje analizy danych i wykonywania kodu. OpenAI wdrożyło poprawkę 20 lutego 2026 roku i nie odnotowano dowodów na aktywne wykorzystanie błędu w rzeczywistych atakach.
Niezależnie od tego BeyondTrust ujawnił krytyczną podatność w Codex. Problem wynikał z niewystarczającej sanityzacji nazwy gałęzi GitHub podczas tworzenia zadań, co umożliwiało wstrzyknięcie poleceń do kontenera agenta i w konsekwencji kradzież tokenów dostępowych GitHub. Poprawka została wdrożona 5 lutego 2026 roku.
Kontekst / historia
Oba incydenty wpisują się w szerszy trend związany z bezpieczeństwem agentów AI i platform wykonujących działania w imieniu użytkownika. W praktyce oznacza to przesunięcie granicy zaufania: system nie tylko interpretuje polecenia, ale może również uruchamiać kod, przetwarzać pliki, korzystać z tokenów dostępowych i komunikować się z usługami zewnętrznymi.
W takim modelu tradycyjne zabezpieczenia, takie jak blokowanie klasycznych połączeń wychodzących czy filtrowanie odpowiedzi modelu, nie zawsze są wystarczające. Jeżeli w tle działają słabiej kontrolowane kanały komunikacji albo backendy przyjmują nieprawidłowo walidowane dane wejściowe, możliwe staje się obejście zabezpieczeń logicznych bez wyraźnych alertów po stronie użytkownika.
Analiza techniczna
W przypadku ChatGPT problem wynikał z możliwości wykorzystania bocznego kanału komunikacyjnego dostępnego w środowisku Linux, w którym uruchamiane są zadania związane z analizą danych i wykonywaniem kodu. Zamiast klasycznej transmisji danych atak mógł kodować informacje w zapytaniach DNS. Taki mechanizm pozwala dzielić dane na fragmenty i umieszczać je w nazwach domen lub subdomen, a następnie odczytywać po stronie kontrolowanej przez atakującego.
Z perspektywy architektury bezpieczeństwa to szczególnie niebezpieczny scenariusz, ponieważ część warstw kontrolnych mogła zakładać brak możliwości bezpośredniego transferu danych na zewnątrz. Jeśli jednak runtime nadal mógł generować zapytania DNS, ruch ten nie musiał być traktowany jak standardowa eksfiltracja wymagająca ostrzeżenia lub zgody użytkownika. W praktyce pojedynczy złośliwy prompt albo specjalnie przygotowany niestandardowy agent mógł inicjować proces wycieku danych niemal niewidoczny z poziomu interfejsu.
Opis techniczny wskazuje również, że ten sam kanał mógł potencjalnie służyć do uzyskania zdalnej interakcji z runtime’em Linux i wykonywania poleceń. Oznacza to, że zagrożenie nie ograniczało się wyłącznie do biernego wycieku treści konwersacji, ale obejmowało także możliwość aktywnego oddziaływania na środowisko uruchomieniowe.
Druga luka, dotycząca Codex, miała charakter command injection. Podatność była związana z parametrem nazwy gałęzi GitHub przekazywanym podczas tworzenia zadania przez backend API. Jeżeli wejście nie zostało odpowiednio oczyszczone, możliwe było przemycenie poleceń systemowych wykonywanych wewnątrz kontenera agenta. W takim scenariuszu atakujący mógł doprowadzić do ujawnienia tokenu GitHub użytkownika, którego Codex używał do autoryzacji, a następnie wykorzystać go do dalszego dostępu do repozytoriów.
Tego typu błąd jest szczególnie groźny w środowiskach współdzielonych i zautomatyzowanych przepływach pracy. Jeśli agent AI uczestniczy w code review, obsłudze pull requestów albo pracuje na wspólnym repozytorium, przejęcie tokenu może umożliwić ruch boczny, odczyt i modyfikację kodu, a nawet trwałe osadzenie złośliwych zmian w pipeline’ach deweloperskich.
Konsekwencje / ryzyko
Najważniejszym skutkiem pierwszej podatności jest utrata poufności danych przekazywanych do systemu AI. Mogą to być informacje biznesowe, fragmenty kodu źródłowego, dane klientów, dokumenty wewnętrzne, a także dane osobowe przesyłane do analizy. Szczególnie niebezpieczny jest scenariusz, w którym użytkownik nie otrzymuje żadnego jednoznacznego sygnału, że dane opuszczają zaufane środowisko.
W przypadku Codex ryzyko obejmuje nie tylko ujawnienie poświadczeń, ale również naruszenie procesu wytwarzania oprogramowania. Token GitHub z odpowiednimi uprawnieniami może otworzyć drogę do kradzieży własności intelektualnej, modyfikacji kodu, sabotażu buildów, kompromitacji sekretów przechowywanych w repozytorium oraz eskalacji do innych systemów zintegrowanych z platformą deweloperską.
Z punktu widzenia organizacji oba przypadki pokazują, że narzędzia AI należy traktować jak uprzywilejowane komponenty infrastruktury. Jeżeli mają dostęp do danych wrażliwych, repozytoriów, środowisk chmurowych i procesów CI/CD, ich kompromitacja może mieć skutki porównywalne z naruszeniem kluczowych systemów administracyjnych.
Rekomendacje
Organizacje powinny wdrożyć dodatkową warstwę kontroli bezpieczeństwa dla narzędzi AI, zamiast polegać wyłącznie na natywnych mechanizmach dostawcy. W praktyce oznacza to monitorowanie ruchu sieciowego związanego z runtime’ami AI, w tym nietypowych wzorców DNS, kontrolę dostępu do danych przesyłanych do modeli oraz inspekcję działań wykonywanych przez agentów.
Konieczne jest także ograniczanie uprawnień zgodnie z zasadą najmniejszych uprawnień. Tokeny używane przez agentów kodujących powinny mieć możliwie wąski zakres, krótki czas życia oraz separację między projektami. Warto wdrożyć mechanizmy rotacji poświadczeń, dodatkową autoryzację dla operacji wysokiego ryzyka oraz segmentację repozytoriów i środowisk wykonawczych.
- blokowanie lub filtrowanie nieautoryzowanych niestandardowych agentów i rozszerzeń,
- traktowanie prompt injection jako realnego wektora ataku,
- walidacja i sanityzacja wszystkich danych wejściowych trafiających do backendów obsługujących agentów,
- rejestrowanie działań wykonywanych przez AI w kontenerach i pipeline’ach,
- regularne przeglądy uprawnień nadawanych integracjom z GitHub i innymi systemami deweloperskimi.
Z perspektywy użytkowników końcowych kluczowa pozostaje ostrożność wobec promptów obiecujących ukryte funkcje, odblokowanie dodatkowych możliwości lub nietypową optymalizację działania narzędzia. W środowisku firmowym warto również ograniczać możliwość przesyłania do chatbotów danych, które nie zostały wcześniej sklasyfikowane pod kątem poufności.
Podsumowanie
Załatane przez OpenAI podatności pokazują, że wraz z rozwojem agentów AI rośnie znaczenie klasycznych zagadnień bezpieczeństwa aplikacyjnego: izolacji środowisk, kontroli kanałów komunikacji, sanityzacji wejścia i ochrony poświadczeń. Przypadek ChatGPT ujawnia ryzyko ukrytej eksfiltracji danych przez kanały boczne, natomiast luka w Codex podkreśla, że agenci programistyczni stają się atrakcyjnym celem ze względu na dostęp do kodu i uprzywilejowanych tokenów.
Dla przedsiębiorstw najważniejszy wniosek jest prosty: AI nie może być traktowane jako zaufana czarna skrzynka. Narzędzia tego typu wymagają takiego samego poziomu nadzoru, twardych kontroli i modelowania zagrożeń jak każdy inny krytyczny element nowoczesnej infrastruktury IT.
Źródła
- https://thehackernews.com/2026/03/openai-patches-chatgpt-data.html
- https://openai.com/
- https://research.checkpoint.com/
- https://www.beyondtrust.com/