Twoja strona firmowa mogła już zostać przejęta — i nic by tego nie zdradzało

Jest sobota rano, strona firmowa ładuje się jak zawsze, formularz kontaktowy działa, sklep przyjmuje zamówienia. Nic nie sygnalizuje problemu. A mimo to ktoś obcy mógł od tygodnia mieć pełny dostęp do bazy danych, hasła administratorów i możliwość dopisania własnego kodu do serwera — bez logowania, bez konta, bez klikania w cokolwiek przez pracownika. Brzmi jak scenariusz z filmu. W przypadku WordPressa, silnika stojącego za mniej więcej połową stron internetowych na świecie, przez kilka dni lipca 2026 roku był to po prostu stan faktyczny.

Skąd się to wzięło

17 lipca zespół WordPress wydał awaryjną łatkę do dwóch podatności w samym rdzeniu systemu — nie we wtyczce, nie w motywie, tylko w kodzie, na którym stoi każda instalacja. To ważne rozróżnienie. Zwykle, kiedy słyszymy o dziurze w WordPressie, chodzi o jakiś dodatek — problem dotyczy wtedy tych, którzy akurat go zainstalowali. Tym razem zagrożona była każda czysta instalacja w podatnej wersji, nawet bez jednej dodatkowej wtyczki.

Błąd nazwano WP2Shell. To połączenie dwóch osobnych luk: nieprawidłowej obsługi zbiorczych żądań w REST API oraz podatności typu SQL injection w mechanizmie zapytań do bazy. Osobno żadna z nich nie byłaby katastrofą. Razem dawały to, co w bezpieczeństwie IT uznaje się za najgorszy możliwy scenariusz — zdalne wykonanie kodu bez żadnego uwierzytelnienia. Innymi słowy: obcy człowiek w internecie, bez hasła i bez konta, mógł przejąć kontrolę nad serwerem.

Dlaczego akurat teraz to boli inaczej

Lukę znaleziono z pomocą modelu AI — to jeden z pierwszych tak głośnych przypadków, gdy sztuczna inteligencja pomogła wykryć krytyczny błąd w rdzeniu tak powszechnego oprogramowania. I to samo narzędzie, które pomaga bronić, pomaga też atakować szybciej. Firma VulnCheck potwierdziła ponad dwadzieścia unikalnych, publicznie dostępnych exploitów zaledwie dwa dni po ujawnieniu luki. Kilka niezależnych firm bezpieczeństwa potwierdziło aktywne ataki w ciągu następnych dni, część z nich wspierała już realne akcje ratunkowe po włamaniach.

To jest właśnie ta zmiana, o której mówią ludzie od bezpieczeństwa od dawna, a która dopiero teraz staje się namacalna dla właściciela zwykłej firmowej strony: okno między ujawnieniem luki a masowym atakiem skurczyło się z dni do godzin. Nie dlatego, że atakujący stali się nagle wybitni. Dlatego, że narzędzia AI potrafią odtworzyć exploit szybciej, niż firma zdąży wysłać komunikat do klientów.

Co to znaczy w praktyce, na trzech przykładach

Pierwszy przypadek: sklep internetowy na WordPressie, właściciel sprawdza tylko, czy zamówienia przychodzą. Strona działa normalnie — przejęta strona rzadko przestaje działać, częściej staje się cichym narzędziem do rozsyłania malware albo phishingu, a właściciel dowiaduje się o tym miesiące później, zwykle od klienta albo od Google, które oznaczy stronę jako niebezpieczną.

Drugi przypadek: firma usługowa z wizytówką WordPress, zarządzaną przez zewnętrzną agencję, która „kiedyś to ustawiła i nikt tego nie dotyka”. To dokładnie profil strony najbardziej narażonej — nikt nie sprawdza wersji, nikt nie widzi powiadomienia o aktualizacji, bo nikt tam nie zagląda.

Trzeci przypadek, mniej oczywisty: firma, która korzysta z Cloudflare w darmowym planie i uważa, że to załatwia sprawę. Częściowo tak — klienci planu darmowego byli chronieni automatycznie. Ale klienci planów płatnych (Pro, Business, Enterprise) musieli sami dopilnować, żeby reguły Cloudflare Managed Rules były włączone. Płacisz za usługę i zakładasz, że ochrona jest wliczona w cenę — czasem trzeba to jeszcze świadomie kliknąć.

Kontrapunkt: łatka to nie to samo co bezpieczeństwo

Warto tu wprowadzić rozróżnienie, które łatwo umyka w pośpiechu. Zaktualizowanie WordPressa do wersji bez luki nie jest równoznaczne ze stwierdzeniem, że strona nie została wcześniej przejęta. Jeśli instalacja stała na podatnej wersji dłużej niż kilka dni, eksperci od bezpieczeństwa radzą traktować ją jak potencjalnie już zaatakowaną, a nie tylko teoretycznie zagrożoną. To różnica między „zamknąłem drzwi” a „sprawdziłem, czy ktoś już nie wszedł, zanim je zamknąłem”.

Łukasz Ozimek, COO Exea Data Center — firmy hostingowej, która ma oczywisty interes w tym, by pozycjonować się jako głos eksperta w kryzysach bezpieczeństwa — zwraca uwagę, że skala i charakter tej luki są rzadkością nawet na tle wcześniejszych incydentów WordPressa. Warto ten komentarz czytać z tą świadomością: fakty dotyczące samych CVE i tempa ataków pochodzą z niezależnych źródeł (badacze bezpieczeństwa, CERT Polska, firmy monitorujące exploity), a ocena wagi problemu od przedstawiciela branży hostingowej to głos zainteresowanej strony, nie neutralnego obserwatora.

Co zrobić dziś, jeśli jeszcze nie zrobiłeś

• Sprawdź wersję WordPressa w Kokpicie → Aktualizacje. Wersje 6.9.0–6.9.4, 7.0.0–7.0.1 i 6.8.0–6.8.5 są w grupie ryzyka.
• Zaktualizuj do 7.0.2, 6.9.5 lub 6.8.6 — to jedyne pełne rozwiązanie, reszta to prowizorka.
• Po aktualizacji sprawdź jeszcze raz numer wersji w panelu. Wymuszone aktualizacje automatyczne czasem się nie kończą powodzeniem mimo uruchomienia.
• Jeśli nie możesz zaktualizować od razu, zablokuj na WAF obie formy dostępu do endpointu — samą ścieżkę i jej wariant przez parametr — bo zablokowanie tylko jednej zostawia furtkę otwartą.
• Niezależnie od tego, czy zdążyłeś załatać: przejrzyj listę kont administratorów, sprawdź ostatnio modyfikowane pliki i logi pod kątem nietypowych żądań do REST API.

Ta historia nie jest o tym, że WordPress jest zły albo że trzeba z niego uciekać — to wciąż najbardziej sprawdzony silnik pod firmową stroną. Jest o czymś innym: o tym, że „działa” przestało znaczyć „jest bezpieczne”, a czas na reakcję, jaki kiedyś dawała nam branża, po prostu się skończył. Kto czeka na powiadomienie w mailu, czeka za długo.