Zaawansowane utwardzanie WordPress w 2026

Wtyczka bezpieczeństwa na zapisywalnym originie to nie utwardzanie. Utwardzanie w 2026 to tożsamość, runtime tylko do odczytu, krawędź, która odrzuca payload zanim wystartuje PHP, oraz logi, których origin nie skasuje.

WordPress 7.1 na PHP 8.4 to utrzymywana aplikacja. To też pierwsza rzecz, którą skanują atakujący, bo katalog wtyczek, xmlrpc.php i wp-login.php są przewidywalne. Incydenty, które nadal sprzątamy, to nie „WordPress jest dziurawy”. To publiczny admin, piątkowa aktualizacja z kokpitu i hosting, na którym PHP zapisuje samo siebie.

Ten przewodnik jest wersją operacyjną. Passkeys, niemutowalne obrazy, wirtualne łatanie na WAF, nonce w CSP, audyt composera, logi poza hostem. Audyt bezpieczeństwa WordPress to powierzchnia handlowa, gdy ten stos chcesz sprawdzić na swoim hoście, a nie tylko przeczytać.

#Tożsamość, passkeys i wp-admin poza internetem

Formularz logowania nadal jest najtańszym atakiem. Masowe logowanie skradzionymi parami login-hasło nie potrzebuje zero-daya. Potrzebuje wp-login.php w otwartym internecie i administratora, który użył hasła z wycieku.

Passkeys (WebAuthn) wiążą ceremonię z urządzeniem i z originem. Fałszywa domena jej nie kończy. Dlatego wymuszamy passkeys na każdym koncie, które instaluje wtyczki albo edytuje PHP w edytorze motywu (ten edytor też ma być wyłączony). Hasła aplikacyjne dla CI siedzą w magazynie sekretów, nie w menedżerze haseł marketingu.

Nie zostawiaj logowania hasłem jako zapasu „na wszelki wypadek” pod publicznym URL. Ten zapas jest tym, przez co phishing nadal działa. Ścieżka awaryjna to klucz sprzętowy w sejfie albo odzyskiwanie przez dostawcę tożsamości, na ścieżce, która nie jest wp-login.php.

wp-admin nie należy do publicznego internetu. Cloudflare Access, Tailscale albo to samo proxy świadome tożsamości, którego firma używa do narzędzi wewnętrznych. Anonimowy GET witryny zostaje w cache. /wp-admin i wp-login.php zwracają 403 albo wyzwanie SSO. xmlrpc.php jest wyłączony, chyba że Jetpack albo aplikacja mobilna naprawdę go potrzebuje. Wtedy allow-lista po metodzie i po IP, nie armata pingbacków.

Nadal widzimy sklepy, które „ukryły” wp-admin nowym sluguem logowania. To nie jest tożsamość. Crawler znajduje nowy slug w jeden dzień. Schowaj powierzchnię za tożsamością albo odpuść.

REST nie jest „bezpieczniejszy od xmlrpc” sam z siebie. /wp-json/wp/v2/users enumeruje loginy na wielu instalacjach z domyślnymi prawami. Hasła aplikacyjne dla frontu headless mają być ograniczone zakresem i rotowane. Endpoint użytkowników jest GET z powodu blogów publicznych. Na sklepie to prezent. Wyłącz go albo wymagaj auth. To samo z przekierowaniami ?author=1, które wyciekają admin jako nicename.

Limitowanie logowania w PHP to sposób, by zrobić sobie DDoS. Tę robotę robi WAF albo Access. Jeśli musisz zostawić publiczne logowanie dla subskrybentów (serwis członkowski), administratorzy i tak idą przez Access na innym hoście. Jeden wp-login.php dla wszystkich to zalew logowań, który zamyka redaktora poza własną stroną.

Na polskim hostingu współdzielonym ten błąd siedzi w panelu. Konto FTP dla „grafika, który wgrywa ZIP motywu”, wp-admin bez żadnego SSO, xmlrpc włączony, bo tak wyszło przy instalacji. home.pl, cyberFolks i LH.pl sprzedają ten układ jako stronę firmową. Publiczny kokpit plus zapisywalne FTP to nie konfiguracja, którą da się utwardzić wtyczką. Najpierw zdejmij admina z internetu. Potem rozmawiaj o passkeys.

#Runtime tylko do odczytu

Aktualizacja z kokpitu to decyzja bezpieczeństwa. Wygląda na wygodę. Jest zapisem na produkcję przez kogoś, kto ma ciasteczko administratora.

Traktuj drzewo PHP jako tylko do odczytu. WordPress startuje z obrazu (kontener albo rsync artefaktu z CI). wp-content/plugins i wp-content/themes są w tym obrazie. Jedyny zapisywalny wolumen to uploady, i ten wolumen nie wykonuje PHP. Jeśli RCE we wtyczce próbuje zrzucić wp-content/uploads/cache.php, zapis pada albo plik nie leży na ścieżce wykonywalnej.

Aktualizacje idą wtedy przez git:

1. Dependabot albo zaplanowany bump composera otwiera PR.
2. CI odpala phpstan, test dymny i skan CVE lockfile.
3. Obraz jest budowany i wdrażany. Poprzedni obraz zostaje do rollbacku.

Żywy serwer nigdy nie jest „edytowany”. To też zabija klasę malware, która trzyma się zapisu do wp-config.php albo must-use, którego kokpit nie listuje.

Użytkownik bazy: SELECT, INSERT, UPDATE, DELETE na schemacie witryny. Bez DROP, bez FILE, bez GRANT. TLS do MySQL. Prefiks tabel to nie kontrola. To drobiazg, który ktoś nadal sprzedaje jako hardening.

Object cache (Redis) trzyma sesje i transients. Traktuj go jak magazyn sekretów. Izolacja sieci, AUTH, zero publicznego portu. „Flush all” ze skompromitowanego admina to incydent dostępności. Rozdziel cache sesji od cache fragmentów HTML, jeśli możesz. Widzieliśmy wtyczkę, która włożyła token resetu hasła do wspólnego Redis, a inna witryna na tym samym hoście go przeczytała. To błąd układu hostingu, nie błąd WordPressa, i i tak ląduje na Twoim kanale incydentów.

Klucze z wp-config.php (AUTH_KEY i reszta) rotujesz, gdy podejrzewasz kradzież ciasteczka. Stare sesje giną. Klucze w środowisku, nie w obrazie, znaczą, że wycieknięte repo to nie wycieknięte logowanie. Obraz i tak musi umieć wystartować. Magazyn sekretów platformy. Nie commituj .env do tego samego gita, który klonuje agencja od frontu.

Na home.pl, cyberFolks i LH.pl ten model pada na starcie, jeśli wdrożenie to FTP i „wgraj ZIP”. PHP musi mieć prawo zapisu, bo tak działa aktualizacja z kokpitu i wgrywanie mediów do katalogu, z którego Apache serwuje cokolwiek z rozszerzeniem .php. Checkbox „ochrona” w panelu tego nie zmienia. Albo wychodzisz z tego układu (obraz, wolumen uploadów bez exec, zero FTP na produkcji), albo nie masz runtime tylko do odczytu. Masz nadzieję.

#WAF i wirtualne łatanie

WAF stoi przed originem. Widzi żądanie HTTP zanim wystartuje PHP. To jedyny powód, by za niego płacić.

Do czego jest:

• Znane ścieżki exploitów: powódź na /wp-login.php, multicall xmlrpc, trasy REST, które nie powinny być anonimowe.
• Wirtualna łatka w dniu, w którym publiczne jest CVE WooCommerce albo Elementora, póki przebudowujesz obraz. Godziny, nie weekend.
• Limity, które aplikacja i tak zaimplementowałaby źle w PHP.

Do czego nie jest: zastępowanie walidacji wejścia ani bycie jedyną kopią logu dostępu.

Hosting ze „stroną WordPress w panelu” często sprzedaje „mamy WAF”. Pytanie brzmi, czy dodasz regułę tego samego dnia i czy ta reguła trafia przed PHP. Jeśli odpowiedzią jest kolejka zgłoszeń w home.pl albo cyberFolks, to nie jest wirtualne łatanie. To ticket.

Wirtualna łatka ma datę ważności. Reguła na krawędzi jest na weekend. Przebudowa obrazu jest na tydzień. Jeśli po pół roku reguła nadal jest jedyną poprawką, nie masz potoku. Masz karteczkę. Otwartą wirtualną łatkę trzymamy jako zgłoszenie z właścicielem, nie jako odznakę.

#Wordfence na originie kontra WAF na krawędzi

To wybór operacyjny, który powtarzamy, i to on oddziela tanią „wtyczkę bezpieczeństwa” od stosu, który nadal odpowiada po piątkowym CVE.

Wordfence, Sucuri plugin, iThemes działają wewnątrz PHP. Umieją skanować pliki, dławić wp-login, wysłać maila. Startują, gdy żądanie już doszło do originu. Payload, który eksploatuje workera PHP przed hakiem init wtyczki, nie jest czymś, co zdążą zobaczyć. Potrzebują też zapisywalnego systemu plików na własne dane, co kłóci się z runtime tylko do odczytu.

WAF Cloudflare (albo Fastly, albo WAF przed VPS) działa na węźle cache. Anonimowy GET zostaje trafieniem cache. POST pasujący do sygnatury CVE nie dochodzi do PHP. Wirtualne łatanie to push reguły, nie aktualizacja wtyczki. Obraz originu zostaje tylko do odczytu.

Reguły, których używamy:

• Logowanie i xmlrpc tylko z Access albo zablokowane. POST witryny (checkout, konto) idzie przez WAF z zestawem reguł WordPress plus własnym skipem dla webhooków płatności, które naprawdę masz (Przelewy24, PayU, Blik). Hurtowy skip /wp-admin/admin-ajax.php to sposób, by zepsuć własny WAF.
• Wordfence, jeśli w ogóle zostaje, jest skanerem w CI albo na klonie stagingu, nie firewallem runtime na produkcji. Dwa firewalle, które oba uważają, że są właścicielem limitów, zablokują klientów i i tak przegapią CVE.
• Integralność plików: porównuj wdrożony obraz z gitem, nie wtyczkę chodzącą po wp-content przy każdym cronie. Cron na originie to kolejny proces PHP, którego nie potrzebowałeś.

Sklep WooCommerce, który odbudowaliśmy w 2025, miał Wordfence „na wysokiej czułości”, Cloudflare „I’m under attack” na tym samym URL i piksel marketingowy POSTujący na admin-ajax. Checkout z Blikiem padał przez dzień, bo skip nie objął webhooka Przelewy24, a Wordfence uznał powtórzone POSTy bramki za brute force. CVE, którego się bali, załataliśmy na krawędzi jedną regułą. Wojna wtyczek była awarią.

Listy skipów to miejsce, w którym WAF-y umierają. /wp-admin/admin-ajax.php, /?wc-ajax=, webhook Przelewy24, PayU, weryfikacja domeny Apple Pay, callback Blika. Każdy skip jest spisanym wyjątkiem z powodem. Skip „bo zepsuł się pasek cookies” otwierający admin-ajax na świat to sposób, by tania wtyczka znów stała się RCE na originie.

#CSP i nonce

Content-Security-Policy to przeglądarka, która odmawia uruchomienia skryptu, którego nie wysłałeś. XSS we wtyczce nadal się zdarza. CSP jest tym, co zatrzymuje ten skrypt przed wywołaniem na zewnątrz.

Polityka, która na motywie WordPress działa w praktyce:

• default-src 'self'
• script-src 'self' 'nonce-…' plus dwa albo trzy originy płatności, które umiesz nazwać (Przelewy24, PayU, Blik, ewentualnie Stripe)
• style-src 'self' 'unsafe-inline' dopóki nie zhashujesz motywu (unsafe-inline na stylu jest kompromisem; nie kopiuj go na skrypt)
• frame-ancestors 'none', chyba że naprawdę osadzasz witrynę
• object-src 'none'
• base-uri 'self'

Nonce musi się zmieniać co odpowiedź. Statyczny nonce w wp_head to teatr. HTMLRewriter na krawędzi albo mu-plugin, który drukuje nagłówek i pasujące atrybuty, oba działają. Katalog wtyczek jest pełen „dodaj CSP”, które emitują 'unsafe-inline' na skrypcie. Ta polityka nie zatrzymuje XSS. Dokumentuje, że ktoś próbował.

Najpierw Report-Only. Czytaj raporty przez tydzień. Potem enforce. W raporcie będą Tag Manager, platforma zgód (Cookiebot, Complianz, CookieYes) i widget płatności. Każdy wpis to decyzja: pozwolić po originie albo zdjąć z pierwszej strony.

CSP nie zastępuje esc_html i nonce na formularzach. Jest ostatnim płotem.

#CERT Polska, KSC i obowiązek zgłoszenia

Utwardzanie produkuje dowód. Zgłoszenie incydentu jest osobnym zdarzeniem, z innymi zegarami i innym adresatem. Polskie sklepy na WordPressie mieszają te dwie rzeczy: albo milczą, bo „to tylko złośliwy kod we wtyczce”, albo wysyłają do CERT Polska zrzut maila z Wordfence bez osi czasu.

Tu są dwa pytania, nie jedno. To nie jest porada prawna. To lista faktów, które musisz umieć odtworzyć, zanim ktokolwiek napisze pismo.

Dane osobowe i UODO. Jeśli w incydencie mogły uczestniczyć dane klientów (konta, zamówienia WooCommerce, zgody, faktury), w grę wchodzi RODO. Zgłoszenie naruszenia ochrony danych do UODO ma zegar 72 godzin od momentu, w którym administrator danych się o naruszeniu dowiedział, o ile naruszenie może skutkować ryzykiem dla praw osób. Nie każdy zainfekowany popup jest naruszeniem danych. Wyciek tabeli zamówień jest. Inżynieria na ten zegar wygląda tak: wiesz, które tabele trzymają dane osobowe, wiesz, czy atakujący miał SELECT na te tabele, masz logi spoza originu. Nie zgadujesz po fakcie z panelu home.pl, którego logi już wygasły.

Operator i KSC. Ustawa o krajowym systemie cyberbezpieczeństwa, z transpozycją NIS2, nakłada na podmioty kluczowe i ważne obowiązki operatora: nazwany kontakt, logowanie, zgłoszenie incydentu do właściwego CSIRT. CERT Polska (NASK) jest krajowym CSIRT, z którym wielu operatorów rozmawia. Czy Twoja firma w ogóle jest takim podmiotem, a agencja utrzymująca cudzy WordPress zbliża się do definicji dostawcy usług zarządzanych, to kwalifikacja prawna. Ten tekst jej nie robi. Nie jest też ustawieniem wtyczki. Powierzchnia tej rozmowy jest w audycie NIS2 i DORA.

CERT Polska robi jeszcze jedną rzecz, której kokpit WordPressa nie robi: publikuje ostrzeżenia o aktywnie wykorzystywanych lukach, w tym we wtyczkach CMS. Operator, który patrzy tylko na ekran „Aktualizacje” w wp-admin, dowiaduje się w piątek. Operator, który czyta cert.pl, może wstawić wirtualną łatkę we wtorek i przebudować obraz, zanim exploit wejdzie do skanerów.

Zgłoszenie, które da się czytać, ma konkret. Kiedy. Jaki URL. Jaka wtyczka albo jakie CVE, jeśli już je znasz. Czy wp-admin był publiczny. Czy uploady wykonywały PHP. Czy atakujący mógł czytać zamówienia. Identyfikatory z WAF (ray id). Identyfikator wdrożenia. To wychodzi z logów poza hostem i z lockfile composera. Nie wychodzi ze screenshotu „antywirusa” w panelu cyberFolks po tym, jak shell skasował logi na originie.

Ten sam hosting, który nie umie trzymać runtime tylko do odczytu, nie umie też wyprodukować paczki na CERT albo na UODO. home.pl, cyberFolks, LH.pl: FTP z zapisem do wp-content, publiczny wp-admin, logi w panelu na kilka dni, potem cisza. Po incydencie zostaje odtworzenie z kopii, która leżała na tym samym koncie. To jest tryb awarii, przeciwko któremu ten przewodnik jest napisany. Zdejmij admina z internetu i logi z originu, zanim ktokolwiek otworzy formularz zgłoszenia. Kłócenie się o właściwy CSIRT przy otwartym FTP jest odwróconą kolejnością.

Widgety płatności nie zdejmują danych osobowych ze sklepu. Przelewy24, PayU, Blik, jeśli numer karty nigdy nie wpada do WordPressa, to osobna rozmowa o zakresie PCI. Imię, adres, e-mail, telefon i pozycje zamówienia w tabelach WooCommerce nadal są danymi osobowymi. Zrzut tabeli zamówień jest terenem UODO nawet wtedy, gdy Blik na originie nie zobaczył PAN.

Nazwany operator. Kto odbiera telefon o drugiej w nocy. Kto ma prawo przebudować obraz. Kto mówi z CERT Polska albo z UODO. Utwardzanie bez tego nazwiska to stos reguł. Proces operatora żyje w usłudze NIS2 i DORA. Ta sekcja jest powodem, dla którego logi i lockfile muszą istnieć, zanim ktoś napisze zgłoszenie.

#Łańcuch dostaw, composer i aktualizacje z kokpitu

Większość włamań na WordPressa, które nadal widzimy, zaczyna się we wtyczce, nie w rdzeniu. Rdzeń ma proces wydania. Wtyczka z dużą liczbą instalacji może w minorze wysłać wywołanie na zewnątrz.

Co robimy:

• Wtyczki, od których zależysz, żyją w composerze (wpackagist albo prywatne lustro), więc lockfile jest spisem materiałów. „Instaluj z wp-admin” na produkcji jest wyłączone.
• CI oblewa PR, jeśli composer audit albo npm audit łańcucha motywu zgłasza znane CVE powyżej przyjętej poprzeczki. Poprzeczka to nie „tylko critical”. Zapomniany XSS w wtyczce formularza wystarczy.
• Nowa wtyczka dostaje czytanie eval, file_get_contents zdalnych URL i handlerów admin-post, zanim wejdzie do lustra. To jest godzina, nie certyfikat teatru bezpieczeństwa.
• Auto-aktualizacje na produkcji są wyłączone. Auto-aktualizacje na klonie stagingu, który promuje się tym samym potokiem, są w porządku.

Piątkowa wtyczka „małego popupu”, którą marketing wgrał, bo demo wyglądało dobrze, to nadal najczęstszy wpis na liście. Druga pozycja: dodatek do Przelewy24 albo InPost z katalogu, którego nikt nie czytał pod kątem admin-post. Trzecia: motyw-dziecko edytowany na FTP, bo „szybciej niż PR”.

Filar NIS2 i DORA jest tam, gdzie żyją obowiązki operatora w UE. Ta sekcja jest inżynierią, która te obowiązki w ogóle umożliwia: umiesz nazwać, co działa, i umiesz to przebudować.

#Logi, które przeżywają incydent

Jeśli jedyna kopia logu auth i logu błędów PHP jest na hoście, który właśnie dostał shella, nie będziesz miał osi czasu incydentu. Będziesz miał przebudowany serwer i zgadywanie. UODO i CERT Polska dostaną wtedy opis wrażeń, nie pakiet.

Strumieniuj:

• logi żądań nginx albo Cloudflare (akcja WAF, ścieżka, kraj, ray id)
• błędy PHP-FPM i slow log
• nieudane authenticate w WordPress oraz user_register / set_role
• zdarzenia wdrożeń z CI (kto wgrał który obraz)

do kubełka albo SIEM, którego rola originu nie skasuje. Retencja, po której naprawdę da się szukać: 90 dni gorących wystarcza sklepowi. Czytelnicy regulowani idą dłużej, bo tak powiedziała kancelaria, nie dlatego, że wtyczka oferowała „retencję logów”.

Alertuj na: skok 401 na wp-login (jeśli nadal jest publiczny, to już jest błąd), nowego administratora, dryf hashy plików wtyczek względem gita, rosnący współczynnik blokad WAF na trasie REST.

Nie kupuj „wykrywania anomalii AI” jako pierwszej kontroli. Pierwsza kontrola to „mamy logi” i „ktoś w poniedziałek czyta zdarzenia utworzenia admina”.

Na hostingu współdzielonym ten strumień często nie istnieje. Panel pokazuje „ostatnie logi”, potem je rotuje. Po shellu nie ma czego wyekstrahować. Dlatego logi poza hostem są w pierwszym tygodniu, nie w fazie „compliance później”.

#Co zmieniamy w pierwszym tygodniu

Pierwszy tydzień utwardzania to nie arkusz z dwudziestoma pięcioma wierszami. To krótka sekwencja, którą da się skończyć.

1. Zrzut aktualnej listy wtyczek i ostatnich aktualizacji z kokpitu. To miejsce zbrodni, jeśli coś już jest nie tak.
2. Access przed wp-admin. Passkeys obowiązkowe dla administratorów. xmlrpc wyłączony, jeśli nieużywany.
3. Stop instalacji wtyczek na produkcji. Otwórz ścieżkę composera, nawet jeśli pierwszy commit tylko pinuje to, co już jest.
4. Dodaj zarządzany zestaw reguł WAF i jedną wirtualną łatkę, którą umiesz nazwać (ostatnie CVE z Twojej listy wtyczek).
5. Wyślij CSP w Report-Only. Przeczytaj raport. Widget Przelewy24 i pasek zgód będą pierwsi.
6. Wyślij logi poza host. Potwierdź, że wczorajsze nieudane logowanie da się wyciągnąć bez SSH na origin.

Potem obraz staje się tylko do odczytu. Ten krok na końcu, bo łamie przepływy „edycja w wp-admin”, których nikt nie spisał. Spisz je najpierw, albo w sobotę wycofasz flagę tylko do odczytu.

Redaktor, który wkleja do bloku wielokrotnego użytku, marketing, który instaluje „jednego małego” popupa, freelancer z prawem administratora, bo „musi wgrać PDF”: te trzy konta są pozostałą ścieżką zapisu. Dwoje z nich powinno być editor albo rolą, która nie instaluje wtyczek. PDF idzie do uploadów, które nie wykonują PHP. Jeśli potrzebują nowej wtyczki, to jest PR, nie piątek.

Kopie zapasowe to nie utwardzanie, ale to sposób, by wyjść z incydentu. Poza originem, wersjonowane, restore sprawdzony na klonie, który nie jest produkcją. Kopia, która żyje tylko na tym samym VPS albo na tym samym koncie home.pl, jest drugim egzemplarzem tego samego dysku. Odtwarzamy klon stagingu, zanim nazywamy robotę skończoną, bo kopia, której nigdy nie odtworzyłeś, jest plikiem, nie planem.

#Audyt i dalsza lektura

Audyt bezpieczeństwa WordPress to tożsamość, runtime, krawędź i logi na Twoim faktycznym hoście, nie generyczna lista kontrolna. Najpierw otwieramy ekspozycję wp-admin i lockfile wtyczek. Wynik w stylu Lighthouse nie jest sygnałem bezpieczeństwa.

Obowiązki operatora w UE (logi, zegary incydentu, nazwane kontakty) siedzą w audycie NIS2 i DORA. Architektura, która zmniejsza PHP na publicznym originie, jest w przewodniku po architekturze headless. Headless sam z siebie nie jest kontrolą bezpieczeństwa. Jest mniejszą powierzchnią PHP, jeśli front jest statyczny, a wp-admin prywatny.

#Podsumowanie

Rdzeń WordPressa nie jest słabym ogniwem. Słabe ogniwo to publiczne logowanie, zapisywalny dysk, wtyczka bezpieczeństwa, która startuje po PHP, i logi, które giną z hostem. Passkeys, wp-admin świadomy tożsamości, obraz tylko do odczytu, WAF, który umie wirtualnie łatać, CSP z prawdziwym nonce, lockfile i logi poza hostem. To jest lista. Strona wtyczki z napisem „chronione” na niej nie leży.

Jeśli ten stos ma być sprawdzony, pisz z URL, listą wtyczek i informacją, czy wp-admin jest publiczny. Audyt bezpieczeństwa jest powierzchnią handlową.

PCI, ISO 27001: żadne z tego nie jest wtyczką. PCI znaczy, że dane karty nigdy nie siedzą w WordPressie. ISO to proces operatora wokół tego, co ten przewodnik już wymienia. Odznaka w stopce nie jest raportem z hostingu.

Na polskim sklepie do tej listy dokładają się dwa zegary, których wtyczka nie obsłuży: 72 godziny do UODO, gdy w grę wchodzą dane osobowe, oraz obowiązek operatora KSC wobec CSIRT, gdy w ogóle jesteś takim podmiotem. CERT Polska nie zastąpi WAF. Nie zastąpi też lockfile. Jest adresatem, gdy już masz oś czasu.