Krótko: To, czy właściwym wyborem jest aktualizacja PHP czy backport, zależy od tego, jak długo system ma jeszcze działać i jak dobrze backport jest udokumentowany. Backport własnej dystrybucji w obsługiwanym systemie operacyjnym jest pełnowartościową drogą. Backporty ze źródeł, źródła zewnętrzne i komercyjne wsparcie długoterminowe dla PHP 8.1 i starszych to pomosty z datą ważności. Na dłuższą metę pomaga tylko przejście na wersję PHP, którą projekt PHP nadal oficjalnie wspiera.
Dlaczego pytanie po PHP2Shell jest pilne
21.10.2026 projekt PHP usunął PHP2Shell w wersjach 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Dla PHP 8.1 i starszych nie ma już oficjalnych wydań, tylko minimalne backporty ze źródeł dla 7.4, 8.0 i 8.1. Według prasy branżowej dotknięte są niemal wszystkie wersje aż do PHP 5.4.
Wielu operatorów starych systemów staje więc przed tym samym pytaniem: czy wystarczy jakoś załatać lukę, czy teraz trzeba wykonać aktualizację odkładaną od lat? Co aktualizacja oznacza w praktyce, opisuje nasza oferta migracji z PHP 8.1 i starszych. Co obowiązuje bez oficjalnej aktualizacji, wyjaśnia artykuł PHP 8.1 i starsze: co obowiązuje teraz. Ten wpis pomaga w rozważeniu pomiędzy nimi.
Jakie są rodzaje backportów
„Backport” to pojęcie zbiorcze. Chodzi zawsze o to, że poprawka z nowszej wersji jest przenoszona do starszej. To, kto to robi i jak dobrze jest to sprawdzone, różni się jednak bardzo.
- Backport dystrybucji: Debian, Ubuntu, Red Hat i inni przenoszą poprawki bezpieczeństwa do pakietów PHP swoich obsługiwanych wydań. Numer wersji często pozostaje przy tym taki sam; według doniesień Ubuntu 24.04 po aktualizacji nadal pokazuje na przykład 8.3.6. Poprawkę dokumentuje dziennik zmian pakietu i komunikaty bezpieczeństwa dystrybucji.
- Źródło zewnętrzne: Repozytorium sury.org Ondřeja Surý udostępniło według doniesień kompilacje dla wszystkich gałęzi od 5.6 do 8.5. Nie jest to archiwum bezpieczeństwa Debiana. Szczegóły znajdują się w artykule Repozytorium sury.org.
- Backport ze źródeł projektu PHP: Dla 7.4, 8.0 i 8.1 istnieją minimalne poprawki w kodzie źródłowym, ale nie ma gotowych wydań. Kto z nich korzysta, musi sam budować PHP, testować je i w przyszłości utrzymywać.
- Komercyjne wsparcie długoterminowe: Dostawcy tacy jak TuxCare ELS lub Zend/HeroDevs oferują utrzymanie starych wersji. To, czy i kiedy obejmują PHP2Shell, musi zostać pisemnie potwierdzone; w znanych źródłach nie było to udokumentowane. Więcej w artykule Wsparcie długoterminowe dla starych wersji PHP.
Aktualizacja PHP czy backport: porównanie
| Kryterium | Aktualizacja do obsługiwanej wersji | Backport (zależnie od rodzaju) |
|---|---|---|
| Ochrona przed PHP2Shell | Tak, z 8.2.35, 8.3.36, 8.4.27 lub 8.5.12 | Tak, jeśli kompletny i udokumentowany |
| Przyszłe aktualizacje bezpieczeństwa | Oficjalnie do końca wsparcia wersji | Tylko dopóki dany dostawca utrzymuje |
| Dowód | Numer wersji plus restart | Dziennik zmian pakietu z numerami CVE, potwierdzenie dostawcy |
| Nakład teraz | Średni do wysokiego, potrzebne testy zgodności | Niski w przypadku dystrybucji, wysoki przy samodzielnej budowie |
| Nakład później | Niski do następnego skoku wersji | Rośnie z każdą nową luką |
| Ryzyko dla aplikacji | Niezgodności ze starym kodem i rozszerzeniami | Niskie, zachowanie pozostaje w dużej mierze takie samo |
| Przydatność jako rozwiązanie na stałe | Tak | Tylko backport dystrybucji w ramach obsługiwanego systemu operacyjnego |
Wiersz „Nakład później” jest najważniejszy. PHP2Shell nie będzie ostatnią luką. Każdy miesiąc na wersji bez oficjalnego wsparcia oznacza, że następny komunikat znów postawi to samo pytanie.
Jaka wersja docelowa przy aktualizacji?
Według php.net dla każdej gałęzi PHP obowiązuje: dwa lata aktywnego wsparcia, potem dwa lata tylko poprawek bezpieczeństwa. Z tego wynikają następujące daty końca wsparcia bezpieczeństwa:
| Wersja | Wsparcie bezpieczeństwa do |
|---|---|
| PHP 8.2 | 31.12.2026 |
| PHP 8.3 | 31.12.2027 |
| PHP 8.4 | 31.12.2028 |
| PHP 8.5 | 31.12.2029 |
Aktualizacja do 8.2 jest więc już tylko krótkim przystankiem. Kto i tak migruje, powinien celować w wersję o dłuższym horyzoncie, o ile CMS, sklep i rozszerzenia ją obsługują. Proszę to sprawdzić w wymaganiach systemowych producenta, a nie z pamięci. Jak działa cykl wydań, wyjaśnia artykuł Wersje PHP i cykl wydań.
Niezależnie od drogi: po zainstalowaniu trzeba zrestartować wszystkie procesy PHP. Backport leżący tylko na dysku nie chroni, dopóki stare procesy worker działają w pamięci.
Pragmatyczna kolejność dla starych systemów
- Od razu: Ustawić środki tymczasowe według php.net lub tymczasowo odłączyć system od sieci, jeśli nie ma udokumentowanej poprawki.
- W najbliższych dniach: Zainstalować udokumentowany backport, możliwie z własnej dystrybucji lub z pisemnym potwierdzeniem dostawcy.
- Równolegle: Sprawdzić zgodność aplikacji z obsługiwaną wersją i ustalić harmonogram.
- W najbliższych miesiącach: Aktualizacja do wersji docelowej, przygotowana w kopii testowej, z planem awaryjnym.
Kluczowa myśl: backport to pomost, a nie cel.
Kiedy nie potrzebują Państwo do tego usługodawcy
Jeśli Państwa serwer działa na obsługiwanym Debianie, Ubuntu lub RHEL, a dystrybucja dostarcza backport, wystarczy zwykła aktualizacja z restartem i spojrzenie do dziennika zmian. Doświadczony administrator poradzi sobie z tym sam. Pomoc się opłaca przy samodzielnych kompilacjach, źródłach zewnętrznych, bardzo starych wersjach lub aplikacji, której zgodności nikt już nie przegląda.
Jak konkretnie pomaga PHP SOS?
- Sprawdzamy, jakie wersje PHP i źródła pakietów działają na Państwa serwerach i czy istnieje udokumentowana poprawka.
- Instalujemy backporty, restartujemy i dokumentujemy dowód przez dziennik zmian.
- Testujemy Państwa aplikację w kopii względem wersji docelowej i wskazujemy niezgodności.
- Planujemy i towarzyszymy aktualizacji w ramach migracji z PHP 8.1 i starszych.
Podsumowanie
Backport dystrybucji to pełnowartościowa droga, wszystkie inne backporty to pomosty. Kto utknął na PHP 8.1 lub starszym, powinien wykorzystać backport, aby zyskać czas na aktualizację, a nie by ją dalej odkładać.
Częste pytania
Czy backport jest tak samo bezpieczny jak aktualizacja?
Dla konkretnie naprawionej luki backport może być równoważny, jeśli jest kompletny i udokumentowany. Naprawia jednak tylko to, co zostało przeniesione wstecz. Aktualizacja do obsługiwanej wersji przynosi dodatkowo wszystkie przyszłe oficjalne aktualizacje bezpieczeństwa.
Po czym poznać, że mój backport obejmuje PHP2Shell?
Po dzienniku zmian pakietu: powinny być w nim wymienione numery CVE-2026-109618 i CVE-2026-109619. W Debianie i Ubuntu pokazuje to apt-get changelog, w rodzinie RHEL rpm -q --changelog. Sam numer wersji nie jest dowodem.
Jak długo PHP 8.2 będzie jeszcze otrzymywać aktualizacje bezpieczeństwa?
Według php.net wsparcie bezpieczeństwa dla PHP 8.2 kończy się 31.12.2026. Kto dziś aktualizuje do 8.2, powinien więc od razu zaplanować następny krok.
Czy komercyjne wsparcie długoterminowe dla starych wersji PHP się opłaca?
Może być pomostem, gdy aktualizacja jest w krótkim czasie niemożliwa. Proszę kazać sobie pisemnie potwierdzić, czy i od kiedy obejmuje PHP2Shell. W dotychczas znanych źródłach nie było to udokumentowane.