Co piąta strona, którą dostaję do naprawy, trafia do mnie po włamaniu. Prawie zawsze słyszę to samo zdanie: „przecież to mała firmowa strona, komu by się chciało”. I w tym tkwi nieporozumienie — nikomu się nie chce. Skanowanie prowadzą boty, które nie wiedzą ani czym się zajmujesz, ani ile zarabiasz. Sprawdzają po prostu, czy na serwerze stoi wtyczka w wersji z dziurą.
Skala robi wrażenie. Według raportu State of WordPress Security firmy Patchstack w 2025 roku zgłoszono 11 334 nowych podatności w ekosystemie WordPressa — o 42% więcej niż rok wcześniej. 91% z nich dotyczyło wtyczek, 9% motywów, a w samym rdzeniu WordPressa znaleziono zaledwie sześć błędów, wszystkie o niskim priorytecie.
To ważny wniosek: WordPress rzadko jest problemem. Problemem jest to, co do niego dokładamy.
Jak wygląda typowe włamanie — i dlaczego trwa kilka godzin, nie tygodni
Scenariusz powtarza się do znudzenia. Ktoś publikuje informację o luce w popularnej wtyczce. Boty zaczynają masowo skanować internet w poszukiwaniu stron z podatną wersją. Patchstack policzył, że mediana czasu do pierwszego wykorzystania luki wynosi 5 godzin, a połowa groźnych błędów jest atakowana w ciągu doby.
Twoja strona nie została wybrana. Została znaleziona.
Gorzej: 46% podatności nie miało łatki w momencie ujawnienia. Samo klikanie „aktualizuj” nie zawsze wystarczy — czasem trzeba wtyczkę wyłączyć na kilka dni albo zastąpić inną.
Fundament: cztery rzeczy, które załatwiają większość ryzyka
Aktualizuj — ale nie na żywym organizmie
Przestarzała wtyczka to najczęstsza furtka. Jednocześnie ślepe klikanie „aktualizuj wszystko” na działającej stronie potrafi ją położyć. Właściwa kolejność to: kopia zapasowa, aktualizacja na środowisku testowym, sprawdzenie kluczowych podstron, dopiero potem produkcja. Przy stronie firmowej wystarczy robić to raz w miesiącu, przy sklepie — co tydzień.
Ogranicz liczbę wtyczek do tych, które realnie pracują
Skoro 91% podatności pochodzi z wtyczek, to każda kolejna zwiększa pole rażenia. Przy przejęciu strony po innym wykonawcy standardowo wyłączam połowę i pytam klienta, czego brakuje. Zwykle nie brakuje niczego. Wtyczek nieużywanych nie wystarczy dezaktywować — trzeba je usunąć, bo ich pliki nadal leżą na serwerze i nadal dają się wywołać.
To jeden z powodów, dla których stawiam na dedykowane motywy zamiast gotowców: strona kodowana pod konkretny projekt potrzebuje kilku wtyczek zamiast kilkunastu.
Silne hasła i drugi składnik logowania
Login admin i hasło z imieniem psa to zaproszenie. Menadżer haseł rozwiązuje problem zapamiętywania, a uwierzytelnianie dwuskładnikowe zatrzymuje atakującego nawet wtedy, gdy hasło wyciekło z zupełnie innego serwisu. To pięć minut konfiguracji i najlepszy stosunek efektu do wysiłku w całym tym zestawieniu.
Kopie zapasowe poza serwerem strony
Backup trzymany na tym samym hostingu co strona nie jest backupem — jest kopią w tym samym płonącym budynku. Kopia ma lądować w innym miejscu: chmura, dysk zewnętrzny, osobne konto. I musi być przetestowana, bo kopia, której nikt nigdy nie przywracał, to założenie, nie zabezpieczenie.
Warstwa druga: rzeczy, które odsiewają boty
- Limit prób logowania. Atak słownikowy polega na tysiącach prób. Blokada po pięciu nieudanych kończy zabawę, zanim się zacznie.
- Ukrycie adresu logowania. Przeniesienie
/wp-adminpod inny adres nie zatrzyma zdeterminowanego człowieka, ale odetnie większość automatów. - Wyłączenie edytora plików w panelu. Jedna linijka w
wp-config.phpsprawia, że nawet po przejęciu konta administratora nie da się wklejać kodu prosto z przeglądarki. - Certyfikat SSL. Dziś darmowy i standardowy. Bez niego przeglądarka sama ostrzega odwiedzających, a formularze przesyłają dane otwartym tekstem.
- Uprawnienia dopasowane do roli. Osoba, która pisze wpisy na blogu, potrzebuje roli Autor, nie Administrator. Im mniej kont z pełnymi prawami, tym mniejsze ryzyko.
Czego nie załatwi żadna wtyczka bezpieczeństwa
Najczęstszy błąd, jaki widzę po drugiej stronie: ktoś instaluje popularną wtyczkę ochronną, włącza wszystkie przełączniki i uznaje temat za zamknięty. Tymczasem Patchstack wskazuje, że najczęściej wykorzystywaną kategorią podatności jest Broken Access Control — błędy kontroli uprawnień, które w ruchu sieciowym wyglądają jak najzwyklejsze, poprawnie zalogowane żądanie. Zapora ich nie odróżni, bo formalnie nic podejrzanego się nie dzieje.
Drugi mit dotyczy wtyczek premium. Intuicja podpowiada, że płatne znaczy bezpieczniejsze. Dane mówią coś innego: w komponentach komercyjnych odnotowano trzykrotnie więcej realnie wykorzystywanych luk niż w darmowych. Nie dlatego, że są gorzej napisane — dlatego, że atakującym opłaca się szukać tam, gdzie za jedną luką stoi kilkaset tysięcy sklepów.
Ile to kosztuje, gdy się nie uda
Sprzątanie po włamaniu to nie jest „usunięcie wirusa”. Trzeba przejrzeć pliki motywu i wtyczek, porównać je z oryginalnymi wersjami, przeszukać bazę pod kątem wstrzykniętego kodu, znaleźć furtki zostawione przez atakującego, wymienić wszystkie hasła i klucze, a na koniec poprosić Google o ponowną weryfikację witryny — bo jeśli strona rozsyłała spam, wypada z wyników wyszukiwania.
To zwykle kilkanaście godzin pracy. Miesięczna opieka techniczna kosztuje ułamek tej kwoty — i, co ważniejsze, sprawia, że rozmowa o włamaniu w ogóle się nie odbywa.
Prosta lista do odhaczenia w ten weekend
- Sprawdź, czy WordPress, motyw i wszystkie wtyczki są aktualne.
- Usuń wtyczki i motywy, których nie używasz — nie wyłącz, usuń.
- Włącz uwierzytelnianie dwuskładnikowe dla wszystkich kont administratora.
- Sprawdź, gdzie ląduje kopia zapasowa i kiedy powstała ostatnia.
- Przejrzyj listę użytkowników — usuń konta po byłych współpracownikach i wykonawcach.
- Potwierdź, że strona działa po
https, a wersjahttpprzekierowuje.
Sześć punktów, godzina pracy. To nie uczyni Twojej strony niemożliwą do zaatakowania — nic tego nie zrobi — ale przesunie ją z grupy łatwych celów do takich, przy których bot po prostu jedzie dalej.
Warto przeczytać dalej
- Dlaczego warto skorzystać z administracji WordPress — co dokładnie obejmuje stała opieka nad stroną.
- Jak wybrać hosting dla WordPressa — bo część zabezpieczeń zaczyna się po stronie serwera.
- Google Consent Mode v2 — osobny temat zgodności, który często leży odłogiem obok bezpieczeństwa.
Masz wątpliwości co do stanu swojej strony? Zerknij na nią w ramach bezpłatnej wyceny — napiszę wprost, czy coś wymaga uwagi, nawet jeśli odpowiedź brzmi „nic nie trzeba robić”.
Źródło danych: Patchstack, State of WordPress Security in 2026.