Krótko: Dla PHP 8.1 i starszych projekt PHP nie wydaje już oficjalnych aktualizacji. Wsparcie długoterminowe, zwane też Extended Support, pochodzi od dystrybucji Linuxa, repozytoriów zewnętrznych dostawców lub usług komercyjnych, takich jak TuxCare ELS czy Zend/HeroDevs. Może przeprowadzić przez czas do aktualizacji, jeśli dostawca potwierdzi na piśmie pokrycie dla Państwa wersji. Nie zastępuje jednak ani aktualizacji, ani pielęgnacji CMS i własnego kodu.
Dlaczego pytanie to pojawia się właśnie teraz
21 października 2026 ukazały się poprawki PHP2Shell tylko dla wspieranych gałęzi 8.5, 8.4, 8.3 i 8.2. Dla 7.4, 8.0 i 8.1 projekt PHP udostępnił jedynie minimalne backporty w kodzie źródłowym, czyli poprawki w kodzie bez gotowego wydania. Według prasy fachowej dotknięte są niemal wszystkie wersje aż do PHP 5.4.
Jak duży jest zasób, pokazuje analiza CybelAngel: około 2,24 miliona hostów PHP osiągalnych z internetu, z czego według CybelAngel 59 procent na wersjach bez nadchodzącej oficjalnej poprawki. Dla wielu firm pytanie o wsparcie długoterminowe nie jest więc już teoretyczne. A będzie większe: PHP 8.2 osiąga 31.12.2026 koniec wsparcia.
Czego stary system potrzebuje teraz natychmiast, opisuje PHP 8.1 i starsze: co obowiązuje teraz. Ten artykuł pomaga w pytaniu średnioterminowym: która droga wytrzyma do aktualizacji i co musi zapewnić?
PHP Extended Support: drogi w skrócie
| Droga | Co dostarcza | Granice |
|---|---|---|
| Długoterminowa pielęgnacja dystrybucji | backporty w pakietach, dopóki wspierana jest wersja dystrybucji | tylko dla wersji PHP, którą ta dystrybucja zawiera |
| Repozytorium zewnętrznego dostawcy | np. sury.org, według doniesień z buildami od 5.6 do 8.5 | to nie archiwum bezpieczeństwa dystrybucji, kwestia zaufania |
| Komercyjne wsparcie długoterminowe | załatane pakiety dla wygasłych wersji, np. TuxCare ELS, Zend/HeroDevs | pokrycie dla każdej wersji i CVE trzeba kazać potwierdzić, bieżące koszty |
| Samodzielny build z backportów źródłowych | własne buildy z poprawek projektu PHP | pracochłonne, przy każdej luce trzeba od nowa |
Co do ofert komercyjnych: TuxCare opisuje na swojej stronie poprawki CVE dla wygasłych wersji od PHP 5.2 do 8.x, dostarczane przez istniejące zarządzanie pakietami, dla Windows i popularnych dystrybucji Linuxa. Uwaga na tej samej stronie zgłasza poprawki PHP2Shell dla wygasłych wersji PHP. Według dokumentacji cPanel TuxCare obiecuje dla luk od CVSS 7 poprawki w ciągu 14 dni od publikacji; na serwerach cPanel domeny są w tym celu przestawiane z ea-php na alt-php. O Zend/HeroDevs nie mieliśmy informacji o pokryciu PHP2Shell.
Wskazówki o drodze przez zewnętrznego dostawcę daje artykuł Repozytorium sury.org.
Co muszą Państwo mieć od dostawcy na piśmie
Wsparcie długoterminowe to usługa oparta na zaufaniu. Kupują Państwo obietnicę, że przyszłe luki będą zamykane. Przed decyzją proszę więc kazać sobie na piśmie odpowiedzieć:
- Jakie wersje PHP, systemy operacyjne i nazwy pakietów są dokładnie objęte?
- Czy CVE-2026-109618 i CVE-2026-109619 są zamknięte dla Państwa wersji, przy jakim stanie pakietu i od kiedy?
- Jak postępuje się z CVE-2026-115560 i przyszłymi komunikatami następczymi?
- Czy używane przez Państwa rozszerzenia są objęte, czy tylko rdzeń PHP?
- Jak samodzielnie sprawdzić, że poprawka została zainstalowana, na przykład przez changelog pakietu?
- Jak długo trwa pokrycie dla Państwa wersji i jak zapowiadany jest koniec?
- Co dzieje się z zainstalowanymi pakietami, gdy umowa się kończy?
Odpowiedzi, które odsyłają ogólnie do „wszystkich luk bezpieczeństwa”, nie wystarczają. Dla audytorów, ubezpieczycieli i Państwa własnej dokumentacji liczy się konkretne przypisanie wersji, pakietu i CVE.
Granice: czego wsparcie długoterminowe nie rozwiązuje
Wsparcie długoterminowe utrzymuje środowisko PHP na bieżąco. Wszystko ponad nim pozostaje Państwa zadaniem. A właśnie tam leży w starych systemach zwykle większy problem.
- Aplikacja starzeje się dalej: CMS lub sklep, który wymaga PHP 8.1, często sam nie jest już używany w aktualnej wersji.
- Biblioteki i rozszerzenia: Pakiety Composer i wtyczki często nie otrzymują już aktualizacji dla starych wersji PHP.
- Brak zastępstwa za restart i kontrolę: Także załatane pakiety działają dopiero po restarcie wszystkich procesów PHP i nie usuwają szkodliwego oprogramowania wprowadzonego wcześniej.
- Dług techniczny rośnie: Im dłuższy most, tym większy skok przy późniejszej migracji.
- Dowody stają się bardziej pracochłonne: Audytorzy, klienci i ubezpieczyciele coraz częściej pytają o stan poprawek. Wygasłą wersję PHP z poprawkami zewnętrznego dostawcy da się udokumentować, ale wymaga więcej wyjaśnień niż wersja wspierana.
Kiedy wsparcie długoterminowe jest mimo wszystko właściwym wyborem? Typowe są trzy sytuacje: aplikacja specjalistyczna, której producent jeszcze nie zwalnia nowszych wersji PHP; stary system, którego zastąpienie już postanowiono i który ma działać jeszcze tylko kilka miesięcy; albo duża baza kodu, której przejście trzeba starannie zaplanować. We wszystkich trzech przypadkach wsparcie długoterminowe kupuje czas na uporządkowane rozwiązanie. Nie jest rozwiązaniem dla systemów, którymi nikt już nie chce się zajmować.
Jeśli stary system działał między 17 a 21 października bez ochrony w internecie, najpierw proszę wyjaśnić, czy został skompromitowany. Wsparcie długoterminowe dla systemu już zainfekowanego niczego nie chroni.
Do tego należy plan wyjścia
Wsparcie długoterminowe jest dobrą decyzją, jeśli kończy się datą. Proszę ustalić, do kiedy aplikacja ma działać na wspieranej wersji, kto odpowiada za migrację i jakie cele pośrednie obowiązują. Jak długo gałęzie PHP są oficjalnie utrzymywane, wyjaśnia Cykl wydawniczy PHP.
To, czy dla Państwa systemu bardziej opłaca się aktualizacja, czy backport, rozważa artykuł Aktualizacja PHP czy backport?.
Jak konkretnie pomaga PHP SOS?
- Ocenić sytuację: Sprawdzamy wersję, źródło pakietów i stan poprawek Państwa starych systemów oraz czy wykazują ślady ataku.
- Sprawdzić oferty: Porównujemy pisemne zapewnienia dostawcy wsparcia długoterminowego z Państwa faktycznym zasobem.
- Zabezpieczyć most: Do czasu aktualizacji ustawiamy środki przejściowe z php.net i ograniczamy dostępność.
- Przeprowadzić wyjście: W ramach migracji z PHP 8.1 i starszych planujemy i testujemy przejście na wspieraną wersję.
Częste pytania
Czym jest PHP Extended Support?
Chodzi o oferty, które po oficjalnym końcu wsparcia nadal dostarczają wersjom PHP poprawki bezpieczeństwa. Mogą to być dystrybucje Linuxa, repozytoria zewnętrznych dostawców lub usługi komercyjne, takie jak TuxCare ELS czy Zend/HeroDevs.
Czy komercyjne wsparcie długoterminowe obejmuje PHP2Shell?
TuxCare podaje na swojej stronie, że udostępnił poprawki PHP2Shell dla wygasłych wersji PHP. Dla Państwa konkretnej wersji, pakietu i systemu operacyjnego należy to mimo to kazać sobie potwierdzić na piśmie i sprawdzić w changelogu.
Czy wsparcie długoterminowe jest alternatywą dla aktualizacji?
Tylko na czas. Utrzymuje środowisko PHP załatane, ale nie CMS, rozszerzenia i własny kod, które często również są przestarzałe. Data wyjścia powinna więc należeć do każdej decyzji o wsparciu długoterminowym.
Co się dzieje, gdy umowa wsparcia długoterminowego się kończy?
Według dokumentacji cPanel o TuxCare zainstalowane pakiety działają dalej, ale nie otrzymują już nowych aktualizacji bezpieczeństwa. System jest wtedy znów w tej samej sytuacji co wcześniej, tylko później.
Czy temat dotyczy także PHP 8.2?
Tak, wkrótce. PHP 8.2 otrzymuje w wersji 8.2.35 jeszcze poprawkę PHP2Shell, ale 31.12.2026 osiąga koniec wsparcia. Kto prowadzi 8.2, powinien już teraz zaplanować przejście.