21 października 2026 r. projekt PHP wydał poprawki dwóch krytycznych luk. Tego samego dnia WordPress wezwał właścicieli stron do pilnej aktualizacji PHP, wyjaśniając, że nie planuje z tego powodu aktualizacji samego WordPressa. Dwa dni później PHP opublikowało jeszcze dodatkowe zalecenie.
Skąd PHP w wiadomości o WordPressie? I dlaczego aktualny panel strony nie wystarcza, żeby zamknąć ten temat? Żeby zrozumieć alarm, trzeba zajrzeć pod aplikację, w której zmieniasz teksty i dodajesz zdjęcia.
Stan informacji: 23 października 2026 r. Poniżej rozdzielamy naprawę dwóch luk z 21 października od dodatkowego komunikatu z 23 października.
PHP działa pod WordPressem
WordPress to aplikacja do zarządzania stroną. PHP jest językiem, w którym działa jej kod, oraz oprogramowaniem potrzebnym do jego uruchomienia na serwerze. Serwer to komputer lub środowisko hostingowe obsługujące witrynę. Oficjalne wymagania WordPressa wymieniają obsługę PHP jako część takiego zaplecza.
Jak wygląda ta zależność? Korzystasz z panelu WordPressa, ale jego działanie opiera się na PHP uruchamianym przez hosting. PHP wykonuje kod po stronie serwera i może przygotować treść strony, którą otrzyma przeglądarka. Tak opisuje to dokumentacja PHP: odwiedzający dostaje wynik wykonania programu, a nie jego kod źródłowy.
Dlatego WordPress i PHP mają osobne wersje oraz aktualizacje. Zmiana w aplikacji lub jej wtyczce nie jest automatycznie wymianą oprogramowania, które tę aplikację uruchamia. Przy obecnym alarmie znaczenie ma właśnie ta warstwa pod spodem, a nie tylko to, czy w panelu zniknęły powiadomienia o aktualizacjach.
Co pozwalają zrobić wykryte luki
Komunikat PHP z 21 października opisuje dwie podatności umożliwiające zdalne wykonanie kodu bez wcześniejszego zalogowania. NHS England Digital, w niezależnym alercie, potwierdza ryzyko wykonania kodu lub dostępu do wrażliwych danych w pamięci serwera.
Po ludzku: atakujący może doprowadzić do uruchomienia własnych instrukcji w środowisku, które powinno wykonywać kod strony. To poważniejszy problem niż błędnie wyświetlony przycisk czy niedziałająca podstrona. Nie oznacza jednak automatycznie przejęcia całego serwera ani wszystkich danych każdej firmy.
Obie luki dotyczą błędów w obsłudze pamięci przez PHP: jedna wiąże się z sytuacją braku pamięci, druga z pozostawieniem stanu odwołującego się do pamięci, która została już zwolniona. Nie musisz znać ich mechaniki, żeby zrozumieć najważniejszą różnicę: problem tkwi w oprogramowaniu wykonującym aplikację. Nie naprawisz go samą zmianą hasła do panelu.
Których stron dotyczy alarm
PHP wskazuje instalacje obsługujące żądania internetowe. WordPress jest jednym z zastosowań PHP, ale nie jedynym. Jego oficjalny komunikat podkreśla, że podatności nie są specyficzne dla WordPressa i mogą dotyczyć innych aplikacji PHP na serwerze.
Trzeba odróżnić podatną instalację od potwierdzonego włamania. Ostrzeżenie mówi o możliwości wykorzystania błędu. Samo posiadanie strony na WordPressie nie dowodzi, że ktoś już ją zaatakował. Z drugiej strony prawidłowo wyglądająca strona nie pokazuje, jaką wersję PHP uruchamia hosting i jakie poprawki zastosowano.
Nie każda witryna korzysta z PHP. Jeśli sama aplikacja strony go nie używa, nie jest tą podatną instalacją PHP opisaną w ostrzeżeniu. Trzeba jednak sprawdzić rzeczywistą architekturę: strona może być połączona z osobnym sklepem, panelem lub inną usługą. Sama nazwa technologii głównej witryny nie opisuje całego tego zestawu.
Co naprawiono 21 października, a co dodano 23 października
Dwie krytyczne luki naprawiają wydania PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12, każde w swojej gałęzi. PHP zaleca pilną aktualizację. Dostawcy systemów i długoterminowego wsparcia mogą dostarczać własne pakiety z przeniesionymi poprawkami, więc stan konkretnego serwera należy potwierdzić u dostawcy.
To również wyjaśnia, dlaczego WordPress nie zapowiedział osobnej łatki swojej aplikacji dla tych problemów. Naprawa musi trafić do PHP. Aktualizacja wtyczek czy samego WordPressa pozostaje innym zadaniem.
Komunikat z 23 października dotyczy dodatkowego, wąskiego przypadku. Pod nazwą „Session upload progress” PHP opisuje rzadkie połączenie konfiguracji serwera i zachowania aplikacji. Zaleca tymczasowe wyłączenie określonej funkcji do następnego regularnego wydania naprawczego. Wskazuje zarazem, że aplikacje, które nie zmieniają sposobu obsługi sesji podczas działania, mogą pozostawić tę funkcję włączoną.
Wniosek jest ograniczony, ale istotny: samego zdania „wgraliśmy wersję z 21 października” nie traktowałbym jako potwierdzenia sprawdzenia wszystkich późniejszych zaleceń. Trzeba uwzględnić również komunikat z 23 października. Ocenę tego przypadku powinien wykonać administrator, bez samodzielnego przestawiania parametrów przez właściciela firmy.
Co odpada, gdy aplikacja strony nie korzysta z PHP
Własna witryna Falcon Works działa w Next.js. Sprawdzony kod i sposób jej uruchamiania nie opierają się na PHP. W samej tej aplikacji nie ma zatem warstwy wymagającej opisanych poprawek PHP. Przy tym konkretnym alarmie to praktyczna różnica architektury, a nie obietnica ogólnej odporności.
Inny stos technologiczny ma własne zależności i zadania związane z bezpieczeństwem. Dokumentacja Next.js również opisuje wymagane kontrole. Dlatego nie wyciągałbym z tego newsa wniosku „każdy WordPress jest niebezpieczny, a każda inna strona bezpieczna”.
W Falcon Works budujemy strony firmowe w Next.js. Dobór rozwiązania oraz zakres jego dalszego utrzymania ustalamy dla konkretnego projektu. Przykład naszej witryny pokazuje jedną rzeczywistą różnicę, bez przesądzania o wszystkich stronach klientów i ich usługach zewnętrznych.
Jeden krok dla właściciela strony
Poproś hosting lub administratora o potwierdzenie, czy Twoja instalacja korzysta z podatnego PHP, jakie poprawki wdrożono i czy sprawdzono dodatkowe zalecenie z 23 października. Dołącz oba komunikaty projektu PHP. Zacząłbym od ustalenia tych faktów o obecnej stronie, zanim podejmiesz decyzję o jej przebudowie.
Źródła
- PHP: komunikaty bezpieczeństwa z 21 i 23 października 2026 r. oraz wprowadzenie do PHP.
- WordPress: Critical PHP Security Release, 21 października 2026 r., oraz wymagania środowiska.
- NHS England Digital: Critical Vulnerabilities in PHP, CC-4875, 21 października 2026 r.
Informacje sprawdzone 23 października 2026 r. Przed naprawą należy ponownie sprawdzić aktualne komunikaty.