Krótko: Koniec wsparcia PHP (End of Life) oznacza: projekt PHP nie dostarcza już dla tej gałęzi aktualizacji bezpieczeństwa. PHP2Shell wyraźnie pokazuje skutki, ponieważ dla PHP 8.1 i starszego nie ma oficjalnej poprawki, a PHP 8.2 kończy się 31.12.2026. Kto dziś działa na starej gałęzi, powinien zaplanować przejście teraz, a nie dopiero przy następnej awarii.
Co oznacza koniec wsparcia PHP
Każda gałąź PHP, na przykład 8.2 lub 8.3, jest utrzymywana przez projekt PHP tylko przez ograniczony czas. Najpierw są poprawki błędów i aktualizacje bezpieczeństwa, później już tylko aktualizacje bezpieczeństwa. Potem wsparcie kończy się całkowicie. Aktualne okresy publikuje php.net na stronie o wspieranych wersjach.
Po końcu wsparcia oprogramowanie wprawdzie nadal działa. Jeśli jednak ujawniona zostanie nowa luka, projekt PHP nie wyda już poprawki. Serwer pozostaje podatny, dopóki ktoś inny nie wprowadzi poprawki lub dopóki Państwo nie przejdą na wspieraną gałąź.
Dla zarządu i kierownictwa IT jest to przede wszystkim kwestia planowania. Migrację można spokojnie przygotować. Pod presją czasu po krytycznym komunikacie staje się kosztowna i ryzykowna.
Czego PHP2Shell uczy o przestarzałych wersjach
21.10.2026 projekt PHP opublikował poprawki dla dwóch krytycznych luk, CVE-2026-109618 i CVE-2026-109619. Obie umożliwiają zdalne wykonanie złośliwego kodu bez logowania i mają ocenę CVSS v4.0 9,2. Według prasy branżowej dotknięte są niemal wszystkie wersje aż do PHP 5.4.
| Gałąź | Status według projektu PHP | Poprawka PHP2Shell |
|---|---|---|
| PHP 8.5 | wspierana | 8.5.12 |
| PHP 8.4 | wspierana | 8.4.27 |
| PHP 8.3 | wspierana | 8.3.36 |
| PHP 8.2 | wspierana do 31.12.2026 | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | brak oficjalnych aktualizacji | tylko minimalne backporty kodu źródłowego |
| PHP 7.3 i starsze | brak oficjalnych aktualizacji | brak backportu od projektu PHP |
Dla 8.1 i starszego pozostaje więc tylko droga przez backporty dystrybucji lub hostingów. Często nadal pokazują one stary numer wersji, choć są załatane. Czy backport został wprowadzony, może wiążąco potwierdzić tylko dostawca. Szczegóły znajdują się na stronie PHP 8.1 i starsze: co obowiązuje teraz, pełne zestawienie na stronie Które wersje PHP są podatne?.
PHP 8.2 otrzymało jeszcze poprawkę PHP2Shell, ale 31.12.2026 osiąga koniec wsparcia. Kto teraz migruje z 8.1, powinien od razu celować w nowszą gałąź.
Ryzyko przestarzałych wersji PHP w przeglądzie
Ryzyko dla bezpieczeństwa jest na pierwszym planie, ale nie jedyne. Przestarzałe wersje PHP pociągają za sobą dalsze problemy:
- Brak poprawek dla nowych luk: każda przyszła podatność pozostaje otwarta lub zależy od backportów osób trzecich.
- Przestarzałe biblioteki: aktualne pakiety wymagają nowszych gałęzi PHP. Poprawek bezpieczeństwa w bibliotekach nie da się wtedy już wprowadzić, jak pokazuje poradnik composer audit.
- Zależność od dostawcy: hostingi za stare wersje częściowo naliczają dopłaty lub wygaszają usługę. Termin wyznacza wtedy dostawca, a nie Państwo.
- Problemy z udowodnieniem: wobec ubezpieczycieli, zleceniodawców lub przy audytach niewspieraną wersję trudno uzasadnić. Czy wynikają z tego skutki umowne lub prawne, proszę wyjaśnić z ubezpieczycielem lub prawnikiem.
- Rosnący nakład na migrację: im większa odległość od aktualnej wersji, tym więcej kodu trzeba dostosować.
Szczególnie często dotknięte są starsze systemy sklepowe i niedotykane od dawna rozwiązania indywidualne. Typowym przykładem jest Shopware 5, który często działa jeszcze na starszych gałęziach PHP.
Inwentaryzacja: jakie wersje PHP działają u Państwa?
Pierwszym krokiem jest pełny obraz. Na wielu serwerach równolegle działa kilka wersji PHP, na przykład dla starej strony, o której nikt już nie pamięta. Te polecenia tylko odczytują:
# Wersja wiersza poleceń
php -v
# Zainstalowane wersje w Debian/Ubuntu
ls /etc/php/
# Zainstalowane wersje w Plesk
ls /opt/plesk/php/ 2>/dev/null
# Działające procesy PHP z wersją w nazwie
ps -eo user,cmd | grep -E "[p]hp-fpm|[p]hp[0-9.]*-cgi|[l]sphp" | sort | uniq -c
Dla każdej strony proszę zapisać: domenę, wersję PHP, tryb pracy, CMS z wersją, osobę odpowiedzialną. Ta lista jest zarazem podstawą Państwa planu awaryjnego. Na shared hostingu wersje znajdują się zwykle w menu klienta u dostawcy.
Planowanie migracji: jak postępować
Migracja na wspieraną gałąź przebiega zwykle według tych samych kroków, niezależnie od systemu:
- Ustalić cel: wybrać gałąź, która według php.net będzie wspierana jak najdłużej i według wymagań systemowych producenta pasuje do Państwa CMS.
- Sprawdzić kompatybilność: CMS, rozszerzenia, motywy i własny kod. Dane znajdują się na oficjalnej stronie danego producenta.
- Postawić staging: kopię strony z nową wersją PHP, wraz z bazą danych.
- Testować: wszystkie ważne procesy, od formularza kontaktowego po proces zamówienia, a do tego log błędów pod kątem ostrzeżeń.
- Przełączyć i zrestartować: zmienić wersję, zrestartować wszystkie procesy PHP, sprawdzić działanie i log błędów.
Proszę planować realistycznie. Mała strona z aktualnym CMS jest często przełączana szybko. Sklep rozwijany latami, z wieloma rozszerzeniami i własnym kodem, może natomiast wymagać dostosowania kodu i rozszerzeń, aż po przejście na nową wersję główną systemu sklepowego. Proszę wcześnie wyjaśnić, kto wewnętrznie decyduje, jaki budżet jest dostępny i czy trzeba zaangażować zewnętrznych programistów.
Proszę ustalić także, jak w przyszłości będą Państwo śledzić końce wsparcia. Stały termin w roku, w którym porównują Państwo listę swoich stron z danymi na php.net, zapobiega powtórnemu powstaniu tego samego wąskiego gardła za dwa lata.
Do czasu przełączenia warto stosować środki przejściowe z php.net, na przykład session.upload_progress.enabled=0 w konfiguracji serwera. Nie są one pełną ochroną, ale obniżają ryzyko.
Jak konkretnie pomaga PHP SOS?
- Ustalamy wszystkie wersje PHP, tryby pracy i aplikacje na Państwa serwerach.
- Oceniamy ryzyko dla każdej strony i ustalamy z Państwem kolejność oraz wersję docelową.
- Do czasu migracji wdrażamy środki przejściowe i uzyskujemy od dostawcy potwierdzenia dotyczące backportów.
- Migrujemy przez środowisko stagingowe i dokumentujemy test oraz przełączenie.
Przebieg opisuje usługa PHP 8.1 i starsze: migracja na wspieraną wersję.
Częste pytania
Kiedy kończy się wsparcie dla PHP 8.2?
PHP 8.2 osiąga koniec wsparcia ze strony projektu PHP 31.12.2026. Poprawkę PHP2Shell gałąź ta otrzymała jeszcze w wersji 8.2.35, a dla późniejszych luk po tym terminie nie należy oczekiwać oficjalnej aktualizacji.
Czy PHP 8.1 dostanie poprawkę przeciw PHP2Shell?
Projekt PHP nie wydaje już oficjalnych aktualizacji dla 8.1 i starszych. Istnieją tylko minimalne backporty kodu źródłowego dla 7.4, 8.0 i 8.1. Czy i jak Państwa hosting lub dystrybucja je wprowadza, trzeba zapytać u dostawcy.
Czy stara wersja PHP z backportami hostingu jest bezpieczna?
Backporty mogą zamknąć konkretne luki, ale nie zastępują wspieranej gałęzi. Zależą od dostawcy, często pojawiają się później i nie obejmują każdej luki. Jako rozwiązanie trwałe są więc nieodpowiednie.
Skąd mam wiedzieć, czy mój CMS działa z nową wersją PHP?
Proszę sprawdzić wymagania systemowe na oficjalnej stronie producenta i przetestować w środowisku stagingowym. To samo dotyczy rozszerzeń i motywów, ponieważ to często one są właściwym wąskim gardłem.