OpenAI opublikowało szczegółowe oświadczenie dotyczące incydentu, który od kilku dni elektryzował społeczność deweloperów. Sprawa Axios compromise OpenAI sprowadza się do jednego pytania: czy złośliwy kod, który przedostał się do popularnej biblioteki JavaScript, zdołał naruszyć bezpieczeństwo aplikacji ChatGPT na macOS? Odpowiedź jest bardziej złożona, niż mogłoby się wydawać.
Czym jest atak na łańcuch dostaw i dlaczego Axios znalazł się na celowniku
Atak typu supply chain attack polega na tym, że napastnik nie uderza bezpośrednio w cel końcowy. Zamiast tego atakuje jedno z narzędzi lub komponentów, z których ten cel korzysta. To trochę jak zatrucie studni, z której piją mieszkańcy wioski – nie trzeba wchodzić do każdego domu z osobna.
Axios to jedna z najpopularniejszych bibliotek do obsługi żądań HTTP w ekosystemie Node.js. Korzystają z niej setki tysięcy projektów, od małych startupów po korporacje z listy Fortune 500. Jej pakiet npm pobierany jest miliony razy tygodniowo. Właśnie ta powszechność uczyniła ją atrakcyjnym wektorem ataku.
Według analizy opublikowanej przez Google Cloud Threat Intelligence, za atakiem stoi grupa powiązana z Koreą Północną. Napastnicy zdołali wstrzyknąć złośliwy kod do jednej z wersji pakietu Axios dystrybuowanej przez rejestr npm. Modyfikacja była subtelna – nie zmieniała widocznego zachowania biblioteki, ale pozwalała na eksfiltrację zmiennych środowiskowych i tokenów dostępowych z procesów CI/CD, w których pakiet był wykorzystywany.
Co dokładnie się wydarzyło?
OpenAI korzystało z Axios jako zależności w swoich workflow GitHub Actions – automatycznych procesach budowania, testowania i wydawania oprogramowania. Skompromitowana wersja biblioteki trafiła do pipeline’u odpowiedzialnego za code signing i notarization aplikacji ChatGPT na macOS.
Proces podpisywania kodu to mechanizm, dzięki któremu system operacyjny (w tym przypadku macOS) może zweryfikować, że aplikacja rzeczywiście pochodzi od deklarowanego wydawcy i nie została zmodyfikowana po kompilacji. Notarization od Apple to dodatkowa warstwa – Apple skanuje aplikację pod kątem złośliwego oprogramowania przed nadaniem jej cyfrowego stempla zaufania.
Złośliwy kod w Axios miał dostęp do materiałów kryptograficznych wykorzystywanych w tych procesach. Mówiąc prościej: napastnik potencjalnie mógł uzyskać dane potrzebne do podpisania dowolnego oprogramowania tak, jakby pochodziło od ChatGPT. To poważne zagrożenie, nawet jeśli – jak podkreśla sama firma – nie znaleziono dowodów na to, że ktokolwiek z tego skorzystał.
Brak dowodów na wyciek danych i modyfikację oprogramowania
OpenAI po wykryciu incydentu przeprowadziło dogłębny audyt. Firma jednoznacznie stwierdziła, że nie znalazła śladów wycieku danych użytkowników ani modyfikacji wydanego oprogramowania. Żadna wersja aplikacji ChatGPT dla macOS, która trafiła do użytkowników, nie zawierała złośliwego kodu.
To ważne rozróżnienie. Dziura dotyczyła infrastruktury budowania, nie samego produktu końcowego.
Mimo to OpenAI potraktowało sprawę z pełną powagą. Samo istnienie ryzyka – nawet niezrealizowanego – wymagało zdecydowanych działań naprawczych. W kwestiach bezpieczeństwa AI i najlepszych praktyk podejście prewencyjne jest jedynym sensownym wyborem.
Rotacja certyfikatów i wymagane aktualizacje
Pierwszym krokiem było natychmiastowe unieważnienie skompromitowanych certyfikatów podpisywania kodu. OpenAI wygenerowało nowe certyfikaty i podpisało nimi aktualne wersje aplikacji. Dla użytkowników oznacza to jedynie konieczność aktualizacji.
Firma wyznaczyła graniczną datę – 8 maja 2026 roku. Po tym terminie starsze wersje aplikacji ChatGPT na macOS, podpisane unieważnionymi certyfikatami, przestaną działać. System operacyjny Apple automatycznie odrzuci je jako niezaufane. To standardowa procedura w przypadku rotacji certyfikatów, ale dla użytkowników, którzy mają wyłączone automatyczne aktualizacje, może stanowić zaskoczenie.
Praktyczna rada jest prosta: sprawdź, czy Twoja wersja ChatGPT na macOS jest aktualna. Jeśli korzystasz z wersji sprzed kwietnia 2026, zaktualizuj ją jak najszybciej. Po 8 maja nie będzie to już kwestia komfortu, lecz konieczności.
Ataki na łańcuchy dostaw
Incydent wpisuje się w rosnącą falę ataków na łańcuchy dostaw w ekosystemie open source. W 2021 roku głośna była sprawa Log4Shell. W 2024 roku kompromitacja xz-utils pokazała, jak cierpliwy napastnik potrafi latami budować zaufanie w społeczności, by w odpowiednim momencie wstrzyknąć backdoora.
Jedną z kluczowych lekcji tego incydentu jest kwestia zarządzania zależnościami w pipeline’ach CI/CD. Wiele projektów odwołuje się do akcji i pakietów za pomocą tak zwanych floating tags – etykiet typu @latest lub @v3, które mogą wskazywać na różne wersje kodu w różnych momentach. To wygodne, ale niebezpieczne.
Bezpieczniejszą praktyką jest pinowanie commitów – odwoływanie się do konkretnego, niezmiennego identyfikatora SHA commitu w repozytorium. Dzięki temu nawet jeśli napastnik podmieni tag, Twój pipeline pobierze dokładnie tę wersję kodu, którą wcześniej zweryfikowałeś. GitHub sam zaleca to podejście w swojej dokumentacji dotyczącej bezpieczeństwa GitHub Actions.
Warto też rozważyć stosowanie narzędzi do weryfikacji integralności pakietów, takich jak npm audit, Sigstore czy SLSA framework. Żadne z nich nie jest panaceum, ale każde dodaje kolejną warstwę ochrony. Temat sztucznej inteligencji w cyberbezpieczeństwie jest coraz istotniejszy właśnie dlatego, że skala i wyrafinowanie ataków rosną szybciej niż zdolność ludzi do ręcznego monitorowania każdej zależności.
Rola państwowych grup hakerskich w atakach na AI
Raport Google Cloud Threat Intelligence wprost wskazuje na powiązania z północnokoreańskim aktorem zagrożeń. Nie jest to odosobniony przypadek – grupy takie jak Lazarus Group od lat atakują infrastrukturę technologiczną, kryptowalutową i finansową na całym świecie. Celowanie w narzędzia wykorzystywane przez firmy rozwijające sztuczną inteligencję to logiczna ewolucja ich taktyki.
Potencjalne zyski z hackowania procesu budowania oprogramowania AI są ogromne. Gdyby napastnikowi udało się podmienić podpisaną aplikację, miliony użytkowników zainstalowałyby złośliwy kod w pełnym zaufaniu. Dlatego właśnie firmy takie jak OpenAI muszą traktować bezpieczeństwo łańcucha dostaw nie jako dodatek do procesu developerskiego, ale jako jego fundament.
