WordPress jako najpopularniejszy system zarządzania treścią jest w centrum zainteresowania atakujących. Otwarty kod źródłowy, łatwość przetestowania opracowanego scenariusza ataku w lokalnych środowiskach czy wreszcie duża szansa na odnalezienie podatnego celu sprawiają, iż ta sytuacja gwałtownie nie ulegnie zmianie. Nie bez znaczenia pozostaje też kwestia wielu małych serwisów czy nieutrzymywanych od dawna blogów, które lata świetności mają już za sobą, a które to wciąż są publicznie dostępne. Przestarzałe wersje systemu WordPress, motywów i wtyczek znacząco zwiększają perspektywę skutecznego ataku.
Bieżące aktualizacje WordPress i powiązanych komponentów wdrażane w przemyślany sposób, minimalizacja ilości różnych „wtyczek” wraz z zastosowaniem odpowiedniej konfiguracji serwera, a najlepiej dodatkową ochroną WAF są poprawnym podejściem do bezpieczeństwa. Należy znaleźć „złoty środek” i wdrożyć kilka zabezpieczeń, ale jednocześnie nie przekładać często teoretycznej ochrony nad wydajność i dostępność naszych serwisów.
Niestety niektórzy po ostatniej serii podatności zaczęli zbyt pochopnie oceniać nowo odkrywane luki. Statusy „High” czy „Critical” otrzymują zaawansowane błędy, których użycie nie polega na wykonaniu udostępnionego exploita, a raczej na mozolnym dopracowywaniu skryptów pod konkretne konfiguracje. Przecenione podatności wywołują reakcje branżowych mediów, dla których nie liczy się rzetelne przekazanie informacji, a szybkie napisanie artykułu bez głębszego zrozumienia danego tematu. Coraz mniej liczy się praktyczne użycie podatności. Teraz wystarczy, iż luka występuje w znanym oprogramowaniu i niemal automatycznie nadane zostaje jej wysokie „severity”.
Tak właśnie stało się z podatnością CVE-2026-119977. W oficjalnej bazie CVE przypisano jej status High (na podstawie analizy Wordfence), a zespół odpowiedzialny za rozwój systemu WordPress pozostawił we własnej bazie zdroworozsądkową ocenę Low. Użycie tej luki ma poważną konsekwencję, jaką jest zdalne wykonanie kodu – tutaj oczywiście na prawach użytkownika wykonującego kod PHP, czyli posiadającego dostęp do plików serwisu. Jednak możliwość wykorzystania jest znacznie ograniczona. Atakujący musiałby odpytać odpowiedni plik podczas aktualizacji WordPress w niemal perfekcyjnym momencie, aby w ogóle możliwe stało się przeprowadzenie RCE.
Oczywiście można przygotować proste narzędzie, które w niewielkich odstępach czasu próbowałoby przeprowadzić atak, bo w końcu ktoś tę aktualizację wykona. W profesjonalnych wdrożeniach WordPress szanse są jednak zerowe przynajmniej z dwóch powodów.
Przede wszystkim praktyka aktualizacji systemu WordPress bezpośrednio z poziomu Kokpitu jest błędna. Kod całego CMS powinien być przechowywany w repozytorium, a wdrożenia odbywać się z wykorzystaniem CI/CD. Programista wykonuje aktualizację na lokalnym środowisku, weryfikuje wprowadzone zmiany i dopiero wtedy wysyła zmiany do repozytorium. Następnie poprzez CI/CD aktualizacja zostaje wdrożona na środowisku produkcyjnym (a najlepiej wcześniej dodatkowo sprawdzona na osobnym środowisku testowym). Pozwala zachować to pełną kontrolę nad niezależnymi od naszego zespołu modyfikacjami, które zostały dodane przez programistów WordPress.
Oczywiście automatyczne aktualizacje WordPress powinny być zablokowane. Nie zaszkodzi również ograniczenie dostępu do sieci Internet z serwerów hostujących osiągalne z zewnątrz aplikacje. Dla podanego wyżej podejścia z automatyzacją wdrożeń nie będzie to żadną przeszkodą, bo źródłem prawdy pozostaje repozytorium Git – serwis internetowy nie powinien w ogóle inicjować pobierania zasobów z Internetu.
Dodatkowo warto skonfigurować rate limiting (w ustawieniach WAF czy choćby serwera HTTP – dla przykładu w nginx jest to bardzo proste), aby klienci nie mogli w nieskończoność odpytywać naszego serwisu. Będzie to odpowiednie rozwiązanie na próby ciągłego sprawdzania obecności podatnego pliku setup-config.php celem „trafienia” w moment aktualizacji i użycia opisywanego błędu.
Widać więc, iż stosowanie adekwatnych praktyk redukuje potencjalne ryzyko ataku. Nieocenione potrafią być rozwiązania WAF, ale spotykane są z reguły w środowiskach o dużej skali. Natomiast dla naszych mniej skomplikowanych portali czy blogów warto wybierać hostingi oferujące taką ochronę. Popularny ModSecurity może zostać zintegrowany z serwerem HTTP i żadne dodatkowe usługi nie są wymagane. Dobry WAF ochroni nas przed wykorzystaniem trywialnych błędów, takich jak pozostawiony katalog .git czy pewne pliki kojarzone z menedżerami pakietów, które to niekoniecznie powinny znajdować się na serwerze. Oprócz tego powinien zabezpieczać przed innymi poważnymi atakami charakterystycznymi dla aplikacji webowych, ale jak wiadomo nie znajdziemy w pełni skutecznego narzędzia. Kluczowa jest jednak redukcja ewentualnej powierzchni ataku.
WordPress jest bezpiecznym systemem CMS, ale z uwagi na szerokie zastosowanie jest analizowany pod kątem podatności. w tej chwili atakujący zyskali duże ułatwienie w postaci sztucznej inteligencji i mogą wykrywać błędy istniejące w kodzie od lat, które dla człowieka mogą nie być oczywiste. Twórcy każdego systemu powinni używać skanerów bezpieczeństwa (również tych zapewniających integrację z AI), aby już na wczesnych etapach zyskiwać świadomość potencjalnych problemów.
