Krytyczne luki w zabezpieczeniach PHP: co muszą wiedzieć właściciele witryn WordPress

English version: Critical PHP Vulnerabilities: What WordPress Site Owners Need to Know

PHP opublikowało poprawki dla dwóch krytycznych luk bezpieczeństwa 21 października 2026 roku. Aktualizacja WordPressa lub wtyczek ich nie rozwiązuje. Dowiedz się, jak sprawdzić, czy Twoje środowisko hostingowe jest zagrożone i jakie kroki podjąć.

W skrócie: co się wydarzyło

21 października 2026 roku projekt PHP opublikował poprawki dwóch krytycznych luk w środowisku wykonawczym PHP: CVE-2026-109618 i CVE-2026-109619, obie ocenione na 9,2 według CVSS v4.0. W pewnych warunkach umożliwiają one nieuwierzytelnionemu atakującemu uruchomienie kodu na serwerze WWW. Są to luki w samym PHP, a nie w rdzeniu WordPressa, motywach czy wtyczkach, dlatego poprawka musi pochodzić z poprawionej kompilacji PHP zainstalowanej na serwerze.

Zalecane działanie: Poproś swojego dostawcę hostingu o potwierdzenie, że kompilacja PHP obsługująca Twoją witrynę jest zabezpieczona przed obiema lukami. Jeśli zarządzasz serwerem samodzielnie, zainstaluj poprawiony pakiet PHP i uruchom ponownie PHP.

Ostrzeżenia projektu PHP określają je jako RCE poprzez uszkodzenie OOM (CVE-2026-109618) i RCE poprzez nieaktualny stan globalny (CVE-2026-109619). W obu przypadkach żądanie, które nie powiedzie się w nieodpowiednim momencie, może pozostawić dane wewnętrzne w nieprawidłowym stanie, który później zostanie wykorzystany przez PHP.

Skuteczny atak uruchamia kod z uprawnieniami konta, na którym działa PHP. W zależności od konfiguracji serwera, może to pozwolić atakującemu na odczytanie wp-config.php i zawartych w nim danych uwierzytelniających do bazy danych, dostęp do bazy danych lub jej modyfikację, a także na modyfikację plików i zawartości witryny. Zhakowany pracownik PHP nie daje atakującemu automatycznie dostępu do roota serwera.

Stan eksploatacji (stan na 21 października 2026 r.)

Fundacja PHP oświadczyła, że jej zespół ds. bezpieczeństwa nie znalazł funkcjonalnego exploita w kodzie proof-of-concept (PoC), który pojawił się przed publikacją, ale prace nad PoC przyspieszyły. 21 października Cloudflare, który określa luki jako „php2shell”, poinformował o zaobserwowaniu ruchu ataków wymierzonych w swoich klientów i o tym, że atakujący modyfikowali swoje ładunki, aby ominąć zabezpieczenia. Żadne ze źródeł nie podaje potwierdzonego, skutecznego włamania. Ruch ataków wskazuje na aktywne próby ataku, ale sam w sobie nie potwierdza, że jakakolwiek strona została naruszona. Będziemy aktualizować tę sekcję w miarę rozwoju sytuacji.

Kogo potencjalnie dotyczy

Potencjalnie każda strona internetowa obsługiwana przez niezaktualizowaną kompilację PHP jest zagrożona, niezależnie od wersji WordPressa, motywów i wtyczek, z których korzysta. Zalecenia projektu PHP obejmują wszystkie instalacje PHP obsługujące żądania sieciowe, w tym PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed.

Projekt PHP uważa, że najwyższe ryzyko dotyczy mod_php, gdzie zademonstrowano lukę w zabezpieczeniach, która może spowodować uruchomienie nieuwierzytelnionego żądania przed uruchomieniem jakiegokolwiek kodu aplikacji. Nie oznacza to jednak, że inne konfiguracje są bezpieczne. Każda instalacja PHP obsługująca żądania sieciowe wymaga poprawki.

Jak sprawdzić wersję PHP i status poprawki

W panelu WordPress przejdź do Narzędzia → Stan witryny → Informacje i rozwiń sekcję Serwer . Wyświetli się wersja PHP i interfejs API serwera (API) PHP obsługujący Twoją witrynę. Większość paneli sterowania hostingiem wyświetla te same informacje. Jeśli korzystasz z WP Cerber, WP Cerber → Narzędzia → Diagnostyka wyświetla również wersję PHP i interfejs API serwera.

Następujące wersje źródłowe projektu PHP zawierają poprawki:

Ważne: są to wersje upstream, a nie uniwersalny test minimalnej wersji. Dystrybucje Linuksa i dostawcy komercyjnego wsparcia długoterminowego (LTS) mogą backportować poprawki do kompilacji, które zachowują wcześniejszy numer wersji, w tym kompilacji obsługiwanych gałęzi 8.2, 8.3 i 8.4. Na przykład Ubuntu 24.04 LTS utrzymuje pakiety PHP 8.3 w łańcuchu wersji opartym na 8.3.6 i dostarcza obie poprawki w wersji pakietu 8.3.6-0ubuntu0.24.04.13. Sama ocena stanu witryny nie jest w stanie określić, czy kompilacja dostawcy zawiera obie poprawki. Sprawdź komunikat bezpieczeństwa dostawcy lub dziennik zmian pakietów albo zapytaj swojego usługodawcę hostingowego. Nie przełączaj się na zewnętrzne repozytorium pakietów PHP tylko dlatego, że numer Twojej wersji jest niższy niż numer wersji upstream z poprawkami.

PHP 7.4, 8.0 i 8.1. Zaktualizowane kompilacje tych gałęzi, oparte na backportach źródłowych projektu PHP, usuwają obie luki, zapewniając minimalne ograniczenie dla wersji wycofanych z eksploatacji, które jest węższe niż pełna poprawka wprowadzona w wersji 8.2 i nowszych. Dzięki temu ograniczeniu, proces PHP, który utracił pamięć, jest natychmiast zamykany, więc witryna, która przekroczyła limit pamięci, może wyświetlić ogólny błąd serwera zamiast ekranu błędu krytycznego WordPressa. W takich kompilacjach, stan witryny może wyświetlać ten sam numer wersji przed i po aktualizacji, dlatego należy potwierdzić poprawkę u dostawcy hostingu lub w dzienniku zmian pakietu. Aktualizacja do obsługiwanej gałęzi nadal jest zalecana.

Wsparcie dla PHP 8.2 wkrótce się zakończy. Wsparcie bezpieczeństwa projektu PHP dla PHP 8.2 zakończy się 31 grudnia 2026 roku. Jeśli aktualizujesz z PHP 7.4, 8.0 lub 8.1, wybierz PHP 8.3 lub nowszy, najpierw utwórz kopię zapasową witryny i sprawdź kompatybilność motywu i wtyczek. Możesz również poprosić swojego usługodawcę hostingowego o zaktualizowaną kompilację bieżącej gałęzi.

Dlaczego poprawka musi zostać zastosowana na serwerze

Podatny na atak kod jest częścią środowiska wykonawczego PHP, które uruchamia WordPress, a nie częścią samego WordPressa.

• Aktualizacja WordPressa nie rozwiązuje tych luk w zabezpieczeniach PHP. Aktualizacja rdzenia WordPressa, motywów lub wtyczek nie zmienia środowiska wykonawczego PHP.
• Wtyczki zabezpieczające nie są w stanie naprawić środowiska wykonawczego. Niektóre ścieżki ataku mogą zostać uruchomione przed załadowaniem WordPressa, więc żadna wtyczka nie ma szansy na sprawdzenie żądania. Reguły zapory sieciowej (WAF) na poziomie hostingu lub sieci mogą ograniczyć niektóre ścieżki ataku, ale nie zastępują w pełni łatania.
• Ustawienia zmienione z poziomu witryny nie są niezawodnym rozwiązaniem. Ostrzeżenie projektu PHP ostrzega przed poleganiem na plikach ini_set() lub FPM .user.ini w celu zastosowania zabezpieczeń konfiguracyjnych, a to samo dotyczy ustawień PHP zmienionych w wp-config.php lub przez wtyczkę. Nawet środki na poziomie serwera opisane w ostrzeżeniu ograniczają jedynie narażenie na określone ścieżki ataku i nie zapewniają bezpieczeństwa instalacji.

Uwaga dla użytkowników WP Cerber. WP Cerber działa w WordPressie. Nie może on łatać PHP ani sprawdzać żądania, które wyzwala jedną z tych luk, przed załadowaniem WordPressa. Z tego samego powodu logi WP Cerber mogą nie rejestrować takiej próby, więc log bez podejrzanych wpisów nie dowodzi, że witryna nie była celem ataku. WP Cerber nadal chroni WordPressa na poziomie aplikacji, ale nie zastępuje aktualizacji PHP.

Co teraz zrobić?

Jeśli nie zarządzasz serwerem

Dotyczy to hostingu współdzielonego i zarządzanego, gdzie dostawca jest odpowiedzialny za utrzymanie środowiska wykonawczego PHP. Poproś go o potwierdzenie, że kompilacja PHP obsługująca Twoją witrynę zawiera poprawki dla obu luk w zabezpieczeniach. Możesz wysłać to pytanie w obecnej formie:

Czy kompilacja PHP obsługująca moją witrynę jest zabezpieczona przed lukami CVE-2026-109618 i CVE-2026-109619? Czy odpowiednie procesy PHP zostały ponownie uruchomione w celu załadowania poprawionej kompilacji?

Jeśli zarządzasz serwerem VPS lub dedykowanym

1. Zaktualizuj PHP. Zainstaluj wersję z poprawkami lub pakiet dystrybucyjny lub od dostawcy, którego zalecenia lub rejestr zmian potwierdzają, że zawiera obie poprawki.
2. Zrestartuj PHP. Zrestartuj lub przeładuj PHP-FPM, Apache lub dowolną inną usługę, która obsługuje PHP dla Twoich witryn. Działające procesy robocze będą nadal korzystać ze starego pliku binarnego, dopóki nie zostaną zrestartowane.
3. Sprawdź w Site Health, czy oczekiwana kompilacja PHP obsługuje teraz każdą witrynę. Następnie sprawdź oddzielnie, w komunikacie dostawcy lub dzienniku zmian pakietu, czy zainstalowany pakiet zawiera obie poprawki. Site Health pokazuje wersję roboczą, ale nie może udowodnić, że uwzględniono backport. Polecenie php php -v może zgłosić inną instalację PHP niż ta, która obsługuje Twoją witrynę, więc nie polegaj tylko na nim.

Niezależnie od przypadku, zachowaj aktualną kopię zapasową, którą z pewnością będziesz mógł przywrócić. Jeśli podejrzewasz, że witryna została zainfekowana przed zainstalowaniem poprawki PHP, pamiętaj, że aktualizacja PHP nie usuwa złośliwego oprogramowania ani backdoorów. W takim przypadku skontaktuj się najpierw z dostawcą hostingu, ponieważ dostęp uzyskany za pośrednictwem PHP może nie ograniczać się do plików WordPressa. Aby dowiedzieć się, jak wyczyścić samą instalację WordPressa, zapoznaj się z naszym poradnikiem „Co zrobić, jeśli Twoja witryna WordPress została zhakowana” .

Często zadawane pytania

Czy mój komputer lub przeglądarka są narażone na ryzyko, gdy odwiedzam podejrzaną witrynę internetową?

Nie bezpośrednio. Luki występują w PHP na serwerze WWW, a nie w urządzeniach ani przeglądarkach użytkowników. Witryna zainfekowana tymi lukami może jednak zostać zmodyfikowana i wyświetlać złośliwą treść, co naraża użytkowników na pośrednie ryzyko.

Czy muszę ponownie zainstalować WordPressa?

Nie, nie chodzi o rozwiązanie tych luk. Można je naprawić poprzez aktualizację PHP na serwerze, a ponowna instalacja WordPressa nie zmienia PHP. Ponowna instalacja może być nadal częścią oczyszczania witryny, która została zainfekowana.

Czy mogę rozwiązać ten problem bez pomocy dostawcy hostingu?

Zależy to od tego, czy kontrolujesz środowisko wykonawcze PHP. Na serwerze VPS lub dedykowanym możesz samodzielnie zainstalować załatane pakiety. Na hostingu współdzielonym lub zarządzanym, kontrolę nad PHP sprawuje host. Wiele paneli sterowania pozwala na zmianę wersji PHP na stronie, ale to, czy kompilacja zostanie załatana, nadal zależy od hosta.

Źródła

• Projekt PHP, Komunikat o bezpieczeństwie: Krytyczne luki w zabezpieczeniach umożliwiające zdalne wykonanie kodu, aktualizacja teraz , 21 października 2026 r.
• Projekt PHP, GHSA-w8hw-w9fx-j79w: RCE poprzez uszkodzenie OOM (CVE-2026-109618) , 21 października 2026 r.
• Projekt PHP, GHSA-6wmf-4rv5-p3rp: RCE poprzez nieaktualny stan globalny (CVE-2026-109619) , 21 października 2026 r.
• Fundacja PHP, Dzisiejsze wydanie zabezpieczeń PHP i jak wzmacniamy bezpieczeństwo PHP , 21 października 2026 r.
• Projekt PHP, Obsługiwane wersje .
• commit php-src 712e60f: Unikanie korupcji państwa poprzez ratowanie , minimalne zabezpieczenie dla wersji wycofanych z eksploatacji.
• Repozytorium RPM Remi'ego, dziennik zmian php74-php , wpis dla wersji 7.4.33-31, 21 października 2026 r.
• Ubuntu, strony ze stanem bezpieczeństwa dla CVE-2026-109618 i CVE-2026-109619 , 21 października 2026 r.
• Cloudflare, Cloudflare wdraża zabezpieczenia przed luką w zabezpieczeniach php2shell , 21 października 2026 r.