Exploit zero-day stworzony przez AI: co to znaczy dla firm

Exploit zero-day stworzony przez AI to złośliwy kod wykorzystujący nieznaną wcześniej lukę w oprogramowaniu, wygenerowany lub współtworzony przez duży model językowy — bez klasycznego procesu ręcznego badania i programowania. Dla firm oznacza to przede wszystkim drastyczny spadek kosztu i czasu przygotowania ataku oraz wyższe wymagania dotyczące zarządzania podatnościami, audytów bezpieczeństwa i zgodności z regulacjami takimi jak RODO czy AI Act.

Co potwierdził Google i dlaczego to przełomowy przypadek

11 maja 2026 roku Google Threat Intelligence Group (GTIG) ujawniło pierwszy publicznie opisany i potwierdzony przypadek exploita zero-day stworzonego przy istotnym udziale modelu AI. Celem był popularny, webowy panel administracyjny oparty na otwartym oprogramowaniu. Exploit napisany w Pythonie pozwalał ominąć uwierzytelnianie dwuskładnikowe (2FA), o ile atakujący dysponował poprawnym loginem i hasłem użytkownika.

Atak został wykryty i zatrzymany we współpracy Google z opiekunem projektu — luka załatana, zanim doszło do masowej eksploatacji. Analiza kodu ujawniła cechy charakterystyczne dla generacji przez duży model językowy (LLM): nadmiarowe, „edukacyjne" komentarze w kodzie, podręcznikową strukturę modułów Pythona oraz zmyślone (zahalucynowane) oceny punktowe CVSS. GTIG podkreśliło, że exploit nie był generowany przez Google Gemini, lecz z dużą pewnością powstał przy użyciu innego modelu AI na etapie odkrycia i „uzbrojenia" podatności.

To pierwszy przypadek, w którym wiarygodny podmiot defensywny potwierdził, że za odkryciem luki i przygotowaniem kodu ataku stał model AI. Wcześniejsze doniesienia o AI w cyberatakach dotyczyły wspomagania pracy hakerów (phishing, rekonesans), nie zaś samodzielnego tworzenia exploita zero-day od podstaw. Szczegółowy raport GTIG dostępny jest na DevStock Academy.

Mechanizm działania: jak LLM tworzy exploit zero-day

Klasyczne tworzenie exploita zero-day wymagało wysokich kompetencji technicznych, tygodni lub miesięcy badań i manualnego testowania kodu w różnych środowiskach. Duże modele językowe zmieniają ten rachunek w kilku wymiarach:

• Rekonesans i analiza podatności — LLM potrafi błyskawicznie przetworzyć publiczne bazy CVE, dokumentację oprogramowania i repozytoria kodu, wskazując potencjalne słabe punkty.
• Generowanie proof-of-concept — model syntezuje kod ataku na podstawie opisu podatności, iteracyjnie poprawiając go do uzyskania działającej wersji.
• Skalowanie prób — atakujący wysyłają tysiące zapytań w pętli, łącząc wyniki wielu sesji i walidując działanie exploita automatycznie. Grupy powiązane z Koreą Północną (APT45) stosowały właśnie tę metodę do rekursywnej analizy CVE.
• Adaptacja do środowisk — AI może przerabiać exploit na warianty omijające konkretne sygnatury AV lub EDR.

Ograniczeniem LLM są halucynacje — modele tworzą błędne metadane, niepoprawne fragmenty kodu lub zmyślone punktacje ryzyka. Jednak atakujący kompensują to masową liczbą prób i automatyczną walidacją. Koszt ataku spada, tempo rośnie, presja na obrońców zwiększa się. Więcej o automatyzacji zagrożeń AI można przeczytać w dziale cyberbezpieczeństwo AI Puls.

Co exploit zero-day stworzony przez AI oznacza dla polskich firm

Skutki tej zmiany dla polskich przedsiębiorstw można podzielić na trzy obszary: operacyjny, prawny i regulacyjny.

Obszar operacyjny: więcej ataków, mniejszy koszt, szybsze warianty

Polskie analizy branżowe wskazują wprost na „zero-day za 20 dolarów" — koszt stworzenia exploita spadł o rząd wielkości względem klasycznych kampanii. Oznacza to:

• Więcej ataków na MŚP — bariera wejścia dla grup przestępczych jest niższa; tanie modele AI, gotowe szablony promptów i skrypty w Pythonie są dostępne powszechnie.
• Ryzyko łańcucha dostaw — uderzenie w open-source'owe komponenty (tak jak w opisywanym przypadku Google) łatwo propaguje się do polskich integratorów, software house'ów i klientów z sektora publicznego.
• Szybsze warianty omijające zabezpieczenia — AI generuje kolejne iteracje exploita, które mogą być nierozpoznawane przez systemy EDR lub sygnatury antywirusowe przez wiele godzin od pierwszego ataku.
• Obejście 2FA jako precedens — klasyczne uwierzytelnianie dwuskładnikowe, dotąd uznawane za solidną barierę, zostało ominięte przez LLM-generowany skrypt. Oznacza to konieczność wdrożenia dodatkowych warstw kontroli dostępu.

Szczegółowe informacje o polskich narzędziach do zarządzania podatnościami dostępne są w sekcji narzędzia AI.

Obszar prawny: RODO i obowiązki po incydencie

Udany exploit zero-day prowadzący do naruszenia danych osobowych uruchamia obowiązki wynikające z art. 33–34 RODO: zgłoszenie do Urzędu Ochrony Danych Osobowych (UODO) w ciągu 72 godzin oraz powiadomienie osób fizycznych, jeśli naruszenie stwarza wysokie ryzyko dla ich praw i wolności. Kary administracyjne sięgają 20 mln EUR lub 4% globalnego rocznego obrotu.

Z perspektywy RODO istotna jest należyta staranność: firma, która ignoruje znane mechanizmy zarządzania podatnościami — regularne patching, testy penetracyjne, oceny skutków dla ochrony danych (DPIA) przy wdrożeniach AI — ponosi wyższe ryzyko sankcji. DPIA jest szczególnie wymagana, gdy firma wdraża systemy oparte na AI do przetwarzania danych osobowych na dużą skalę.

Obszar regulacyjny: AI Act i KRiBSI

AI Act — rozporządzenie UE o sztucznej inteligencji — wchodzi w pełne zastosowanie od sierpnia 2026 roku. Nakłada obowiązki na dostawców i wdrażających systemy AI wysokiego ryzyka, w tym wymagania dotyczące cyberbezpieczeństwa samych modeli AI. Dla firm korzystających z AI do analizy zagrożeń lub automatycznego patchingu oznacza to konieczność dokumentowania systemów, prowadzenia rejestrów i przeprowadzania ocen zgodności.

W Polsce nadzór nad stosowaniem AI Act ma sprawować KRiBSI (Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji) — nowy krajowy regulator AI. Komisja będzie uprawniona do weryfikacji, czy firmy stosujące systemy AI spełniają wymogi bezpieczeństwa określone w rozporządzeniu. Dla polskich organizacji oznacza to konieczność monitorowania wytycznych KRiBSI równolegle z przepisami unijnymi. Firmy poszukujące wsparcia w zakresie zgodności mogą skorzystać z polskiej platformy zgodności AI EU Act.

Jak rozpoznać exploit stworzony przez AI i co wdrożyć w obronie

Identyfikacja exploita generowanego przez LLM opiera się na kilku sygnałach w samym kodzie i telemetrii:

• Nadmiarowe komentarze edukacyjne — LLM domyślnie wyjaśnia każdy krok kodu, co jest rzadkie w złośliwym oprogramowaniu pisanym ręcznie przez doświadczonych atakujących.
• Podręcznikowa struktura modułów — „czyste", dobrze sformatowane funkcje z opisowymi nazwami zmiennych, charakterystyczne dla modeli językowych.
• Halucynacyjne metadane — zmyślone lub błędne oceny CVSS, niepoprawne odwołania do numerów CVE, fikcyjne nazwy bibliotek.
• Masowe, powtarzalne zapytania sieciowe — w telemetrii sieci widoczne jako tysiące identycznych lub podobnych żądań w krótkim czasie (sygnatura procesu iteracyjnej walidacji).

Na poziomie organizacyjnym działania obronne obejmują kilka priorytetów:

• Skrócenie okna patchingu — AI skraca czas od odkrycia podatności do gotowego exploita; firmy muszą skrócić cykl aktualizacji krytycznych komponentów open-source do minimum.
• Dodatkowe warstwy uwierzytelniania — 2FA to nadal wartościowa warstwa, ale nie wystarczająca sama w sobie; warto rozważyć klucze sprzętowe (FIDO2) lub uwierzytelnianie oparte na ryzyku (risk-based authentication).
• Monitorowanie anomalii w kodzie i telemetrii — wdrożenie reguł SIEM wyłapujących charakterystyczne wzorce kodu LLM oraz masowe, powtarzalne zapytania.
• Audyt komponentów open-source — inwentaryzacja bibliotek i zależności (SBOM — Software Bill of Materials) pozwala szybko identyfikować zagrożone komponenty po ujawnieniu podatności.
• Szkolenia dla zespołów bezpieczeństwa — uwzględnienie scenariuszy AI-generated threats w programach awareness i ćwiczeniach red team.

Więcej o strategiach ochrony przed zagrożeniami AI dostępnych jest w sekcji edukacyjnej AI Puls oraz w dziale AI w biznesie.

Perspektywa na najbliższe miesiące

GTIG ostrzegło wprost: opisany przypadek prawdopodobnie nie jest jedynym — podobnych exploitów mogło być więcej i część pozostaje nieujawniona. Trend jest wyraźny: grupy powiązane z Chinami i Koreą Północną aktywnie testują LLM do wyszukiwania podatności, generowania proof-of-concept i walidacji ataków. Automatyzacja tego procesu będzie się pogłębiać w miarę, jak modele AI stają się tańsze i bardziej dostępne.

Dla polskich firm — niezależnie od wielkości — wniosek jest jednoznaczny: zarządzanie podatnościami musi być traktowane jako proces ciągły, a nie jednorazowy audyt. Wymogi AI Act, RODO oraz nadzór KRiBSI tworzą ramy regulacyjne, które wymuszają ten kierunek. Organizacje, które dostosują procedury teraz, będą lepiej przygotowane zarówno na ataki, jak i na kontrole regulacyjne.