TL;DR: Jak zabezpieczyć stronę WordPress? Przede wszystkim szybko aktualizować rdzeń, wtyczki i motywy, bo atakujący potrafią uderzyć w lukę w ciągu kilku godzin od jej ujawnienia. Do tego minimum wtyczek z pewnych źródeł, silne hasła z 2FA, wyłączony XML-RPC, przegląd kont i haseł aplikacji, aktualne PHP oraz kopie zapasowe trzymane poza serwerem. Zabezpieczenie WordPress to nie jedna wtyczka, tylko kilkanaście prostych nawyków, które razem zamykają drzwi, przez które w mojej praktyce najczęściej wchodzą włamywacze. Poniżej znajdziesz 14 kroków z wyjaśnieniem „dlaczego” i „jak”.
Na co dzień czyszczę zhakowane strony WordPress i prawie zawsze widzę to samo: włamanie nie było wynikiem genialnego ataku, tylko zaniedbania, które dało się wyłapać w kwadrans. Skala problemu jest duża. Według Patchstack w 2025 roku odkryto w ekosystemie WordPressa 11 334 nowe podatności, o 42% więcej niż rok wcześniej, a 91% z nich dotyczyło wtyczek[1]. Sucuri podaje, że w 2023 roku 95,5% wykrytych przez nich infekcji dotyczyło stron na WordPressie, a 39,1% zainfekowanych stron miało nieaktualny CMS[2]. Jeśli chcesz zobaczyć, jakie konkretnie luki krążyły w tym roku, opisałem je we wpisie o najnowszych podatnościach WordPressa w 2026. Tutaj skupiam się na tym, co możesz zrobić.
Lista: 14 kroków, które realnie chronią stronę przed hakerami
1. Aktualizuj od razu i włącz automatyczne aktualizacje
Dlaczego: czas między łatką a atakiem liczy się dziś w godzinach. Patchstack wylicza, że mediana czasu do masowej eksploatacji luki to 5 godzin od jej ujawnienia[1]. Przy krytycznej luce w rdzeniu CVE-2026-87902 pierwsze próby ataku pojawiły się 22 września 2026 roku, czyli tego samego dnia, w którym wyszła poprawka w wersji 7.1.2, bo atakujący analizowali samą łatkę[3]. Strona aktualizowana „raz w miesiącu” jest przez kilka tygodni otwarta.
Jak: nowe instalacje od WordPressa 5.6 mają domyślnie włączone automatyczne aktualizacje rdzenia, ale starsze instalacje często dostają tylko drobne poprawki, a wtyczki i motywy aktualizują się same tylko w wyjątkowych przypadkach[4]. Wejdź w Kokpit, a potem w Aktualizacje i włącz automatyczne aktualizacje wszystkich wersji, a na liście wtyczek kliknij „Włącz automatyczne aktualizacje” przy każdej z nich. To się opłaca: przy luce wp2shell WordPress wymusił aktualizacje właśnie na stronach z włączonymi auto-aktualizacjami[5]. Pamiętaj jednak, że auto-update to nie przegląd. Gdy WordPress.org wymusił aktualizację przejętych wtyczek EssentialPlugin, nowa wersja wyłączyła łączność z serwerem atakującego, ale nie usunęła kodu, który zdążył już trafić do wp-config.php[6].
2. Usuń porzucone i zbędne wtyczki
Dlaczego: każda wtyczka to dodatkowy kod, który ktoś musi łatać. Patchstack podaje, że tylko w 2024 roku z repozytorium WordPress.org usunięto 1 614 wtyczek i motywów z powodu niezałatanych luk[7]. Usunięcie z repozytorium nie usuwa ich z Twojej strony. Taka „wtyczka zombie” działa dalej i nigdy nie dostanie poprawki. Do tego dochodzi ryzyko przejęcia: w 2026 roku napastnik kupił ponad 30 wtyczek i umieścił w nich backdoor, czyli ukrytą furtkę, a WordPress.org zamknął 31 wtyczek jednego dnia[6].
Jak: przejrzyj listę wtyczek i zadaj przy każdej pytanie: czy ta funkcja jest mi naprawdę potrzebna? Wyłączone wtyczki usuń całkowicie, bo nieaktywny kod też bywa wykorzystywany. Sprawdź, kiedy wtyczka była ostatnio aktualizowana i czy wciąż jest dostępna w katalogu WordPress.org. Jeśli autor lub właściciel wtyczki nagle się zmienił, przyjrzyj się jej uważniej.
3. Zero „nulled” motywów i wtyczek
Dlaczego: „nulled” to spiratowane wersje płatnych dodatków, rozdawane za darmo w sieci. Sucuri opisuje, że niosą one backdoory, złośliwe oprogramowanie i spam SEO. W jednym z opisanych przypadków webshell (skrypt do zdalnego sterowania serwerem) siedział w pliku motywu, wyłączał wtyczki bezpieczeństwa i wysyłał dane z wp-config.php na zewnętrzny serwer[8].
Jak: kupuj licencje u producenta i pobieraj pliki wyłącznie z jego strony lub z WordPress.org. Uwaga: „płatne” nie znaczy „bezpieczniejsze”. Według Patchstack znane, aktywnie wykorzystywane podatności występują 3 razy częściej w komponentach premium niż w darmowych[1], więc płatne dodatki też muszą być aktualizowane.
4. Silne hasła i 2FA dla każdego administratora
Dlaczego: hasła wyciekają z innych serwisów i trafiają do botów, które próbują ich na tysiącach stron. Dokumentacja WordPressa wprost zaleca włączenie 2FA (logowania dwuskładnikowego, czyli hasła plus kodu z telefonu) dla wszystkich administratorów i kont z podwyższonymi uprawnieniami[9].
Jak: rdzeń WordPressa nie ma wbudowanego 2FA, potrzebna jest wtyczka, np. „Two Factor” z oficjalnego katalogu[10]. Hasło generuj menedżerem haseł, nigdy nie używaj go w innym miejscu i zmień je od razu, jeśli Twój adres e-mail pojawił się w jakimś wycieku.
5. Wyłącz XML-RPC, jeśli go nie używasz
Dlaczego: XML-RPC to stary interfejs do zdalnego publikowania, dziś rzadko potrzebny. Dokumentacja WordPressa pisze, że plik xmlrpc.php jest częstym celem ataków brute force (zgadywania haseł) i że jeśli z niego nie korzystasz, należy go wyłączyć[9].
Z praktyki: strona firmy usługowej spod Warszawy. Boty logowały się przez XML-RPC hasłem administratora, które krążyło w wyciekach, i publikowały spam. Potem ktoś aktywował menedżer plików i wstrzyknął do functions.php fałszywą „weryfikację Cloudflare”, która kazała odwiedzającym wkleić komendę do systemu, instalując malware na komputerach klientów firmy. Wyłączony XML-RPC i 2FA zamknęłyby tę drogę na samym początku.
Jak: wyłącz XML-RPC wtyczką bezpieczeństwa albo regułą na serwerze. Ograniczaj też liczbę prób logowania, najlepiej na poziomie hostingu lub CDN, a w ostateczności wtyczką[9].
6. Przejrzyj hasła aplikacji i usuń nieznane
Dlaczego: hasła aplikacji (Application Passwords) są w WordPressie od wersji 5.6. Działają jako zamiennik hasła użytkownika w REST API i XML-RPC, choć nie pozwalają zalogować się do kokpitu[11]. Zmiana głównego hasła ich nie unieważnia.
Z praktyki: sklep internetowy, w którym zainstalowano fałszywą wtyczkę udającą narzędzie do czyszczenia cache. Była backdoorem z własnym punktem dostępu w API, przez który atakujący wstrzykiwał linki do treści. Miał też własne hasło aplikacji, więc działał dalej mimo zmiany hasła administratora.
Jak: wejdź w Użytkownicy, otwórz profil każdego administratora i przewiń do sekcji „Hasła aplikacji”. Usuń każde, którego pochodzenia nie znasz. Jeśli nie korzystasz z żadnych integracji, możesz tę funkcję wyłączyć jednym filtrem w kodzie[11].
7. Sprawdź konta użytkowników i domyślną rolę
Dlaczego: według Sucuri 55,2% stron z zainfekowaną bazą danych miało złośliwe konta administratorów[2]. Atakujący zakłada sobie konto, żeby wrócić po sprzątaniu.
Z praktyki: przy audytach włamań jednym z pierwszych miejsc, które sprawdzam, jest ustawienie „Domyślna rola nowego użytkownika”. Zdarzało mi się znaleźć tam wartość „Administrator”, ustawioną przez atakującego. Każdy, kto zarejestrował się na stronie, dostawał pełną władzę.
Jak: w Ustawienia, Ogólne sprawdź, czy domyślna rola to „Subskrybent”, i wyłącz rejestrację, jeśli jej nie potrzebujesz. Na liście użytkowników przefiltruj administratorów i usuń konta, których nie rozpoznajesz. Każdy pracownik powinien mieć własne konto z najniższą wystarczającą rolą.
8. Wyłącz edytor plików w kokpicie
Dlaczego: wbudowany edytor motywów i wtyczek pozwala każdemu, kto przejmie konto administratora, wkleić złośliwy kod bez dostępu do serwera.
Jak: dodaj do pliku wp-config.php linię define( 'DISALLOW_FILE_EDIT', true );. Dokumentacja WordPressa uczciwie zaznacza, że to nie powstrzyma atakującego przed wgraniem złośliwych plików[12], więc traktuj to jako jedną z warstw, a nie pełną ochronę.
9. Ustaw poprawne uprawnienia plików
Dlaczego: zbyt szerokie uprawnienia pozwalają złośliwemu skryptowi zmieniać pliki, których nie powinien ruszać.
Jak: zalecenia WordPressa to 755 dla katalogów, 644 dla plików i 400 lub 440 dla wp-config.php. Do przesyłania plików używaj SFTP zamiast zwykłego FTP[12]. Warto też zablokować wykonywanie plików PHP w katalogu uploads. Takie właśnie obejście zalecano przy luce w Elementor Pro, gdzie złośliwe pliki trafiały do podkatalogu uploads[13].
10. Aktualne PHP, nie wersja po końcu wsparcia
Dlaczego: PHP to język, w którym działa WordPress. Wersje po końcu wsparcia (EOL) nie dostają poprawek bezpieczeństwa. Według php.net PHP 7.4 nie jest wspierane od 28 listopada 2022, PHP 8.0 od 26 listopada 2023, a PHP 8.1 od 31 grudnia 2025. PHP 8.2 kończy wsparcie 31 grudnia 2026[14].
Jak: zespół WordPressa wskazuje PHP 8.3 jako minimalną rekomendowaną wersję[15]. Wersję zmienisz zwykle w panelu hostingu. Zrób to najpierw na kopii strony albo przynajmniej z świeżą kopią zapasową, bo stare wtyczki potrafią nie działać na nowym PHP.
11. Kopie zapasowe 3-2-1 poza serwerem, z testem przywracania
Dlaczego: kopia trzymana na tym samym koncie hostingowym ginie razem ze stroną albo zostaje zainfekowana. Złośliwe oprogramowanie z rodziny opisanej przez Sucuri we wrześniu 2026 przechowywało swoje kopie m.in. w paczkach ZIP[16].
Jak: stosuj zasadę 3-2-1 zalecaną przez CISA: 3 kopie danych, na 2 różnych typach nośników, z czego 1 poza siedzibą[17]. Dla strony oznacza to np. kopię na hostingu, kopię w chmurze i kopię na dysku u Ciebie. Raz na kwartał przywróć kopię na testową domenę. Kopia, której nigdy nie odtworzono, jest tylko nadzieją. Aktualizuj też samą wtyczkę do kopii, bo i ona bywa celem: luka w All-in-One WP Migration pozwalała na wykonanie kodu przy odtwarzaniu archiwum[18].
12. WAF i monitoring zmian
Dlaczego: 46% podatności z 2025 roku nie miało łatki w dniu ujawnienia[1], więc samymi aktualizacjami nie zamkniesz każdej luki. WAF (zapora aplikacji webowych) blokuje znane ataki, zanim dotrą do WordPressa. Nie licz przy tym wyłącznie na hosting: w teście Patchstack typowe zabezpieczenia hostingowe zablokowały tylko 12% ataków na znane, wykorzystywane podatności[1].
Jak: rozważ zarządzany WAF (Cloudflare, Sucuri lub firewall wtyczki bezpieczeństwa). Pamiętaj, że darmowy Wordfence dostaje nowe reguły zapory z 30-dniowym opóźnieniem[19]. Włącz powiadomienia o zmienionych plikach, nowych administratorach i nowych wtyczkach.
13. Jedna strona, jedno konto hostingowe
Dlaczego: jeśli kilka stron stoi na jednym koncie, włamanie do najsłabszej daje dostęp do wszystkich.
Z praktyki: kilka stron na wspólnym koncie, na każdej obce konta administratorów, a w crontabie (harmonogramie zadań serwera) backdoor, który co jakiś czas od nowa infekował pliki. Czyszczenie pojedynczych stron nic nie dawało, bo infekcja wracała z harmonogramu. Pomogło dopiero sprzątanie całego konta naraz, łącznie z harmonogramem zadań.
Jak: trzymaj ważne strony na osobnych kontach hostingowych, a stare, nieużywane instalacje usuń. Przy wyborze hostingu pomoże wpis o tym, jak wybrać domenę i hosting dla firmy.
14. Monitoruj Google Search Console
Dlaczego: często to Google pierwszy zauważa włamanie. Raport „Problemy dotyczące bezpieczeństwa” pokazuje zhakowane treści, złośliwe oprogramowanie i socjotechnikę[20].
Jak: zweryfikuj stronę w Search Console i dopilnuj, by powiadomienia trafiały na e-mail, który czytasz. Reaguj na komunikat, że ktoś nowy został właścicielem usługi. Google ostrzega, że przy nieznanym właścicielu jest duże prawdopodobieństwo, że strona została zhakowana[21]. Co miesiąc rzuć okiem na liczbę zaindeksowanych stron: nagły skok to częsty objaw spamu. Jeśli już widzisz takie sygnały, przeczytaj wpis o tym, jak rozpoznać zhakowaną stronę WordPress i co zrobić od razu.
Checklista: zabezpieczenie WordPress w skrócie
- Automatyczne aktualizacje rdzenia, wtyczek i motywów włączone.
- Usunięte nieaktywne, porzucone i zbędne wtyczki.
- Żadnych „nulled” motywów ani wtyczek.
- Silne, unikalne hasła i 2FA dla administratorów.
- XML-RPC wyłączony, limit prób logowania.
- Hasła aplikacji przejrzane, nieznane usunięte.
- Lista administratorów sprawdzona, domyślna rola „Subskrybent”.
- DISALLOW_FILE_EDIT w wp-config.php.
- Uprawnienia 755/644, wp-config.php 400 lub 440, brak PHP w uploads.
- PHP 8.3 lub nowsze.
- Kopie 3-2-1 poza serwerem, przywracanie przetestowane.
- WAF i powiadomienia o zmianach.
- Osobne konta hostingowe dla ważnych stron.
- Search Console zweryfikowane, powiadomienia czytane.
Nie każdy właściciel firmy ma czas, żeby co tydzień pilnować tej listy. Dlatego wszystkie te kroki, od aktualizacji, przez kopie zapasowe, po monitoring, wykonuję w ramach usługi stałej opieki i administracji stronami WordPress. Ty zajmujesz się firmą, a ja pilnuję, żeby strona nie stała się furtką dla hakerów.
FAQ - zabezpieczenie strony WordPress
Czy wystarczy zainstalować wtyczkę bezpieczeństwa?
Nie. Wtyczka bezpieczeństwa pomaga, ale nie zastąpi aktualizacji, silnych haseł, przeglądu kont ani kopii poza serwerem. Darmowe wersje niektórych zapór dostają nowe reguły z opóźnieniem, a atakujący działają w ciągu godzin. Traktuj wtyczkę jako jedną warstwę z kilkunastu.
Czy automatyczne aktualizacje mogą zepsuć stronę?
Mogą, choć zdarza się to rzadko. Dlatego automatyczne aktualizacje idą w parze z kopiami zapasowymi i monitoringiem. W mojej ocenie ryzyko awarii po aktualizacji jest dużo mniejsze niż ryzyko włamania przez lukę, która przez tygodnie czeka na ręczną aktualizację.
Czy zmiana hasła admina wystarczy po podejrzeniu włamania?
Nie. Atakujący często zostawia sobie ukryte konto administratora, hasło aplikacji albo backdoor w plikach lub bazie danych. Każda z tych furtek działa niezależnie od Twojego hasła. Trzeba sprawdzić wszystkie, najlepiej w ramach profesjonalnego czyszczenia zhakowanej strony.
Jak często robić kopie zapasowe strony?
Tak często, jak często zmienia się treść. Dla sklepu internetowego to zwykle codziennie, dla strony wizytówki wystarczy raz w tygodniu i przed każdą większą zmianą. Ważniejsze od częstotliwości jest to, żeby kopia leżała poza serwerem i żeby raz na jakiś czas sprawdzić, czy da się ją przywrócić.
Czy mały firmowy serwis w ogóle jest celem hakerów?
Tak. Większość ataków jest automatyczna: boty skanują wszystkie strony w poszukiwaniu znanych luk i wyciekłych haseł, niezależnie od wielkości firmy. Mała strona przydaje się atakującym do spamu SEO, przekierowań i rozsyłania malware.
Twoja strona już została zhakowana?
Jeśli widzisz spam w Google, dziwne przekierowania albo obcych administratorów, sama profilaktyka już nie wystarczy. Zajmuję się naprawą i czyszczeniem zhakowanych stron WordPress: szukam wszystkich furtek, usuwam infekcję z plików i bazy, zamykam lukę, przez którą weszli włamywacze, i pomagam zdjąć ostrzeżenia Google. Gdy strona jest już czysta, mogę przejąć jej stałą administrację i opiekę, żeby sytuacja się nie powtórzyła. Zadzwoń: +48 606 719 343 albo napisz: lukasz@freelancerka.com.
Przypisy i źródła
Wszystkie źródła zweryfikowane; dostęp: 8 października 2026.
- Patchstack, „State of WordPress Security in 2026” (25.02.2026) - patchstack.com
- Sucuri, „2023 Hacked Website & Malware Threat Report” (06.2024) - sucuri.net
- Patchstack, „CVE-2026-87902: Attackers Started Probing WordPress Sites Hours After the Patch” (22.09.2026) - patchstack.com
- WordPress Advanced Administration Handbook, „Upgrading WordPress” (b.d.) - developer.wordpress.org
- Rapid7, „CVE-2026-63030: wp2shell, a Critical Remote Code Execution Vulnerability in WordPress Core” (17.07.2026) - rapid7.com
- InfoQ, „Attacker Bought 30 WordPress Plugins on Flippa and Backdoored All of Them” (06.05.2026) - infoq.com
- Patchstack, „State of WordPress Security in 2025” (14.03.2025) - patchstack.com
- Sucuri Blog, „The Dangers of Installing Nulled WordPress Themes & Plugins” (02.2023) - blog.sucuri.net
- WordPress Advanced Administration Handbook, „Brute Force Attacks” (b.d.) - developer.wordpress.org
- WordPress.org, „Two Factor” (wtyczka, b.d.) - wordpress.org
- Make WordPress Core, „Application Passwords: Integration Guide” (05.11.2020) - make.wordpress.org
- WordPress Advanced Administration Handbook, „Hardening WordPress” (b.d.) - developer.wordpress.org
- Orca Security, „Critical Elementor Pro File Upload Flaw Enables Unauthenticated Remote Code Execution on WordPress Sites” (2026) - orca.security
- PHP.net, „Supported Versions” (stan na 08.10.2026) - php.net
- Make WordPress Core, „PHP support clarification, spring 2026 edition” (22.05.2026) - make.wordpress.org
- Sucuri Blog, „SC WordPress Malware: A Self-Healing Mesh of Loaders, Drop-Ins, and a Blockchain-Controlled Backdoor” (30.09.2026) - blog.sucuri.net
- CISA, „Data Backup Options” (b.d.) - cisa.gov
- Tech Times, „WordPress Backup Plugin Flaw: 3.25 Million Sites Exposed, Exploit Code Active” (03.09.2026) - techtimes.com
- Wordfence, „Wordfence Intelligence Weekly WordPress Vulnerability Report (September 21, 2026 to September 27, 2026)” (01.10.2026) - wordfence.com
- Google, „Security Issues report” (Search Console Help, b.d.) - support.google.com
- Google (web.dev), „Fix the Japanese keyword hack” (b.d.) - web.dev
