„AI-Driven Cyberattacks”: Jak sztuczna inteligencja zautomatyzowała włamania na strony w 2026 roku i jak się bronić

Jeszcze dwa lata temu atak na stronę internetową wyglądał jak zarzucanie sieci. Botnet skanował setki tysięcy domen w poszukiwaniu jednej, konkretnej, dawno opisanej luki we wtyczce. Jeśli miałeś aktualizacje – sieć przepływała obok Ciebie. Aktualność była tarczą.

W 2026 roku ta tarcza przestała wystarczać. Nie dlatego, że aktualizacje straciły sens, tylko dlatego, że zmienił się przeciwnik. Po drugiej stronie nie stoi już skrypt z listą sygnatur, ale autonomiczny agent oparty na modelu językowym: czyta Twój kod, stawia hipotezy, testuje je, uczy się na własnych błędach i próbuje dalej. Robi to w kilka minut, jednocześnie na tysiącach witryn i bez udziału człowieka.

Poniżej opisujemy, jak taki atak wygląda krok po kroku, dlaczego klasyczna wtyczka zabezpieczająca przestaje go zatrzymywać i co realnie działa – z konkretnymi przykładami z tego roku.

Rok 2026 w liczbach

Skala zjawiska przestała być prognozą i stała się statystyką:

• Ponad połowa ruchu w sieci nie pochodzi od ludzi. Według raportu Imperva (Thales) Bad Bot Report 2026 automaty odpowiadały w 2025 roku za ok. 53% całego ruchu webowego, wobec 51% rok wcześniej. Udział ruchu ludzkiego spadł do 47%.
• Złośliwe boty to już 40% ruchu – wzrost z 37% rok do roku, siódmy rok wzrostu z rzędu.
• Ataki z użyciem AI wzrosły 12,5-krotnie. Średnia dobowa liczba zablokowanych incydentów napędzanych sztuczną inteligencją wzrosła z ok. 2 mln do ok. 25 mln.
• 27% ataków botów celuje bezpośrednio w API – z pominięciem interfejsu, formularzy i całej warstwy, którą projektowano z myślą o człowieku.
• Ok. 5 godzin – tyle średnio mija od publicznego ujawnienia podatności do pierwszych zautomatyzowanych prób jej wykorzystania.
• Ponad 11 tysięcy nowych podatności odkryto w ekosystemie WordPressa w 2025 roku, o ok. 42% więcej niż rok wcześniej. Zdecydowana większość dotyczy wtyczek i motywów, nie rdzenia. Blisko połowa z nich jest wykorzystywalna bez logowania.

Ostatnia liczba jest kluczowa dla zrozumienia reszty tekstu: atakującemu w większości przypadków nie jest potrzebne żadne hasło. Silne hasło i 2FA chronią konto administratora, a nie aplikację.

Jak naprawdę wygląda atak sterowany przez AI

Klasyczny skaner podatności szukał sygnatury: konkretnej wersji konkretnej wtyczki. Agent AI działa jak pentester – tyle że nie potrzebuje snu, kawy ani stawki godzinowej.

1. Rekonesans: bot pozna Twoją stronę lepiej niż Ty

Pierwszy etap to inwentaryzacja. Agent pobiera HTML, parsuje bundle JavaScriptu, wyciąga z niego ścieżki do endpointów REST i GraphQL, czyta nagłówki odpowiedzi, sprawdza /wp-json/, mapy witryny, pliki źródłowe map (source maps), komentarze w kodzie, nazwy klas CSS zdradzające motyw i buildera. Z tego składa profil technologiczny: jaki CMS, jaka wersja PHP, jakie wtyczki, jaki cache, jaki hosting, jakie API płatności.

Ten sam model potrafi następnie przejrzeć publiczne repozytorium GitHub użytej wtyczki, przeanalizować changelog i commity – i wywnioskować, gdzie w kodzie znajduje się słabość, o której nikt jeszcze nie napisał advisory.

2. Autonomiczny fuzzing i łańcuchowanie podatności

Zamiast wysyłać gotowe payloady z bazy, agent generuje zapytania dopasowane do konkretnej architektury. Obserwuje różnice w kodach odpowiedzi, czasach wykonania, długości treści – i modyfikuje kolejną próbę na podstawie poprzedniej.

Najgroźniejsza jest jednak umiejętność łączenia luk w łańcuch. Pojedynczy błąd bywa nieszkodliwy. Dwa błędy, które człowiek analizowałby tygodniami, żeby dostrzec, że razem prowadzą do zdalnego wykonania kodu, model zestawia w kilkanaście minut.

Nie jest to teoria. Google Threat Intelligence Group w swoim AI Threat Tracker za III kwartał 2026 opisał przypadek zbadany przez Mandiant: atakujący, korzystając z asystenta do kodowania i zestawu instrukcji dla agentów, zaplanował, zbudował i wykonał masową kampanię wykradania danych uwierzytelniających w mniej niż sześć godzin. Skompromitowano tysiące poświadczeń podmiotów trzecich. Badacze nazwali to przejściem od pasywnych infostealerów do „ofensywnego zbierania agentowego”.

3. Kod polimorficzny, czyli WAF na sygnaturach zawsze o krok z tyłu

Klasyczna zapora aplikacyjna dopasowuje żądanie do wzorca. Agent AI, dostając odpowiedź 403, nie poddaje się – przeformułowuje atak: zmienia kodowanie znaków, rozbija payload na kilka żądań, podmienia nagłówki, losuje odstępy między pakietami tak, aby rytm ruchu przypominał człowieka przeglądającego sklep, rotuje adresy IP z pul rezydencjalnych.

Skutek jest taki, że filtr oparty wyłącznie na sygnaturach blokuje pierwszą próbę i przepuszcza dziesiątą. Według danych Patchstack z 2026 roku tradycyjne WAF-y zatrzymują zaledwie kilkanaście procent ataków specyficznych dla WordPressa – bo większość z nich to nie „dziwne żądania”, tylko poprawne żądania wysłane w złej kolejności lub do złego endpointu.

4. Phishing 1:1 i kradzież sesji zamiast łamania hasła

Równolegle idzie wektor ludzki, i to on najczęściej okazuje się tańszy. Model zbiera publiczny profil administratora – LinkedIn, stopki maili, wystąpienia, repozytoria, wpisy na forach – i generuje wiadomość, która nawiązuje do jego realnego projektu, realnego klienta i realnego terminu. Bez literówek, w naturalnej polszczyźnie, z odpowiedniego adresu.

Celem coraz rzadziej jest hasło. Celem jest ciasteczko sesji. Atak typu adversary-in-the-middle przepuszcza cały proces logowania przez serwer pośredniczący: ofiara podaje hasło, zatwierdza kod z aplikacji, wchodzi do panelu – a napastnik przechwytuje gotowy token sesji. Dwuskładnikowe uwierzytelnianie oparte na SMS-ie lub kodzie TOTP nie stanowi tu przeszkody, bo zostało poprawnie przejściowo wykonane.

5. Atak na łańcuch dostaw: luka, która przychodzi z aktualizacją

Najbardziej podstępny wariant nie forsuje żadnych drzwi – wchodzi przez te otwarte. Ktoś kupuje pakiet popularnych, ale zaniedbanych wtyczek od zmęczonego dewelopera (transakcje takie odbywają się całkiem jawnie, na giełdach typu Flippa), przejmuje wraz z kodem dostęp do repozytorium i zaufanie kilkuset tysięcy instalacji, a złośliwy kod dostarcza w kolejnej, legalnie podpisanej aktualizacji.

W opisywanym w 2026 roku przypadku przejęcia takiego pakietu backdoor pozostawał w plikach wtyczek przez osiem miesięcy, niezauważony przez automatyczne skanery – wykryła go dopiero analiza manualna. WAF też go nie widział, bo połączenie do serwera C2 wygląda z zewnątrz jak zwykły ruch wychodzący z serwera.

Studium przypadku: WP2Shell, lipiec 2026

Jeśli ktoś potrzebował dowodu, że okno reakcji się zamknęło, dostał go 17 lipca 2026 roku.

Ujawniono wtedy dwie podatności w samym rdzeniu WordPressa: CVE-2026-63030 w obsłudze żądań wsadowych REST API oraz CVE-2026-60137 umożliwiającą SQL Injection w mechanizmie WP_Query. Osobno – nieprzyjemne. Połączone w łańcuch, nazwany WP2Shell – zdalne wykonanie kodu i pełne przejęcie witryny bez logowania, na domyślnej instalacji, bez żadnych dodatkowych wtyczek.

Zagrożone były wersje 6.8.0–6.8.5, 6.9.0–6.9.4 oraz 7.0.0–7.0.1. Poprawki wydano jako 6.8.6, 6.9.5 i 7.0.2, a skalę uznano za na tyle poważną, że tam, gdzie było to możliwe, uruchomiono wymuszone aktualizacje automatyczne. CERT Polska ostrzegał przed masowym wykorzystaniem w ciągu godzin, nie dni.

I to jest w tej historii najistotniejsze. Publiczny kod exploita krążył w sieci w kilka godzin po ujawnieniu. Benjamin Harris z watchTowr zwrócił uwagę, że okno między publikacją a masowym atakiem drastycznie się skróciło właśnie dzięki narzędziom AI, które pozwalają odtworzyć działający exploit z opisu i diffa poprawki w godziny zamiast w dni.

Wniosek praktyczny: harmonogram „aktualizujemy w każdy pierwszy poniedziałek miesiąca” w 2026 roku oznacza średnio kilka tygodni ekspozycji na luki, które są wykorzystywane tego samego dnia.

Dlaczego popularna wtyczka zabezpieczająca już nie wystarcza

Większość serwisów opiera ochronę na jednej z kilku popularnych wtyczek i podstawowym filtrze hostingu współdzielonego. To lepsze niż nic, ale ma trzy strukturalne ograniczenia.

Reaktywność

Bazy sygnatur aktualizują się po tym, jak lukę opisano i zgłoszono. Agent, który znalazł ją samodzielnie w publicznym repozytorium, działa w oknie, w którym sygnatura jeszcze nie istnieje. Przy średnio 30 nowych podatnościach dziennie w samym ekosystemie WordPressa to nie jest wyjątek, tylko norma.

Ślepota na to, co dzieje się już wewnątrz

Wtyczka pilnuje ruchu przychodzącego. Nie widzi, że PHP nawiązuje połączenie wychodzące do nieznanego hosta, że w katalogu uploads pojawił się plik .php, albo że zadanie cron uruchamia kod, którego nie ma w repozytorium. A właśnie tam kończą się dziś skuteczne ataki.

Wtyczka jest częścią atakowanej powierzchni

Każdy dodatkowy komponent to dodatkowy kod z własnymi uprawnieniami, własnymi endpointami REST i własnym harmonogramem łatania. Rozwiązanie zabezpieczające, które działa wewnątrz aplikacji, dzieli los aplikacji – jeśli napastnik uzyska wykonanie kodu, wyłączy je pierwszym poleceniem.

Do tego dochodzi problem czysto biznesowy: obciążenie. Zmasowane, inteligentne skanowanie generuje ruch, który nawet przy zerowej skuteczności potrafi wysycić pulę połączeń bazy danych i położyć sklep w godzinach szczytu. Nieudany atak też kosztuje.

Warstwowa ochrona, która realnie działa w 2026 roku

Nie istnieje jedno narzędzie, które to załatwia. Działa natomiast konsekwentne nakładanie warstw, z których każda kosztuje napastnika czas – a czas jest jedynym zasobem, którego zautomatyzowana kampania nie ma w nadmiarze.

1. WAF behawioralny na brzegu sieci, nie w aplikacji. Filtrowanie oparte na intencji i zachowaniu sesji (tempo, kolejność żądań, spójność nagłówków, reputacja ASN), a nie wyłącznie na treści pojedynczego żądania. Ruch odrzucany zanim dotrze do PHP nie obciąża serwera.
2. Limity i throttling na ścieżkach krytycznych. wp-login.php, xmlrpc.php, REST API, koszyk, wyszukiwarka, formularze. Rate limiting per IP i per sesja plus wyzwanie (challenge) dla ruchu podejrzanego to najtańszy sposób na zdjęcie 90% wolumenu.
3. Hardening środowiska uruchomieniowego. Ograniczenie uprawnień procesu PHP, wyłączenie funkcji systemowych, całkowita blokada wykonywania skryptów w katalogach uploadu, oddzielenie właściciela plików od użytkownika serwera WWW, izolacja kont między witrynami, rygorystyczne nagłówki bezpieczeństwa (CSP, HSTS, X-Frame-Options).
4. 2FA odporne na phishing. Klucze sprzętowe FIDO2 lub passkeys dla kont administracyjnych – w przeciwieństwie do SMS i TOTP nie da się ich przekazać przez serwer pośredniczący, bo są związane kryptograficznie z domeną. Do tego krótszy czas życia sesji i wiązanie jej z adresem oraz odciskiem przeglądarki.
5. Monitoring integralności plików (FIM) i ruchu wychodzącego. Natychmiastowa detekcja każdej nieautoryzowanej zmiany w rdzeniu, motywie i wtyczkach – porównywana z repozytorium wzorcowym, nie z bazą sygnatur. Plus alert na nietypowe połączenia wychodzące, bo to jedyny sygnał, który wyłapuje backdoora z łańcucha dostaw.
6. Dyscyplina zależności. Im mniej wtyczek, tym mniejsza powierzchnia ataku – to najbardziej niedoceniana warstwa bezpieczeństwa w WordPressie. Audyt każdej wtyczki przed instalacją (kiedy ostatnia aktualizacja, kto jest właścicielem, ile otwartych zgłoszeń), usuwanie nieużywanych zamiast dezaktywacji, świadoma decyzja przy zmianie właściciela wtyczki.
7. Kopie zapasowe poza serwerem i przetestowane odtworzenie. Backup, którego nigdy nie przywracano, jest hipotezą, nie zabezpieczeniem. Kopia na tym samym koncie hostingowym co witryna zostanie zaszyfrowana razem z nią.

Mini-audyt: dziesięć pytań, na które musisz znać odpowiedź

Jeśli na którekolwiek z nich odpowiadasz „nie wiem”, masz gotową listę zadań:

• W jakiej wersji rdzenia działa strona i kiedy była aktualizowana ostatnia wtyczka?
• Ile wtyczek jest zainstalowanych, a ile faktycznie używanych?
• Czy w katalogu uploads da się wykonać plik PHP?
• Ilu użytkowników ma rolę administratora i czy każdy z nich nadal pracuje przy tym projekcie?
• Czy administratorzy logują się kluczem sprzętowym, czy kodem z SMS-a?
• Czy REST API i xmlrpc.php są otwarte dla całego świata?
• Kiedy ostatnio ktoś odtworzył kopię zapasową, a nie tylko sprawdził, że się wykonała?
• Gdzie trafiają logi dostępu i czy ktokolwiek na nie patrzy?
• Czy wiesz, jakie połączenia wychodzące nawiązuje Twój serwer?
• Co dokładnie zrobisz w pierwszej godzinie po wykryciu włamania – i kto to zrobi?

Bezpieczeństwo Twojej strony z iql.pl

W iql.pl nie opieramy ochrony na gotowych, powszechnie dostępnych wtyczkach – ich zachowanie jest publicznie znane, a więc możliwe do przewidzenia i obejścia przez zautomatyzowanego przeciwnika. Pracujemy odwrotnie: minimalizujemy liczbę komponentów, a to, czego brakuje, dopisujemy we własnym kodzie, dopasowanym do konkretnego wdrożenia.

Na co to się przekłada w praktyce:

• audyt istniejącej witryny lub sklepu wraz z inwentaryzacją zależności i realną oceną powierzchni ataku,
• dedykowane, ręcznie strojone reguły filtrowania ruchu na brzegu sieci – budowane pod ruch konkretnego serwisu, nie pod średnią statystyczną,
• hardening serwera i środowiska PHP, izolacja kont, polityka nagłówków,
• monitoring integralności plików i ruchu wychodzącego z alertowaniem,
• procedura reakcji na incydent: izolacja, odtworzenie, ustalenie wektora wejścia i domknięcie luki – bo samo przywrócenie kopii bez zamknięcia drzwi oznacza włamanie ponownie w ciągu doby,
• stały nadzór nad aktualizacjami w tempie odpowiadającym realnemu oknu ekspozycji, a nie kalendarzowi.

Chcesz wiedzieć, jak Twoja strona wypada na tle powyższej listy? Napisz do nas – zaczniemy od audytu.

Najczęstsze pytania

Czy sama regularna aktualizacja WordPressa wystarczy?

Jest warunkiem koniecznym, ale nie wystarczającym. Przy średnio pięciu godzinach od ujawnienia luki do pierwszych zautomatyzowanych ataków nawet cotygodniowy cykl aktualizacji zostawia okno ekspozycji. Aktualizacje nie chronią też przed lukami typu zero-day ani przed złośliwym kodem, który przyszedł razem z legalną aktualizacją.

Mam wtyczkę zabezpieczającą i 2FA. Czy to mnie chroni?

Chroni przed atakami sprzed kilku lat i to nadal ma wartość. Nie zatrzyma natomiast podatności wykorzystywanych bez logowania (blisko połowa wszystkich), ataków przechwytujących sesję po poprawnym zalogowaniu ani złośliwego kodu działającego już wewnątrz serwera.

Moja strona jest mała, komu by się chciało?

Nikomu – i właśnie na tym polega problem. Wybór celu nie jest decyzją człowieka, tylko efektem skanowania. Mała firmowa witryna ma dla napastnika konkretną wartość: hosting do wysyłki spamu, miejsce na stronę phishingową pod zaufaną domeną, ruch do przekierowania lub po prostu dane klientów.

Po czym poznać, że strona została przejęta?

Typowe sygnały to nagły spadek widoczności w wyszukiwarce, ostrzeżenia przeglądarki, przekierowania widoczne tylko dla ruchu z Google lub na urządzeniach mobilnych, nowe konta administratorów, nieznane zadania cron, skok obciążenia serwera i pliki zmodyfikowane w dziwnych godzinach. Coraz częściej jednak nie ma żadnych objawów – dobrze ukryty backdoor nie ma interesu w tym, żeby się ujawniać.