Już sam opis całej historii brzmi jak scenariusz technicznego thrillera: badacze bezpieczeństwa odkrywają podatność, która prowadzi ich przez pozornie zwykły system obrazów aż do realnego przejęcia kont pracowniczych w OpenAI. Najciekawsze jest jednak to, że cała sprawa przypadkowo nawiązuje do starego komiksu xkcd, którego żartobliwy podpis z 2020 roku dziś wygląda jak niepokojąco trafna przepowiednia.
Od komiksu do prawdziwego incydentu
Wspomniany komiks xkcd przedstawiał współczesną infrastrukturę cyfrową jako konstrukcję opartą na jednym, kruchym elemencie, którego nikt nie docenia, dopóki nie dojdzie do awarii. W podpisie pod obrazkiem Randall Munroe żartował, że pewnego dnia ImageMagick „w końcu padnie na dobre”, a ludzie będą w pośpiechu składać cywilizację z gruzów.
Dopiero później okazało się, że to właśnie ImageMagick znalazł się na ścieżce prowadzącej do luki wykorzystanej przeciwko OpenAI. Zbieżność jest na tyle uderzająca, że łatwo odnieść wrażenie, iż komiks zażartował zbyt celnie, dotykając miejsca, które rzeczywiście okazało się newralgiczne.
Jak wyglądał łańcuch podatności
Cały atak nie opierał się na jednym błędzie, lecz na kilku elementach połączonych w jeden skuteczny łańcuch. Forum społeczności OpenAI działało na platformie Discourse, a ta przy obsłudze niektórych obrazów korzystała z narzędzia FastImage.
Problem polegał na tym, że FastImage nie radził sobie z formatem HEIF, więc przekazywał zadanie dalej do ImageMagick. Dopiero tam uruchamiany był komponent libheif, który rzeczywiście dekodował obraz i zawierał podatność typu heap overflow.
W praktyce ImageMagick nie był głównym celem, ale pełnił rolę bramy. To właśnie ta warstwa pośrednia sprawiła, że zwykłe przetwarzanie pliku graficznego mogło otworzyć drogę do znacznie poważniejszego incydentu.
To jeden z tych przypadków, które pokazują, jak łatwo zaufanie do popularnej biblioteki może zamienić się w realne ryzyko. W bezpieczeństwie najbardziej zdradliwe bywają właśnie rzeczy uznawane za rutynowe i oczywiste. Dlatego łańcuch zależności trzeba analizować tak samo uważnie jak sam kod aplikacji.
Jak luka z forum przełożyła się na przejęcie kont
Według opisu badaczy, podatność w libheif była dostępna w wersji dostarczonej przez Debiana i wcześniej została naprawiona, ale bez odpowiedniego oznaczenia jako zagrożenie bezpieczeństwa. To wystarczyło, by stała się praktycznym punktem wejścia.
Następnie badacze połączyli tę lukę z błędem w konfiguracji OpenAI dotyczącym SSO, czyli logowania jednokrotnego. W efekcie osoba posiadająca konto społecznościowe i logująca się przez forum mogła w określonych warunkach uzyskać dostęp do zasobów związanych z ChatGPT i Codexem.
To już nie była tylko teoretyczna podatność. Chodziło o realną możliwość wejścia do wewnętrznych zasobów, w tym do firmowego GitHuba OpenAI, gdzie zespół wykonał demonstracyjny, nieszkodliwy pull request, a następnie zgłosił całą sprawę twórcom systemu.
Five Eyes ostrzega przed wykorzystywaniem AI do cyberataków. To dobry kontekst do zrozumienia, jak szybko narzędzia oparte na AI zaczynają wpływać na skalę i tempo operacji ofensywnych.
Reakcja OpenAI i zabezpieczenia po fakcie
OpenAI zareagowało stosunkowo szybko i załatało problem po około 14 godzinach. Zespół badaczy otrzymał również nagrodę w ramach bug bounty w wysokości 6500 dolarów.
Z kolei Discourse oceniło sam błąd związaną z obrazami jako poważny, przyznając mu 8,8 w skali CVSS. Następnie dodano dodatkową warstwę ochrony wokół przetwarzania obrazów, aby ograniczyć ryzyko podobnych sytuacji w przyszłości.
To dobry przykład klasycznej zasady bezpieczeństwa: nawet jeśli pojedyncza podatność wydaje się „tylko” problemem technicznym, w połączeniu z innymi słabościami może dać atakującemu dostęp znacznie dalej, niż sugerowałby sam początek łańcucha.
Dlaczego ten problem nie dotyczy wyłącznie OpenAI
Najważniejszy wniosek z tej historii jest taki, że podobny mechanizm może dotyczyć wielu innych serwisów i produktów. Te same dekodery libheif oraz libde265 pojawiają się nie tylko w OpenAI, ale też w narzędziach i środowiskach takich jak Slack, Meta, GitHub Enterprise, Ruby on Rails czy frameworki Node.js.
Badacze wskazali również na popularne systemy budowania i dystrybucji oprogramowania, w tym Next.js, Astro i Gatsby. Oznacza to, że problem nie jest niszowy ani ograniczony do jednego, konkretnego wdrożenia.
W praktyce taki błąd może być dziedziczony przez wiele warstw oprogramowania, często bez świadomości końcowego administratora. To właśnie sprawia, że podatności w bibliotekach multimedialnych bywają tak groźne.
Sztuczna inteligencja po stronie atakujących
Równie interesujący jest sposób, w jaki zespół badawczy przygotował exploit. Według relacji użyli modeli Anthropic Claude, najpierw Opus 4.8, a później Opus 5, i zbudowali działający łańcuch w zaledwie dwa miesiące.
Cały proces kosztował ich mniej niż 3000 dolarów w tokenach, a w zespole były tylko trzy osoby. To pokazuje, jak bardzo AI może zwiększyć tempo pracy nawet niewielkiej grupy specjalistów.
Jednocześnie nie był to przypadek, w którym model „sam” wykonał wszystko za ludzi. Badacze musieli przedstawiać swoje środowisko testowe jako zadanie typu capture the flag, żeby przekonać chatbota do współpracy. Mimo to efekt końcowy pozostaje wyraźny: asystent AI może znacząco przyspieszyć tworzenie złożonych exploitów.
Dlaczego ta historia wybrzmiewa dziś tak mocno
W czasach, gdy AI coraz częściej trafia do cyberbezpieczeństwa, takie przypadki działają jak ostrzeżenie. Pokazują, że wielkie systemy są często zbudowane z małych, pozornie zwyczajnych komponentów, które same w sobie wydają się niegroźne.
To także przypomnienie, że bezpieczeństwo nie kończy się na jednym patchu. Liczy się cały łańcuch zależności, konfiguracja usług, sposób uwierzytelniania i to, jak szybko organizacja reaguje na nowo odkryte problemy.
A komiks xkcd, który miał być tylko żartem o kruchych fundamentach internetu, dziś brzmi jak trafne podsumowanie tej sytuacji. Nie dlatego, że przewidział konkretny atak, ale dlatego, że bardzo dobrze uchwycił zasadę, według której działa współczesna infrastruktura: czasem wszystko opiera się na jednym, niedocenionym elemencie.
Świetnie, że znowu rozmawiają o xkcd. Zawsze mówiłem, że to, co na pierwszy rzut oka wygląda na żart, może mieć poważne konsekwencje. Dobrze, że w tym przypadku wystarczająco szybko to naprawili. Ciekawe, jakie inne luki mogą być nieodkryte.
Serio? Jak to możliwe, że taki klasyczny błąd jak heap overflow nadal nie został załatwiony? To świadczy o najgorszym zarządzaniu bezpieczeństwem w wielkich firmach, takich jak OpenAI. Niby wszystko super szybkie, a tu błąd czekał na naprawę.
To była tylko kwestia czasu, aż coś takiego się zdarzy. Każde oprogramowanie ma swoją kruchość, a ImageMagick to klasyczny przykład. Bez dobrej dokumentacji i patchy czekamy tylko na rozwalenie całej infrastruktury. Ale kto by się tym przejmował…
Facet z xkcd ma nosa do przewidywań. Nie wiem, jak oni w ogóle wpuszczają tego całego libheif do produkcji bez odpowiednich testów. Powinno się bawić w automatyzację testów wszędzie, a nie tylko przy większych projektach.
Hm, ciekawe czy inne usługi, które używają tych samych bibliotek, są równie podatne. Musiałbym zweryfikować, bo nie chciałbym się narażać. W końcu bezpieczeństwo nie kończy się na jednym patchu, jak słusznie zauważono w artykule.
Co z tego, że załatali po 14 godzinach? Czy taka luka nie powinna być rozwiązana znacznie wcześniej? Widać, że cały ekosystem bazuje na zaufaniu, które łatwo można złamać. To przestroga dla innych firm.