koniec wsparcia dla wersji PHP

Koniec wsparcia dla wersji PHP to moment, w którym gałąź języka PHP przestaje otrzymywać jakiekolwiek poprawki od jego twórców. Projekt PHP określa taką wersję jako nieobsługiwaną i zaleca jak najszybszą aktualizację, bo jej użytkownicy mogą być narażeni na niezałatane podatności ^[1]. Dla strony na WordPressie oznacza to, że nawet aktualny rdzeń, wtyczki i motywy działają na interpreterze, w którym nowe błędy bezpieczeństwa nie będą już poprawiane. W żargonie hostingowym mówi się o wersji „po EOL” (end of life).

Jak działa

Każda gałąź PHP, na przykład 8.3, przechodzi przez stałe etapy. Przez dwa lata od pierwszego stabilnego wydania ma aktywne wsparcie, a przez kolejne dwa lata tylko wsparcie bezpieczeństwa; razem daje to cztery lata ^[1]. W fazie aktywnej naprawiane są zgłoszone błędy i luki, a nowe wydania poprawkowe ukazują się regularnie ^[1]. W fazie bezpieczeństwa poprawiane są tylko krytyczne problemy bezpieczeństwa, a wydania pojawiają się wyłącznie w razie potrzeby ^[1]. Po tym czasie gałąź trafia na listę nieobsługiwanych ^[2].

RYS. 1Cykl życia gałęzi PHP

Terminy są stałe i znane z góry. Według stanu strony php.net z września 2026 roku wyglądają one tak ^{[1] [2]}:

Na liście wersji nieobsługiwanych są też starsze gałęzie, między innymi 5.6, której wsparcie skończyło się 31 grudnia 2018 roku ^[2].

W WordPressie

WordPress sam nie wymusza aktualnej wersji PHP. Strona wymagań zaleca PHP w wersji 8.3 lub nowszej ^[3]. Rdzeń uruchomi się także na starszym środowisku, od PHP 7.4, ale dokumentacja ostrzega, że takie wersje osiągnęły oficjalny koniec wsparcia i mogą narażać stronę na podatności ^[3]. Zgodność WordPressa z daną wersją PHP nie oznacza więc, że ta wersja jest bezpieczna.

Rdzeń sprawdza wersję PHP funkcją wp_check_php_version(). Pyta ona usługę api.wordpress.org/core/serve-happy/1.0/ i dostaje w odpowiedzi między innymi wersję zalecaną, wersję minimalną oraz pola is_supported, is_secure i is_acceptable ^[4]. Na tej podstawie narzędzie Zdrowie witryny (Site Health) pokazuje ostrzeżenie. Dla wersji bez poprawek komunikat brzmi: „Your site is running on an outdated version of PHP (…), which does not receive security updates. It should be updated.” ^[5]. W kodzie Site Health znajduje się uwaga, że pole is_secure nie oznacza bezpiecznej wersji PHP, a jedynie to, że wersja wciąż dostaje poprawki bezpieczeństwa ^[5].

Wersję PHP zwykle wybiera się w panelu hostingu, a na hostingu współdzielonym często tylko tam. Utrzymanie aktualnego środowiska uruchomieniowego jest więc wspólnym zadaniem właściciela strony i dostawcy hostingu. Po zmianie wersji problemem bywa zgodność: porzucona wtyczka albo stary motyw mogą nie działać na nowszym PHP i zatrzymać aktualizację całej strony.

Zagrożenia i skutki

OWASP w kategorii Vulnerable and Outdated Components z 2021 roku uznaje za podatną aplikację, której oprogramowanie jest nieobsługiwane albo przestarzałe, wymieniając wprost środowiska uruchomieniowe, serwery aplikacji i biblioteki ^[7]. Ryzyko rośnie także wtedy, gdy platforma i zależności nie są aktualizowane w terminie wynikającym z oceny ryzyka ^[7]. OWASP zwraca uwagę, że aktualizacje w cyklu miesięcznym albo kwartalnym zostawiają organizację na długo narażoną na znane podatności ^[7]. Wersja po końcu wsparcia jest przypadkiem skrajnym: nie ma cyklu aktualizacji, bo nie ma już poprawek.

Przykładem jest CVE-2024-4577, podatność w PHP-CGI w systemie Windows, oceniona jako wysoka. Pozwalała ona na wstrzyknięcie argumentów i zdalne wykonanie kodu przy niektórych stronach kodowych, jako obejście starszej poprawki dla CVE-2012-1823 ^[6]. Mechanizm błędu był nietypowy: w systemach Windows z niektórymi stronami kodowymi, między innymi dla Japonii, Chin i Tajwanu, mapowanie znaków „Best-Fit” zamieniało miękki łącznik na zwykły, co pozwalało ominąć wcześniejsze zabezpieczenie przed argumentami w zapytaniu ^[6]. Poprawione wydania ukazały się dla gałęzi 8.1, 8.2 i 8.3: 8.1.29, 8.2.20 i 8.3.8 ^[6]. Gałąź 8.0, której wsparcie skończyło się 26 listopada 2023 roku, nie znalazła się wśród poprawionych, a jej ostatnim wydaniem pozostało 8.0.30 ^[2].

Skutki dla strony na nieobsługiwanym PHP:

• Każda nowa łatka (patch) do PHP omija to środowisko, więc lista znanych i niezałatanych błędów rośnie z czasem.
• Nowe wersje wtyczek i motywów przestają obsługiwać stare PHP, co blokuje ich aktualizację i utrwala także ich podatności.
• Po włamaniu samo oczyszczenie plików nie wystarcza. CERT Polska w zaleceniach dla przejętych stron wymienia utrzymywanie aktualnej wersji oprogramowania serwera obok aktualizacji CMS, wtyczek i motywów ^[8].

Dobre praktyki

• Znać wersję PHP każdej strony i datę końca jej wsparcia; oba dane są jawne na php.net ^[1].
• Planować przejście na nowszą gałąź z wyprzedzeniem, najlepiej jeszcze w fazie wsparcia bezpieczeństwa obecnej wersji.
• Testować zmianę wersji w środowisku testowym i mieć aktualną kopię zapasową przed przełączeniem produkcji.
• Traktować ostrzeżenie Site Health o PHP jako sygnał do działania, nie tylko informację ^[5].
• Włączyć wersję PHP do procesu zarządzania poprawkami i aktualizacji oprogramowania, razem z rdzeniem, wtyczkami i motywami.
• Nie pokazywać wersji PHP w nagłówkach odpowiedzi; ujawnianie wersji ułatwia atakującym dobór celu.