Pierwszy zero-day napisany przez AI. Google przechwycił atak, zanim wystartował

Google ogłosił, że po raz pierwszy w historii wykrył i powstrzymał exploit zero-day stworzony z pomocą sztucznej inteligencji. Atak miał być przeprowadzony na masową skalę i obejść dwuskładnikowe uwierzytelnianie w popularnym narzędziu administracyjnym open source.

Raport Google Threat Intelligence Group z 11 maja 2026 roku to nie kolejna techniczna ciekawostka z konferencji. To moment, w którym branża cyberbezpieczeństwa musi powiedzieć głośno coś, o czym dotąd mówiło się półszeptem. Ofensywne wykorzystanie dużych modeli językowych przestało być teorią.

Po czym poznać, że exploit pisała maszyna

GTIG nie podaje ani nazwy zaatakowanego narzędzia, ani konkretnej grupy przestępczej. Wiadomo tyle, że chodzi o powszechnie używaną, webową platformę administracyjną o otwartym kodzie, a sami napastnicy mają w swoim dorobku, jak ujął to John Hultquist z GTIG, „strong record of high-profile incidents and mass exploitation / udokumentowaną historię głośnych incydentów i masowej eksploatacji podatności”.

Najciekawsze jest to, jak Google rozpoznał ślad sztucznej inteligencji w kodzie. Analitycy przyjrzeli się skryptowi w Pythonie i znaleźli tropy, które po prostu nie pasowały do tego, jak piszą ludzie:

• nadmiar edukacyjnych docstringów wyjaśniających, co robi każdy fragment, jakby autor tłumaczył samego siebie egzaminatorowi
• „halucynowany” CVSS score, czyli wymyślona, nieistniejąca w żadnej oficjalnej bazie ocena krytyczności podatności
• czysta, podręcznikowa struktura zgodna z konwencjami, które dominują w danych treningowych modeli językowych
• dopracowane menu pomocy i schludna klasa kolorów ANSI, typowe dla kodu generowanego przez LLM, a nie pisanego pod presją w piwnicy

Hultquist nie owija w bawełnę. „There’s a misconception that the AI vulnerability race is imminent. The reality is that it’s already begun / Istnieje błędne przekonanie, że wyścig zbrojeń AI w obszarze podatności dopiero nadchodzi. Prawda jest taka, że już się zaczął”.

Sama podatność też mówi coś istotnego. To nie był banalny błąd typu buffer overflow, jakie dobrze wyłapują fuzzery. Deweloperzy zaszyli w kodzie założenie zaufania, które stało w sprzeczności z logiką uwierzytelniania w aplikacji. Klasyczny błąd semantyczny, na poziomie wysokiego rozumowania o systemie. I właśnie w wykrywaniu takich rzeczy duże modele językowe okazują się dziś nieprzyzwoicie skuteczne.

Komu zawdzięczamy ten exploit

Google wprost zaznacza, że nie chodziło o Gemini. Firma odpiera oskarżenie, zanim ktokolwiek je sformułuje. Nie wymienia też z nazwy Mythosa od Anthropic, choć The Verge przypomina, że ten model trafił niedawno na świecznik w dyskusji o ofensywnych zastosowaniach AI w cyberbezpieczeństwie.

Co dokładnie zrobili napastnicy, pozostaje niejasne. GTIG twierdzi z „dużą pewnością”, że model AI był używany w sposób znaczący na wszystkich etapach prac, ale nie potwierdza jeszcze, czy to AI samo znalazło podatność, czy tylko pomogło napisać działający exploit po wskazaniu jej przez człowieka.

Sprawa jest poważniejsza niż sam incydent. Przez lata pocieszaliśmy się, że napastnicy używają AI głównie do pisania lepszych maili phishingowych po angielsku. Ten przypadek pokazuje, że jesteśmy gdzie indziej. LLM-y zaczynają wykrywać błędy semantyczne, czyli klasę luk, którą tradycyjne narzędzia statyczne omijały szerokim łukiem. To zła wiadomość dla każdego dostawcy oprogramowania, który liczył, że jego logika biznesowa jest zbyt złożona, by ktoś chciało mu się ją analizować ręcznie.

Z drugiej strony nie wpadałbym w panikę. To, że Google wykrył ten atak i go zatrzymał, dowodzi, że obrońcy też mają teraz AI. Big Sleep z lipca zeszłego roku to ten sam zestaw narzędzi, tylko po drugiej stronie barykady. Pytanie, które naprawdę warto sobie zadać, brzmi inaczej. Po której stronie ekonomia tego wyścigu daje większy zwrot? Bo jeśli koszt znalezienia luki AI spada szybciej niż koszt jej załatania, to mamy problem strukturalny, którego nie rozwiążą kolejne konferencje branżowe.

Niepokoi mnie też jedna rzecz w komunikacji Google. Brak nazwy narzędzia, brak nazwy grupy. Rozumiem responsible disclosure, ale dla społeczności open source, której odpowiedzialność za bezpieczeństwo i tak rozkłada się na garstkę nieopłacanych maintainerów, taka anonimowość bywa zabójcza. Inni operatorzy podobnych narzędzi powinni mieć szansę sprawdzić, czy nie mają u siebie analogicznego błędu.

Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl

Persona-driven jailbreak i hodowanie exploitów w laboratorium

GTIG opisuje też szerszy trend, który najlepiej oddaje, w którym kierunku to wszystko zmierza. Napastnicy nie próbują już prosić modelu wprost o napisanie złośliwego kodu, bo wiedzą, że dostaną odmowę. Stosują tak zwany persona-driven jailbreaking, czyli każą modelowi wcielić się w rolę eksperta od bezpieczeństwa, badacza akademickiego czy uczestnika zawodów capture-the-flag. W tej masce model staje się znacznie bardziej skłonny do współpracy.

Chińska grupa UNC2814 próbowała w ten sposób analizować firmware urządzeń TP-Link i protokół OFTP. Inni napastnicy karmili modele całymi repozytoriami danych o znanych podatnościach (Google wspomina o eksperymentach z biblioteką WooYun zawierającą ponad pięć tysięcy realnych przypadków z lat 2010 to 2016), żeby model „uczył się w kontekście” myśleć jak doświadczony pentester.

Pojawia się też OpenClaw. Według raportu Google obserwuje „an interest in refining AI-generated payloads within controlled settings to increase exploit reliability prior to deployment / zainteresowanie dopracowywaniem payloadów generowanych przez AI w kontrolowanych środowiskach w celu zwiększenia ich niezawodności przed wdrożeniem”. Mówiąc po ludzku, exploity są hodowane jak rośliny w szklarni, zanim trafią do ataku.

Nie tylko ten jeden incydent

Listopadowy raport GTIG z 2025 roku dał już zapowiedź tego, co dziś widzimy. Wtedy mowa była o malware PROMPTSTEAL używanym przez rosyjską APT28 przeciwko Ukrainie, który w czasie działania odpytywał model Qwen2.5-Coder hostowany na Hugging Face, żeby generować polecenia na bieżąco, zamiast nosić je w sobie na sztywno. I o PROMPTFLUX, droperze, który prosił Gemini o przepisanie własnego kodu co godzinę, żeby uciec sygnaturom antywirusów.

Tamten raport pokazał, jak AI wchodzi w fazę wykonawczą złośliwego oprogramowania. Dzisiejszy pokazuje, że AI wchodzi w fazę projektowania ataku. Różnica jest fundamentalna.

Warto pamiętać o jeszcze jednym wątku, który Google przemyca w tle. AI staje się też celem ataków. GTIG zauważa, że napastnicy coraz częściej biorą na cel „the integrated components that grant AI systems their utility / komponenty integracyjne, które dają systemom AI ich użyteczność”, a więc autonomiczne skille, łączniki z zewnętrznymi danymi, wtyczki. Wszystko to, co sprawia, że agent AI jest czymś więcej niż czatem.

Co to znaczy dla Polski i Europy

Dla polskich firm, które masowo używają open source’owych paneli administracyjnych, baz danych i bibliotek, ten incydent jest sygnałem ostrzegawczym. Reguła „patchuj, gdy będzie wiadomo, że coś groźnego krąży” przestaje działać, jeśli okno między znalezieniem podatności a jej masową eksploatacją skraca się do dni albo godzin.

Z punktu widzenia europejskich regulacji to też ciekawy moment. AI Act traktuje modele ogólnego przeznaczenia, ale kwestia odpowiedzialności za to, co modele robią w rękach przestępców, w praktyce dopiero się klaruje. Google ostrożnie zaznacza, że to nie Gemini, że asetynękły zostały wyłączone. Ale jutro może to być model open source, którego nikt nie wyłączy, bo nie ma jak.

Hultquist ma rację w jednym. Dla każdego zero-day, który da się prześledzić wstecz do AI, jest pewnie wiele takich, których nie wykryjemy nigdy.