Krótko: Aktualizacja WordPressa nie pomaga przy luce PHP2Shell, ponieważ błąd nie tkwi w WordPressie, lecz w PHP, oprogramowaniu na serwerze, które WordPress wykonuje. Według Dr. Web WordPress.org nie planuje więc własnej aktualizacji. Ochronić może tylko aktualizacja PHP na serwerze z restartem wszystkich procesów PHP. Zwykle instaluje ją Państwa dostawca hostingu lub operator serwera.
Punkt wyjścia: „Przecież wszystko zaktualizowaliśmy”
Po pierwszych nagłówkach o PHP2Shell wielu operatorów zrobiło to, co oczywiste: otworzyło panel WordPressa, kliknęło „Aktualizuj teraz”, a razem z tym wtyczki i motywy. Potem wszystko jest zielone i uczucie mówi: załatwione.
Przy tej luce to uczucie myli. Nie leży to w WordPressie, lecz w miejscu, w którym tkwi błąd. Także Cloudflare zwraca w swoim komunikacie uwagę, że aktualizacja kodu aplikacji lub wtyczek nie usuwa luk.
Aktualizacja WordPressa a luka PHP: model warstw
Strona WordPress składa się z kilku warstw, które na sobie bazują. Każda warstwa ma własne aktualizacje i często własnych odpowiedzialnych:
| Warstwa | Przykład | Kto zwykle aktualizuje | Dotknięta przez PHP2Shell? |
|---|---|---|---|
| System operacyjny | Debian, Ubuntu, AlmaLinux | dostawca hostingu lub administrator serwera | nie, ale często dostarcza pakiet PHP |
| Serwer WWW | Apache, Nginx, LiteSpeed | dostawca hostingu lub administrator serwera | tryb pracy wpływa na ryzyko |
| Środowisko PHP | PHP-FPM, mod_php | dostawca hostingu lub administrator serwera | tak, tu leży luka |
| Rdzeń WordPressa | WordPress | operator lub agencja | nie |
| Wtyczki i motywy | WooCommerce, page builder | operator lub agencja | nie |
Przycisk aktualizacji w panelu sięga tylko dwóch dolnych wierszy. Środowisko PHP leży pod nimi i jest dla WordPressa niewidoczne. Jak inne systemy bazują na PHP, opisuje artykuł CMS-y i sklepy na PHP.
Dlaczego WordPress nie może zamknąć luki
Można by sądzić, że WordPress może przecież „programować wokół”. Przy PHP2Shell nie działa to z dwóch powodów.
Po pierwsze oba błędy tkwią w sposobie, w jaki PHP przetwarza żądania i potem sprząta. Dzieje się to niezależnie od tego, jaki program działa w PHP. Po drugie zespół PHP pokazał dla Apache z mod_php exploit, który działa, zanim w ogóle zostanie wykonany kod aplikacji. WordPress, jego wtyczki i każda wtyczka bezpieczeństwa w ogóle nie dochodzą wtedy do głosu.
Z tego samego powodu nie pomoże też „wtyczka utwardzająca”, która zmienia ustawienia przez ini_set(). php.net wyraźnie odradza ustawianie tą drogą środków przejściowych.
A w Managed WordPress?
W ofertach Managed WordPress dostawca często dba nie tylko o aktualizacje WordPressa, ale także o serwer pod spodem. Dla PHP2Shell jest to zaleta, ale nie automatyzm. Proszę zapytać konkretnie, czy aktualizacja PHP została zainstalowana i wszystkie procesy PHP zrestartowane. Wypowiedź „Utrzymujemy Państwa WordPressa w aktualności” nie odpowiada na to pytanie.
Wiele stron, jedna instalacja PHP
Agencje i firmy z kilkoma stronami powinny znać pewną osobliwość: na jednym serwerze wiele instalacji WordPressa dzieli często tę samą wersję PHP. Jeśli jest niezałatana, dotknięte są wszystkie, niezależnie od tego, jak dobrze utrzymywana jest każda pojedyncza strona. Odwrotnie, aktualizacja PHP chroni wszystkie instalacje naraz, o ile po niej zrestartowane zostaną wszystkie należące do nich procesy PHP. Kto prowadzi równolegle kilka wersji PHP, musi zaktualizować każdą osobno.
Zielony panel WordPressa nic nie mówi o PHP2Shell. Decydujący jest stan poprawek PHP na serwerze i restart wszystkich procesów PHP.
Jak prawidłowo odczytać wersję PHP w WordPressie
WordPress pokazuje wersję PHP: w panelu pod Narzędzia, Kondycja witryny, w zakładce Informacje w sekcji Serwer. To dobra pierwsza wskazówka, ale nie dowód.
Jeśli widnieje tam gałąź taka jak 8.1 lub starsza, jest to wyraźny sygnał ostrzegawczy, bo dla niej nie ma już oficjalnych aktualizacji. Jeśli widnieje tam 8.2.35, 8.3.36, 8.4.27 lub 8.5.12, zainstalowany jest naprawiony stan. Jeśli widnieje tam starszy numer wspieranej gałęzi, mimo to może być zainstalowany backport. Dystrybucje i dostawcy hostingu często nie zmieniają przy tym numeru. Jasność daje tylko potwierdzenie dostawcy hostingu lub spojrzenie do changelogu pakietu. Jak to zrobić, opisuje strona Sprawdzanie wersji PHP i stanu poprawek.
Co zamiast tego powinni zrobić operatorzy WordPressa
- Zapytać dostawcę hostingu lub operatora serwera: Czy PHP jest załatane, kiedy i czy wszystkie procesy PHP zostały zrestartowane? Odpowiedź na piśmie.
- Sprawdzić gałąź PHP: Jeśli strona działa na 8.1 lub starszym, zaplanować przejście na wspieraną gałąź. Którą wersję wspiera Państwa wersja WordPressa, podano w wymaganiach systemowych na wordpress.org. Zmianę w menu klienta opisuje artykuł Zmiana wersji PHP w panelu klienta hostingu.
- Sprawdzić ślady: nowe pliki PHP w
wp-content/uploads, nieznane konta administratorów, obce wpisy wmu-plugins. Typowe kryjówki opisuje strona WordPress i PHP2Shell. - Mimo to utrzymywać WordPressa w aktualności: Rdzeń, wtyczki i motywy zamykają inne luki. To pozostaje obowiązkiem, tyle że innym.
- Wyjaśnić odpowiedzialność: Jeśli stroną opiekuje się agencja, zapisać, czy odpowiada także za PHP, czy tylko za WordPressa.
Właśnie ostatni punkt często powoduje luki. Agencja dba o WordPressa, dostawca hostingu o serwer, a każdy sądzi, że drugi ma PHP2Shell na oku.
Jak konkretnie pomaga PHP SOS?
- Wyjaśnienie warstw: Ustalamy, kto przy Państwa stronie WordPress odpowiada za którą warstwę.
- Aktualizacja PHP: Na własnych lub zarządzanych serwerach instalujemy aktualizację PHP i restartujemy wszystkie procesy.
- Sprawdzenie WordPressa: Szukamy śladów ataku w plikach, bazie danych i kontach.
- Dowód: Otrzymują Państwo stan poprawek na piśmie, także do przekazania agencji lub klientom.
Przebieg opisuje usługa łatania PHP.
Podsumowanie
Aktualizacja WordPressa to dobra pielęgnacja, ale przy PHP2Shell niewłaściwa warstwa. Luka siedzi piętro niżej, w PHP na serwerze. Kto to rozumie, zadaje właściwe pytanie we właściwym miejscu: Czy PHP jest załatane, zrestartowane i udokumentowane?
Częste pytania
Czy WordPress wyda aktualizację bezpieczeństwa przeciw PHP2Shell?
Według Dr. Web WordPress.org nie planuje aktualizacji przeciw PHP2Shell, ponieważ luka leży w interpreterze PHP na serwerze. Pomoże tylko aktualizacja PHP przeprowadzona przez dostawcę hostingu lub operatora serwera.
Gdzie w WordPressie zobaczę wersję PHP?
W panelu pod Narzędzia, Kondycja witryny, w zakładce Informacje w sekcji Serwer. Wyświetlany numer nie mówi jednak pewnie, czy poprawka jest zainstalowana, ponieważ dostawcy hostingu często wbudowują poprawki jako backport bez nowego numeru wersji.
Czy wtyczka bezpieczeństwa chroni przed PHP2Shell?
Tylko w bardzo ograniczonym stopniu. Wtyczka sama działa w PHP i staje się aktywna dopiero po załadowaniu WordPressa. W przypadku Apache z mod_php zespół PHP pokazał exploit, zanim w ogóle uruchomi się kod aplikacji. Tam wtyczka nie może interweniować.
Czy mimo to powinienem zaktualizować WordPressa?
Tak. Aktualne wersje WordPressa, motywów i wtyczek zamykają inne luki i są częścią dobrej pielęgnacji. Nie rozwiązują tylko problemu PHP2Shell.