17 lipca 2026 roku WordPress wydał awaryjną aktualizację bezpieczeństwa. Tydzień później, 24 lipca, na dwóch stronach naszych klientów zobaczyliśmy, że ktoś próbował z załatanej luki skorzystać. Sprawa skończyła się tego samego dnia, a właściciele obu witryn nie musieli nic robić ani o niczym wiedzieć.
To nie jest opowieść o wyjątkowo sprytnym ataku. To opowieść o tygodniu, w którym cały internet dowiaduje się o dziurze w najpopularniejszym systemie do prowadzenia stron, i o tym, dlaczego jednym właścicielom taki tydzień mija niezauważenie, a innym zabiera kilka dni i kilka tysięcy złotych.
Opisujemy to zdarzenie od środka, z datami i z sygnałami, które zobaczyliśmy na ekranie. Nie po to, żeby straszyć, tylko dlatego, że to najlepszy znany nam sposób pokazania, na czym w praktyce polega pilnowanie aktualizacji WordPressa.
Najważniejsze w skrócie
- 17 lipca WordPress wydał awaryjną poprawkę na dwie poważne luki. Siedziały w samym WordPressie, nie we wtyczkach.
- Groźniejsza z nich pozwalała przejąć stronę bez logowania i bez konta, więc nie chroniło przed nią ani mocne hasło, ani ostrożny dobór wtyczek.
- Pierwsze próby ataków ruszyły około półtorej godziny po ogłoszeniu poprawki.
- 24 lipca zobaczyliśmy ślady takich prób na dwóch stronach objętych naszą opieką. Pozostałe witryny nie zostały ruszone.
- Tego samego dnia zaktualizowaliśmy wszystkie strony i posprzątaliśmy te dwie. Kopii zapasowych nie trzeba było przywracać.
Poprawka, która sama pokazuje atakującym, gdzie szukać
Aktualizacje bezpieczeństwa WordPressa wychodzą kilka razy w roku i zwykle nikt poza branżą ich nie zauważa. Ta była inna. Załatała dwie dziury naraz, a jedna z nich pozwalała uruchomić własny kod na cudzym serwerze bez logowania, bez konta i bez żadnej podejrzanej wtyczki.
Warto się przy tym zatrzymać, bo przeczy to temu, co zwykle słyszy właściciel strony. Standardowa rada brzmi, żeby nie instalować przypadkowych dodatków i pilnować haseł. Tutaj nic z tego nie miało znaczenia. Zagrożona była strona, która robiła wszystko dobrze, o ile tylko nie zdążyła się zaktualizować.
Druga rzecz jest jeszcze mniej oczywista. Ogłoszenie poprawki opisuje, co dokładnie było zepsute, więc dla kogoś, kto potrafi czytać kod, jest instrukcją, gdzie uderzyć. Pierwsze próby włamań zaczęły się około półtorej godziny po publikacji łatki. Dzień wydania poprawki bywa więc groźniejszy niż cały tydzień przed nim.
Skala była na tyle duża, że 18 lipca ostrzeżenie wydał CERT Polska, a 21 lipca amerykańska agencja CISA wpisała obie luki na listę tych, o których wiadomo, że są aktywnie wykorzystywane. To nie było teoretyczne zagrożenie opisane w komunikacie, tylko trwająca fala.
Co zobaczyliśmy na stronach klientów 24 lipca
Strony objęte naszą opieką są codziennie skanowane, a raz w tygodniu przechodzą przegląd z aktualizacjami. 24 lipca te dwie rutyny spotkały się z czymś, co nie wyglądało jak zwykły dzień. Na dwóch witrynach pojawiły się trzy sygnały naraz.
Konta, których nikt nie zakładał
Na liście użytkowników zaczęły przybywać nowe konta. Żadne nie należało do pracowników klienta ani do nas.
Pliki, których nikt nie wgrywał
W katalogach witryny zaczęły zapisywać się pliki, które nie pochodziły ani z aktualizacji, ani z pracy nad treścią.
Zmiany, których nikt nie zlecał
Ustawienia zaczęły się zmieniać bez udziału osób, które mają do witryny dostęp.
Taka kolejność nie jest przypadkowa. Kto potrafi uruchomić własny kod na cudzej stronie, najpierw zakłada sobie wejście na przyszłość, czyli konto. Potem zostawia pliki, którymi będzie się posługiwał. Dopiero na końcu robi to, po co przyszedł, a to bywa rozsyłanie spamu, podmiana treści albo przekierowywanie ruchu na obce witryny.
Ślady zobaczyliśmy na dwóch stronach. Pozostałe witryny z naszej opieki tego dnia nie zostały ruszone.
Podejrzewasz, że Twoja strona ma wirusa?
Opisz objawy, przejrzymy stronę i wrócimy z odpowiedzią, czy to infekcja i jak ją usunąć.
Co zrobiliśmy tego samego dnia
Pierwszy ruch nie dotyczył wcale tych dwóch zaatakowanych stron. Zaczęliśmy od aktualizacji wszystkich pozostałych, także tych, na których nie było żadnych śladów. Kolejność wynika z prostego rachunku, skoro fala trwa i uderza losowo, najpierw zamyka się drzwi wszystkim, a dopiero potem sprząta u dwóch.
Na dwóch zaatakowanych witrynach doszła do tego druga część pracy, czyli to samo, co przy każdym usuwaniu wirusów z WordPressa. Trzeba było skasować konta założone przez atakującego, usunąć dopisane pliki i sprawdzić, czy nie zostało nic, co pozwoliłoby wrócić.
Najważniejsze zdanie tej historii jest jednak inne. Nie trzeba było przywracać kopii zapasowych. To rzadziej doceniana część szybkiej reakcji, bo przywrócenie kopii cofa stronę do stanu sprzed infekcji, ale cofa razem z nią wszystko inne, czyli zamówienia, wiadomości z formularzy i wpisy z ostatnich dni. Im wcześniej ktoś zauważy problem, tym mniejsza szansa, że po kopię w ogóle trzeba będzie sięgnąć.
Dzień wydania poprawki bywa groźniejszy niż cały tydzień przed nim.
Ogłoszenie łatki opisuje, co było zepsute, więc wskazuje atakującym drogę. Przy krytycznych lukach nie liczy się samo to, czy strona zostanie zaktualizowana, tylko jak szybko.
Obserwacja z opieki nad stronami klientów
Dlaczego właściciele tych stron nie musieli nic robić
Żaden z klientów nie dostał od nas wiadomości z prośbą o pilne działanie. Nikt nie logował się wieczorem do panelu, nie szukał w internecie, czy jego wersja jest zagrożona, i nie zastanawiał się, czy ktoś obcy czyta wiadomości z jego formularza kontaktowego.
Tak wygląda różnica, której nie widać na fakturze. Za lipiec ci klienci zapłacili dokładnie tyle samo co za czerwiec, a raport z miesiąca niczym się nie wyróżniał.
Cisza w raporcie nie znaczy, że nic się nie działo. Strony są zaczepiane codziennie i nie dlatego, że ktoś się na nie uwziął, tylko dlatego, że automaty przeczesują internet i próbują wszędzie tego samego. Odbite próby logowania i zablokowany ruch to zwykły dzień każdej witryny, która stoi w sieci. Właściciel nie ma być o tym informowany, bo to jest dokładnie ta praca, którą nam zlecił. Raport ma pokazywać stan strony i decyzje, które podjęliśmy, a nie listę zaczepek, które zostały już obsłużone. Co jeszcze się w tej pracy mieści, rozpisaliśmy w tekście o tym, co powinna obejmować opieka nad WordPressem.
Dla porównania warto przypomnieć inną historię z naszej praktyki. Strona producenta maszyn, której przez rok nikt nie aktualizował, i której nikt nie pilnował. Właściciel zgłosił się sam, kiedy witryna przestała się otwierać, a infekcja zdążyła już zakładać w panelu kolejne konta. Sprzątanie zajęło pięć godzin i kosztowało 1500 zł, nie licząc kilku dni, przez które strona nie działała. Opisaliśmy to dokładnie w tekście o tym, ile kosztuje usuwanie wirusów z WordPressa.
To było inne zdarzenie i inna przyczyna, ale przebieg infekcji bardzo podobny, od zakładania kont po dopisywanie plików. Różnica polegała wyłącznie na tym, czy ktoś patrzył.
Hosting to nie to samo co opieka nad stroną
Przy okazji tego zdarzenia wrócił temat, który słyszymy regularnie. Zgłosił się do nas klient, dla którego kiedyś robiliśmy stronę i który ma u nas hosting, ale nigdy nie wykupił opieki. Był przekonany, że skoro płaci za hosting, to ma w tym również ochronę przed wirusami. To bardzo częste nieporozumienie i warto je rozwiać, bo daje fałszywe poczucie bezpieczeństwa.
Hosting odpowiada za to, żeby strona miała gdzie stać i żeby serwer działał. Dobry hostingodawca zadba o zaporę, o kopie zapasowe całego serwera i o to, żeby zablokować część ruchu, który wygląda podejrzanie. Czego nie zrobi, to nie zaktualizuje Twojego WordPressa, nie zajrzy do listy użytkowników i nie zauważy, że w katalogu przybyło plików, których wczoraj tam nie było. Serwer może działać bez zarzutu, a strona na nim postawiona być w tym czasie zainfekowana.
Różnicę między jednym a drugim rozpisaliśmy dokładniej w tekście o tym, kiedy opieka po stronie hostingu przestaje wystarczać. W lipcu ta różnica sprowadzała się do jednego pytania, czy ktoś patrzył na samą stronę, a nie tylko na serwer, na którym stoi.
Co zrobić, jeśli Twojej strony nikt nie pilnuje
Pięć rzeczy, które możesz sprawdzić samodzielnie, nawet jeśli nie znasz się na technicznej stronie WordPressa.
- Sprawdź, czy WordPress jest aktualny. Po zalogowaniu do panelu zobaczysz to w sekcji Aktualizacje. Jeśli system prosi o aktualizację, zrób ją albo zleć komuś od razu, nie za tydzień. Jak przejść przez to bezpiecznie, krok po kroku, opisaliśmy w poradniku o aktualizacji WordPressa.
- Przejrzyj listę użytkowników. Każde konto, którego nie rozpoznajesz, jest powodem do niepokoju, a konto z uprawnieniami administratora tym bardziej.
- Włącz automatyczne aktualizacje bezpieczeństwa, jeśli nikt nie robi ich za Ciebie ręcznie. Automatyczna aktualizacja jest zawsze lepsza niż żadna.
- Sprawdź, kiedy powstała ostatnia kopia zapasowa i czy ktokolwiek próbował ją kiedyś odtworzyć. Kopia, której nikt nigdy nie sprawdził, jest tylko obietnicą kopii.
- Jeśli widzisz którykolwiek z sygnałów opisanych wyżej, nie kasuj niczego samodzielnie. Usunięcie podejrzanego pliku bez sprawdzenia, jak się tam znalazł, zwykle kończy się tym, że po kilku dniach pojawia się znowu.
Punkt pierwszy z tej listy jest zwykle tym, który ludzie odkładają najdłużej, i rzadko chodzi o brak czasu. Chodzi o obawę, że po aktualizacji strona przestanie działać, a nikt nie będzie umiał jej naprawić. Ta obawa nie jest bezpodstawna, aktualizacje potrafią popsuć rzeczy, które wychodzą dopiero po kilku dniach, i rozpisaliśmy to osobno, przy okazji tematu tego, co może się zepsuć po aktualizacji WordPressa. Warto tylko zestawić dwie rzeczy obok siebie. Nieudana aktualizacja to zwykle kilka godzin pracy i strona wraca do stanu sprzed. Przejęta strona to sprzątanie, którego zakresu nie znasz w dniu, w którym się zaczyna.
Ta luka została załatana i dziś jest już tylko jedną z wielu. Za kilka miesięcy pojawi się następna, bo tak działa oprogramowanie, z którego korzysta prawie połowa internetu. Jedyne, co da się ustawić z góry, to kto będzie patrzył na Twoją stronę w dniu, w którym to się stanie.
Chcesz, żeby ktoś patrzył na Twoją stronę codziennie?
Sprawdzimy, w jakim stanie jest dziś Twoja witryna, i powiemy, co wymaga uwagi.
Autor: Marcin Osak
Założyciel agencji interaktywnej Avangardo, którą prowadzi od 2008 roku. Tworzy strony i sklepy internetowe. Od lat pasjonuje się SEO, a od kilku lat także AI i optymalizacją stron pod wyszukiwanie generatywne (GEO). Ma za sobą ponad 1000 zrealizowanych projektów dla firm z całej Polski i Europy.
