Audyt Bezpieczeństwa WordPress | Audyty wycena indywidualna

#Audyt bezpieczeństwa WordPress: Kompendium wiedzy 2026

W dobie cyfrowej transformacji, bezpieczeństwo strony internetowej przestało być opcją, a stało się absolutną koniecznością. Rok 2025 przyniósł rekordową liczbę cyberataków wymierzonych w systemy CMS, a prognozy na 2026 rok wskazują na dalszy wzrost tego trendu, napędzany m.in. przez automatyzację ataków z wykorzystaniem sztucznej inteligencji (AI). WordPress, zasilający już ponad 43% wszystkich stron w internecie, jest naturalnym celem numer jeden.

Czy Twoja strona jest bezpieczna? Czy masz pewność, że dane Twoich klientów nie wyciekły? Audyt bezpieczeństwa WordPress to nie tylko sprawdzenie „czy strona działa”. To kompleksowy proces analizy, wykrywania luk (vulnerabilities), usuwania złośliwego oprogramowania (malware) i wdrażania strategii obronnej typu hardening.

W tym artykule, napisanym z perspektywy dewelopera i eksperta bezpieczeństwa, przeprowadzę Cię przez kompletny proces audytu. Dowiesz się, jak zabezpieczyć swojego WordPressa w wersji 6.7+, jakich narzędzi używać w 2026 roku i dlaczego podejście „Zero Trust” jest kluczowe dla przetrwania w sieci.

#Jak naprawdę dochodzi do włamań

Większość incydentów, które czyścimy, sprowadza się do kilku powtarzających się wzorców. Świadomość tych wzorców zmienia to, czego szukasz w kodzie i logach.

#Wtyczki, nie rdzeń

Core WordPressa od linii 5.x jest mocno utwardzony. Włamania, które widzimy na produkcji, idą przez wtyczki, najczęściej w trzech postaciach:

• Endpointy REST rejestrowane z permission_callback => '__return_true'. Tę szkołę pisania mieliśmy m.in. w Elementorze i kilku znanych form builderach.
• Stored XSS w shortcode’ach, które echo’ują $_GET lub post meta bez wp_kses_post().
• Upload przez AJAX, który przyjmuje plik bez wp_check_filetype_and_ext() i bez whitelisty MIME; kończy się dropem .cache.php w /wp-content/uploads/.
• Eskalacja uprawnień przez update_option('user_role') wystawione na save settings, który ufa requestowi.

Audyt sprawdza zainstalowane sluginy względem WPScan i Patchstack, a potem czyta źródło wtyczek pod kątem powyższych wzorców. Sama baza CVE nie wystarcza, bo zero-day nie jest jeszcze skatalogowany.

#Enumeracja użytkowników

?author=1 przekierowuje na /author/<slug>/ i wystawia login admina. Tak samo ?rest_route=/wp/v2/users i /wp-json/wp/v2/users na instalacjach, które nigdy nie ograniczyły publicznego endpointu users. Po hardeningu oba powinny zwracać 404 albo pustą tablicę.

#XML-RPC i amplifikacja

/xmlrpc.php jest ulubionym celem botnetów Loginizer-style. Klasyczny trik amplifikacyjny to system.multicall opakowujący wp.getUsersBlogs; jeden POST testuje 1000+ haseł. Jeśli nie używasz Jetpack i aplikacji mobilnej WP, można to wyłączyć całkowicie. Jeśli używasz, ograniczenie idzie na poziom WAF (Cloudflare managed challenge na /xmlrpc.php), nie do wp-config.

#Konsekwencje, które realnie boli klienta

Skompromitowana strona w polskim ekosystemie oznacza najczęściej:

1. Wyciek bazy klientów objętej RODO i obowiązek zgłoszenia incydentu do UODO w ciągu 72 godzin (art. 33 RODO). IOD musi mieć log dostępu pokazujący, kiedy doszło do nieautoryzowanego dostępu, a zwykła wtyczka security tego nie wystarczy.
2. Ryzyko wokół KSeF. Jeśli wp-config.php przechowuje klucze do API KSeF (testowego lub produkcyjnego), każdy backdoor w /wp-content/uploads/ ma do nich dostęp i może wystawiać faktury w imieniu firmy. Klucze KSeF nigdy nie powinny siedzieć w plikach pod web rootem; minimum to zmienna środowiskowa poza katalogiem WWW.
3. Wycieki credentiali Allegro, Przelewy24, Tpay. Restricted key Stripe albo seed do PSP zaszyte w wp-config.php jest pierwszą rzeczą, którą atakujący wyciąga przez backdoor. Mailer z firmową domeną zamienia się w spam relay w 48 godzin, host blackholuje port 25, a dostawca PSP cofnie ci konto na czas wyjaśnienia.
4. Pharma Hack i japanese keywords: czerwony ekran w Chrome i spadek pozycji w SERP, którego odbudowa po Safe Browsing trwa 2-6 tygodni nawet po pełnym czyszczeniu.

#Checklist audytu bezpieczeństwa WordPress

Profesjonalny audyt to proces ustrukturyzowany. Poniższa tabela przedstawia moją autorską checklistę, którą stosuje podczas pracy z klientami.

#Najczęstsze rodzaje infekcji (Malware)

Podczas audytów najczęściej spotykam się z trzema typami zagrożeń:

#1. SEO Spam (Pharma Hack / Japanese Keywords)

Hakerzy wstrzykują tysiące stron z chińskimi lub japońskimi znakami, promując podróbki produktów.

• Objaw: W wynikach wyszukiwania Google Twoja strona wyświetla dziwne znaki.
• Skutek: Pełna blokada w Google (ban) w ciągu 14 dni.

#wycena indywidualna ośliwe przekierowania (Malicious Redirects)

Użytkownik wchodzący na stronę jest przekierowywany na witryny hazardowe lub pornograficzne. Często działa to tylko dla użytkowników mobilnych lub z konkretnych lokalizacji, co utrudnia wykrycie przez właściciela.

• Mechanizm: Zmieniony plik header.php lub zainfekowany plik .htaccess.

#3. Backdory PHP

Ukryte skrypty (np. w plikach systemowych typu wp-includes/images.php), które pozwalają hakerowi odzyskać kontrolę nad stroną nawet po zmianie haseł.

#Hardening, który realnie zmienia ekspozycję

Hardening to nie checklist, który odhaczasz raz. To zestaw ograniczeń, które utrudniają lądowanie kolejnej klasy exploitów. Poniżej kolejność, w jakiej wdrażamy to przy audycie.

Stałe w wp-config.php. DISALLOW_FILE_EDIT i DISALLOW_FILE_MODS ucinają edytor w panelu i instalator wtyczek. FORCE_SSL_ADMIN blokuje kradzież ciastek na sieciach współdzielonych. WP_AUTO_UPDATE_CORE => 'minor' puszcza poprawki bezpieczeństwa bez ryzyka, że major aktualizacja położy sklep w piątek wieczorem. Sam plik trzymamy w trybie 440, własność na użytkowniku deploymentu, nie web userze. Klucze do API (KSeF, Tpay, Przelewy24) nie idą tutaj; idą do zmiennych środowiskowych poza web rootem.

Rotacja sekretów. Audyt rotuje osiem soli AUTH_KEY/SECURE_AUTH_KEY przez generator wordpress.org i wymusza wylogowanie wszystkich sesji. Robimy też przegląd Application Passwords w Users → Profile i unieważniamy te, które nie mają dokumentacji integracji.

Warstwa logowania. Two Factor lub Wordfence Login Security z TOTP, plus udokumentowana ścieżka odzyskania przez WP-CLI (wp user meta delete <id> _two_factor_* z serwera, kiedy ktoś zgubi telefon). Throttling na brzegu sieci, nie tylko w PHP. Dla sklepu na Cloudflare: WAF custom rule limitujący POST do /wp-login.php do 5 prób na minutę z IP, managed challenge na /xmlrpc.php. Polskie hostingi managed (Mhostingu, home.pl, Cyberfolks) coraz częściej oferują WAF na poziomie panelu; sprawdź zanim doinstalujesz Wordfence Premium na duplikat.

System plików. PHP wyłączone w /wp-content/uploads/ regułą <FilesMatch "\.php$"> Require all denied </FilesMatch> w .htaccess lub odpowiednikiem nginx location block. wp-config.php przeniesiony katalog wyżej tam, gdzie hosting na to pozwala. Listing katalogów off. xmlrpc.php 403, jeśli strona tego nie potrzebuje.

Filtrowanie na brzegu. ModSecurity OWASP CRS na paranoia level 1, z udokumentowanymi wyjątkami site-specific zamiast hurtowego wyłączenia. Custom rule blokujący znane user-agenty wp-scan i POSTy do /wp-admin/admin-ajax.php bez nagłówka nonce. Dla klientów RODO ważne jest, żeby Cloudflare miał ustawione DPA i Data Localization w EU; bez tego IOD nie podpisze rejestru czynności przetwarzania.

Detekcja, nie tylko prewencja. Codzienny diff plików core, wtyczek i motywów względem upstream zip checksumów przez WP-CLI (wp checksum core, wp checksum plugin --all). fail2ban czyta access log pod kątem ratio 200/302 na /wp-login.php, bo udany brute force pojawia się tam wcześniej niż gdziekolwiek indziej. Alerty na nowe konta admin i na zdarzenia user_register poza godzinami pracy. Dla klientów z IOD ten log idzie do osobnego rejestru audytowego; to jest dokument, który firma pokazuje UODO, jeśli dojdzie do incydentu.

#Trzy incydenty, które widzimy najczęściej

Liczba „średni koszt naruszenia to X tysięcy złotych” nie ma żadnej wartości operacyjnej, bo każde naruszenie kosztuje co innego. Wartość mają wzorce techniczne, które powtarzają się przy czyszczeniach.

Trwały admin po injection. Dziurawa wtyczka formularzy puszcza wp_insert_user() przez źle skonfigurowany endpoint AJAX. Konto dostaje rolę administrator i niewinną nazwę „Support” lub „Editor”. Przywrócenie backupu sprzed tygodnia nic nie daje, bo injection był wcześniej, a backup jest już zatruty. Polujemy na to diffem wp_users i wp_usermeta względem ostatniego czystego snapshota, nie zaufaniem do listy w panelu. Dla sklepu Allegro lub WooCommerce z integracją PSP to poważne; taki admin może wystawić faktury KSeF i podmienić dane bankowe na fakturach pro forma.

Backdoor w uploadach. Plik PHP zrzucony do /wp-content/uploads/2024/03/.cache.php przyjmuje payload base64 przez POST i wykonuje eval(). Częściowy restore samego core’a i wtyczek go nie usuwa, atakujący wraca w kilka godzin. Audyt tarballuje uploads, szuka wewnątrz .php, .phtml i .phar, weryfikuje, że na poziomie serwera PHP jest tam wyłączony.

Wyciek .env przez publiczne repo. Programista commituje .env z hasłem do SMTP relay i restricted key Stripe na publiczny mirror w GitHub. Mailer w 48 godzin staje się relayem spamerskim, hosting blackholuje port 25, a Stripe blokuje konto na czas wyjaśnienia. Recovery to rotacja obu kluczy, scrub git history (git filter-repo), pre-commit hooki blokujące commit .env. Sprawdzamy .env, .env.backup, modyfikacje wp-config-sample.php i każdy plik pod web rootem zawierający DB_PASSWORD lub wzorce _KEY.

Realny koszt to przede wszystkim czas: godziny developera na identyfikację wektora wejścia, downtime w trybie maintenance, krzywa odbudowy SEO po flagu Safe Browsing (2 do 6 tygodni do pełnego oczyszczenia) i rozmowa z klientami, jeśli w zakresie były dane osobowe. Cena audytu jest mała przy każdym z tych pojedynczych kosztów.

Potrzebujesz pomocy? Skontaktuj się z nami, żeby zaplanować audyt zakresowy, jednorazowe czyszczenie po incydencie albo monitoring z miesięcznym diffem checksumów i kwartalnym re-audytem.