OpenAI puściło AI na kod jądra Linuksa. Efekt: 948 unikalnych dziur do przejęcia roota

Do niedawna testowanie modeli AI w kontekście programowania sprowadzało się głównie do sprawdzania, czy potrafią napisać działającą funkcję, poprawić drobny błąd albo wychwycić podatność w niewielkim wycinku kodu. OpenAI zaprezentowało jednak eksperyment zupełnie innej skali. Firma opracowała wieloetapowy, w znacznej mierze samodzielnie działający system do wyszukiwania podatności i wypuściła go na jądro Linuksa.

Efekty trudno nazwać komfortowymi dla tych, którzy uważali poszukiwanie poważnych luk za rzemiosło odporne na automatyzację. System zbadał 2,8 mln linii kodu, wytypował 2308 podejrzanych miejsc, dynamicznie potwierdził 1724 z nich, a finalnie doprowadził do powstania 948 unikalnych przypadków lokalnego podniesienia uprawnień wraz z działającymi exploitami. Mowa o błędach, które pozwalają użytkownikowi z ograniczonymi prawami dostępu wspiąć się do poziomu roota.

To nie był eksperyment na jakimś uproszczonym, testowym systemie stworzonym pod potrzeby AI. Celem stał się realny Linux – fundament, na którym opiera się ogromna część dzisiejszej infrastruktury komputerowej.

AI przejrzała tylko 7 proc. jądra Linuksa

Warto najpierw uświadomić sobie rozmiar tego przedsięwzięcia. Jądro Linuksa to ponad 40 mln linii kodu, które trafiają m.in. do urządzeń z Androidem, infrastruktury chmurowej czy superkomputerów używanych przez miliardy ludzi na świecie. Powierzchnia potencjalnego ataku jest ogromna – obejmuje wywołania systemowe, obsługę sieci, systemy plików oraz sterowniki. OpenAI nie zdecydowało się jednak na przegląd całego repozytorium linijka po linijce. Najpierw trzeba było znaleźć miejsca, w które w ogóle warto się wgłębiać.

Tę rolę pełniły agenty określone jako Scouci, które przeszukiwały katalogi i pliki pod kątem bezpieczeństwa oraz dostępności dla użytkownika o niskich uprawnieniach. Udało im się wskazać 5034 cele obejmujące łącznie około 2,8 mln linii, czyli zaledwie 7 proc. całej bazy kodu jądra. Ten etap kosztował 3426 dol. w kredytach API. Dopiero w kolejnym kroku do akcji wkroczyły agenty analityczne, które w ciągu 12 godzin, po odrzuceniu duplikatów, wygenerowały 2308 potencjalnych odkryć. Ten fragment eksperymentu pochłonął 316 549 dol. kosztów API. I właśnie tutaj zaczyna się najciekawszy wątek całej historii – samo wskazanie podejrzanego kodu nie jest równoznaczne z potwierdzeniem realnej podatności.

Nie wystarczyło powiedzieć: „tu chyba jest dziura”

To jeden z kluczowych elementów publikacji OpenAI. Model nie poprzestał na statycznej analizie i wyrzuceniu tysięcy raportów do ręcznej weryfikacji. Kolejnym krokiem była dynamiczna walidacja wyników. Agent tworzył proof of concept i próbował odtworzyć problem na izolowanej maszynie wirtualnej z jądrem wyposażonym w Kernel Address Sanitizer. Analizował zachowanie programu i logi systemowe, po czym dopracowywał swój PoC – aż do skutecznego odtworzenia błędu lub wyczerpania limitu przewidzianego na daną próbę.

W ciągu 30 godzin udało się potwierdzić 1724 z 2308 wcześniej wskazanych przypadków, czyli około 74,7 proc. kandydatów. Co ciekawe, OpenAI podaje, że jedynie 3,1 proc. pozostałych przypadków wynikało z błędu samego modelu, który zakładał wystąpienie niemożliwego warunku. Reszta nie przeszła walidacji z innych powodów – na przykład wymagała podwyższonych uprawnień albo warunków trudnych do odtworzenia w dostępnym czasie. Sam etap walidacji kosztował 73 330 dol.

To rozróżnienie ma duże znaczenie. Przy automatycznym audycie milionów linii kodu samo wyłapywanie podejrzanych fragmentów to dopiero połowa sukcesu. Gdy narzędzie produkuje górę fałszywych alarmów, koszt i tak przenosi się na ludzi, którzy muszą ją ręcznie przekopać. W tym przypadku system próbował wykonać tę żmudną pracę samodzielnie.

Potem AI przestała tylko szukać błędów

Po wstępnej selekcji zostało 313 kandydatów na wycieki informacji oraz 1238 kandydatów na lokalne podniesienie uprawnień. Do pracy przystąpiły kolejne agenty, testując te przypadki w izolowanych maszynach wirtualnych. OpenAI podkreśla, że środowisko nie zostało celowo osłabione – uwzględniono standardowe zabezpieczenia dystrybucji Linuksa, w tym SMEP, SMAP, KASLR oraz HARDENED_USERCOPY.

W efekcie powstało 291 proof of concept dotyczących wycieków informacji oraz 1169 działających exploitów typu lokalne podniesienie uprawnień. Nie oznacza to jednak 1169 odrębnych luk. Po analizie wariantów i opracowaniu poprawek badacze wyliczyli finalnie 948 unikalnych podatności LPE. To właśnie ta liczba stanowi według OpenAI najważniejszy wynik całego eksperymentu – 948 potencjalnych ścieżek prowadzących od konta zwykłego użytkownika do pełnych uprawnień roota.

Trzeba przy tym zaznaczyć istotne zastrzeżenie: lokalne podniesienie uprawnień nie oznacza magicznego zdalnego włamania przez internet na dowolny komputer z Linuksem. Atakujący musi najpierw mieć możliwość uruchamiania kodu jako użytkownik o niskich uprawnieniach. Dopiero wtedy podatność LPE pozwala mu wspiąć się na poziom roota. To nadal poważna klasa błędów, ale nie jest to równoznaczne ze stwierdzeniem, że AI znalazła 948 sposobów na zdalne przejęcie wszystkich komputerów z Linuksem.

Najdziwniejsze? AI zaczęła wymyślać własne techniki

OpenAI przeanalizowało próbkę 166 exploitów przygotowanych przez agenty. Firma twierdzi, że w tej grupie znalazło się co najmniej 10 nowych technik eksploatacji jądra Linuksa. Pokazano je niezależnym ekspertom od bezpieczeństwa jądra, dla których metody te miały być równie nieznane. Ze względów bezpieczeństwa OpenAI nie ujawniło pełnych szczegółów technicznych tych rozwiązań. To zmienia wymowę całego eksperymentu.

Najprostszy sceptyczny argument wobec AI w bezpieczeństwie brzmiałby tak: modele widziały ogromne ilości kodu i materiałów o cyberbezpieczeństwie, więc po prostu sprawnie odtwarzają znane wcześniej schematy. Jeśli jednak wyniki OpenAI zostaną potwierdzone szerzej, granica zaczyna się przesuwać – system nie tylko rozpoznawał znane strategie, ale według badaczy potrafił dojść także do rozwiązań nowych.

To właśnie ten wątek zasługuje na baczniejszą uwagę niż samo efektowne „948”.

Całość kosztowała ponad 1,2 mln dolarów

Na szczęście nie jesteśmy jeszcze na etapie, w którym ktoś wykupuje miesięczny abonament za kilkadziesiąt złotych i po obiedzie zleca chatbotowi prześwietlenie jądra systemu operacyjnego. Cały eksperyment kosztował 1 213 430 dol. w kredytach API. OpenAI szacuje średni koszt na 1279 dol. za unikalny exploit LPE. Sam etap rozwijania exploitów pochłonął 775 929 dol., z czego 691 tys. dol. przypadło na kandydatów związanych z lokalnym podniesieniem uprawnień. To ogromna suma, dopóki nie zestawimy jej z realnym rynkiem, na którym tego typu podatności mają konkretną wartość.

OpenAI porównuje swój koszt do historycznych nagród za exploity na jądro Linuksa przyznawanych w konkursach Pwn2Own i TyphoonPWN – odpowiednio 20 tys. i 70 tys. dol. Przy czysto hipotetycznym przemnożeniu takich stawek przez 948 exploitów wychodzi od 18,9 do 66,3 mln dol., czyli od około 16 do 55 razy więcej niż wyniósł koszt całego eksperymentu.

Nie znaczy to oczywiście, że OpenAI właśnie wygenerowało sobie kilkadziesiąt milionów dolarów – tak nie działa rynek bug bounty, a sama firma mówi jedynie o hipotetycznej wycenie opartej na wcześniejszych stawkach. Porównanie dobrze pokazuje jednak inną rzecz: ekonomiczny koszt masowego wyszukiwania poważnych błędów przez AI przestaje być absurdalny.

Na kernelCTF wynik również jest mocny

OpenAI przeprowadziło też bardziej ograniczony eksperyment w środowisku opartym na kernelCTF Google, z jądrem o zmniejszonej powierzchni ataku. Tutaj system uzyskał 25 proof of concept związanych z wyciekami informacji oraz 21 exploitów LPE. Cała kampania trwała 112 godzin i kosztowała około 32 936 dol. w kredytach API. Dla porównania – jak podaje OpenAI – w momencie przygotowywania publikacji program kernelCTF zaakceptował w 2026 r. 26 potwierdzonych exploitów 0-day LPE. Gdyby wszystkie 21 odkryć systemu zostało zaakceptowanych, potencjalna wartość nagród wyniosłaby około 1,5 mln dol.

Nie można jednak wyciągać z tego wniosku, że OpenAI zbudowało w pełni samodzielnego robota-hakera, którego wystarczy uruchomić, by otrzymać gotowy stos perfekcyjnych raportów. Człowiek pozostawał ostatnim etapem całego procesu – badacze sprawdzali exploit, proponowaną poprawkę i ocenę wagi problemu, zanim trafiały one do opiekunów projektu. System przygotowywał analizę przyczyny problemu, minimalny PoC powodujący awarię, proponowaną poprawkę i exploit, ale ostateczną weryfikację wykonywał zawsze ekspert. I okazało się, że był naprawdę potrzebny.

We wcześniejszym przebiegu system zgłosił 200 udanych przypadków podniesienia uprawnień. Podczas ręcznej weryfikacji okazało się, że w 20 przypadkach agent faktycznie zdobył roota, ale za pomocą innej, nieznanej wcześniej podatności niż tej, którą miał badać. Cel został więc osiągnięty, tylko inną drogą niż zakładano. OpenAI zmieniło później zasady zadania i dodało niezależną kontrolę sprawdzającą, czy finalny exploit rzeczywiście wykorzystuje przypisaną mu lukę. Trudno o lepszy przykład tego, dlaczego słowo „autonomiczny” w odniesieniu do systemów AI wciąż warto traktować z pewną dozą ostrożności.

AI szuka dziur, ale ma też pomagać je łatać

System nie kończył działania na samym wykryciu problemu – generował też proponowaną poprawkę. Pierwsze próby nie były jednak idealne. Według OpenAI model potrafił stworzyć łatę skutecznie blokującą proof of concept, ale przy okazji zmieniał więcej kodu niż było potrzebne, powodował ryzyko spadku wydajności, odbiegał od konwencji przyjętych w projekcie albo nie sprawdzał dokładnie innych wariantów tej samej podatności. Dopiero kolejne instrukcje i iteracje pozwalały poprawić jakość generowanych łat.

Automatyczne wykrywanie luk bez równie sprawnego mechanizmu ich usuwania mogłoby stać się koszmarem dla opiekunów dużych projektów open source. Zamiast poprawy bezpieczeństwa, ograniczona liczba osób mogłaby zostać zasypana tysiącami raportów wymagających ręcznej analizy. OpenAI zapewnia, że wysłało już setki raportów i proponowanych poprawek dotyczących krytycznych podatności i pracuje nad przekazywaniem kolejnych.

Tempo reakcji po stronie społeczności również robi wrażenie. W ciągu 10 dni obejmujących skanowanie i analizę 61 podatności LPE zostało już załatanych w głównym drzewie Linuksa, dla 43 istniały poprawki oczekujące na wdrożenie, a 299 kolejnych przypadków było publicznie zgłaszanych i dyskutowanych. Sama OpenAI zaznacza jednak, że nie wszystkie te działania wynikały wyłącznie z jej pracy, wskazując na wkład całej społeczności zajmującej się bezpieczeństwem.

Następna generacja AI znalazła ponad pięć razy więcej

Eksperyment dostarcza jeszcze jednego ciekawego punktu odniesienia dotyczącego tempa rozwoju samych modeli. Pod koniec lipca 2026 r. model GPT-5.6 Sol znalazł i wykorzystał 166 unikalnych podatności LPE przy łącznym koszcie procesu wynoszącym 513 690 dol. W połowie października nowszy, jeszcze niewydany model dedykowany cyberbezpieczeństwu znalazł ich już 948, przy koszcie 1 213 430 dol. W obu przypadkach skanowana była aktualna w danym momencie gałąź master jądra Linuksa.

To ponad pięciokrotny wzrost liczby nowo wykrytych LPE, mimo że między skanami kod był przez kilka miesięcy dalej poprawiany. OpenAI wyciąga z tego dość niepokojący wniosek: wcześniejszy audyt wcale nie oznacza, że nie ma już czego szukać. Mocniejszy model potrafi dostrzec problemy, które przeoczyła poprzednia generacja. Jeśli ten trend się utrzyma, bezpieczeństwo dużych projektów może zacząć przypominać nieustający pojedynek kolejnych generacji modeli z tym samym kodem.

To dobra i zła wiadomość jednocześnie

W publikacji OpenAI naturalnie dominuje perspektywa obrońców. Firma argumentuje, że automatyzacja wykrywania i łatania podatności może pozwolić deweloperom zabezpieczać oprogramowanie szybciej, niż napastnicy są w stanie wykorzystywać jego błędy. Eksperyment rzeczywiście pokazuje, dlaczego taki scenariusz warto traktować poważnie. Problem w tym, że te same liczby można odczytać dokładnie na odwrót.

Jeśli wyszukiwanie podatności, ich dynamiczna walidacja oraz przygotowywanie działających exploitów stają się procesami możliwymi do zautomatyzowania na dużą skalę, to technologia nie usuwa asymetrii między obrońcą a napastnikiem – zmienia jej ekonomię.

Kwota 1,2 mln dol. jest absurdalnie wysoka dla przeciętnego użytkownika. Dla dużej korporacji technologicznej, służb państwowych czy innych dobrze finansowanych podmiotów nie jest już kosztem nie do pomyślenia. Co więcej, OpenAI zaznacza, że w eksperymencie skupiało się głównie na pomiarze możliwości modelu, a nie na optymalizacji kosztów, i traktuje podane wydatki raczej jako górną granicę, spodziewając się, że odpowiednia optymalizacja środowiska mogłaby je wyraźnie obniżyć. Dlatego liczba 948 robi wrażenie, ale wcale nie jest tu najważniejsza.

Najważniejsza jest zmiana skali. Badanie bezpieczeństwa oprogramowania, które tradycyjnie wymagało długotrwałej pracy wysoko wykwalifikowanych specjalistów, zaczyna dawać się zamknąć w powtarzalnym procesie: wybierz wartościowe fragmenty kodu, przeskanuj je, odtwórz problem, oceń możliwość jego wykorzystania, przygotuj poprawkę i przekaż wynik człowiekowi do weryfikacji. Dokładnie taki pięcioetapowy proces zbudowało OpenAI.

Linux okazał się przy tym wyjątkowo trudnym poligonem doświadczalnym. Ma dziesiątki milionów linii kodu, ogromne znaczenie dla całej branży i liczną społeczność ekspertów od bezpieczeństwa, którzy od lat przeglądają jego źródła. Mimo to nowy system i tak znalazł setki unikalnych sposobów na lokalne zdobycie roota.

Nie oznacza to, że Linux nagle stał się niebezpiecznym systemem, ani że 948 podatności grzecznie czekało na kogokolwiek uzbrojonego w ChatGPT. Oznacza jednak coś znacznie bardziej znaczącego: minęła epoka, w której można było zakładać, że sama skala i złożoność kodu wystarczą, by uchronić go przed bardzo głębokim, seryjnym audytem. Dziś taki system można poprosić o kolejną iterację. I następną. A po premierze mocniejszego modelu – zacząć cały audyt od zera.