Co zrobić ze stroną internetową, która ma starą wersję PHP albo Node.js?

Krótka odpowiedź jest taka: strona internetowa ze starą wersją PHP albo Node.js ma trzy ścieżki — dostosować kod do wspieranego wydania, przebudować witrynę od nowa albo na jakiś czas trzymać ją na platformie, która dla starego runtime wciąż przygotowuje backport poprawek zabezpieczeń, i w tym czasie spokojnie planować przejście. Czwartej ścieżki — zostawić wszystko tak, jak jest, bo witryna przecież działa — w rzeczywistości nie ma, bo release branch PHP 8.1 i starsze nie dostają już poprawek od projektu PHP, release line Node.js 18 i 20 również nie, a październik 2026 w obu przypadkach pokazał, co to znaczy w praktyce.

Witryna ze starą wersją PHP zwykle nie jest ani wyjątkiem, ani szczególnym zaniedbaniem. Została zbudowana pięć albo osiem lat temu, programista, który ją zrobił, od dawna pracuje gdzie indziej, a witryna przez te wszystkie lata służyła bez większych problemów: przyjmowała zgłoszenia, pokazywała ceny i wysyłała faktury. Według danych W3Techs w październiku 2026 roku 26,8% witryn korzystających z PHP działało na PHP 7, a kolejne 7,7% na PHP 5, a więc więcej niż jedna trzecia z nich używa PHP, którego wsparcie skończyło się kilka lat temu. Pytanie zwykle pojawia się dopiero wtedy, gdy dostawca hostingu przysyła ostrzeżenie albo gdy jakaś podatność pojawia się w wiadomościach.

Kiedy wersja PHP albo Node.js staje się stara

„Stara” nie jest tu kwestią gustu, bo zarówno PHP, jak i Node.js publikują harmonogram, w którym podane jest, do której daty każdy release branch albo każda release line dostaje poprawki. PHP daje każdemu release branch dwa lata Active support i jeszcze dwa lata, w których wychodzą już tylko poprawki krytycznych błędów zabezpieczeń, a potem release branch nie jest wspierany w żaden sposób. Release line Node.js ze wsparciem długoterminowym mają na końcu Maintenance LTS, a gdy Maintenance LTS się kończy, release line nie dostaje już żadnego wydania, także wtedy, gdy nowa podatność dotyczy właśnie jej.

W tabeli są te release branch i release line, z którymi dziś ma się do czynienia najczęściej, oraz ich stan w październiku 2026. Daty pochodzą z listy końca wsparcia PHP i z harmonogramu wydań Node.js, i oba źródła trzeba sprawdzać także później, bo co roku pojawiają się w nich nowe wiersze.

Dwa wiersze w tej tabeli warto przeczytać jeszcze raz. PHP 8.2 straci wsparcie 31 grudnia 2026, więc witryna, która jesienią 2026 wygląda nowocześnie, w styczniu 2027 będzie w tej samej sytuacji co witryna na PHP 7.4, i przejście warto zaplanować już teraz, dopóki da się je zrobić bez pośpiechu. Release line Node.js 20 jeszcze jesienią 2024 była aktywną release line ze wsparciem długoterminowym, na której rozpoczęto wiele nowych projektów, ale 30 kwietnia 2026 wsparcie straciła. Starzenie nie odbywa się stopniowo: jednego konkretnego dnia runtime przechodzi ze stanu „dostaje poprawki” do stanu „nie dostaje nic”, a na witrynie w tej chwili nie zmienia się nic, co dałoby się zauważyć.

Dlaczego działająca strona internetowa i tak jest zagrożona

Wersja bez wsparcia nie staje się groźna w dniu, w którym wsparcie się kończy, tylko w dniu, w którym publikowana jest podatność dotycząca także jej. Poprawka dla wspieranych release branch wychodzi razem z opisem i gdy tylko jest publiczna, atakujący mogą porównać kod poprawiony z niepoprawionym i zobaczyć, gdzie jest dziura. Node.js na stronie o końcu wsparcia mówi to wprost: jeżeli podatność dotyczy także release line bez wsparcia, nowego wydania dla niej nie będzie, a ci, którzy na takiej release line zostają, są od razu bez ochrony przed atakami wykorzystującymi opublikowaną podatność.

W październiku 2026 właśnie to stało się na obu platformach niemal jednocześnie. 21 października PHP wydało awaryjne poprawki dwóch krytycznych podatności znanych pod nazwą PHP2Shell i tylko release branch od 8.2 do 8.5 dostały oficjalne wydania, a dla release branch 7.4, 8.0 i 8.1 zespół bezpieczeństwa w drodze wyjątku przygotował jedynie minimalne poprawki kodu źródłowego dla tych, którzy budują PHP samodzielnie. Tego samego dnia Node.js wydał poprawki dziesięciu podatności, a release line 18 i 20 nie dostały ich od samego projektu wcale. Oba przypadki opisaliśmy szerzej osobno: w artykule o PHP2Shell i w artykule o aktualizacji zabezpieczeń Node.js.

Drugie ryzyko jest mniej widoczne, ale na dłuższą metę większe. Stary runtime nie pozwala zaktualizować niczego z tego, co leży nad nim: wtyczki WordPressa, pakiety Composera i npm oraz sam framework w nowych wydaniach stopniowo przestają wspierać stare PHP i Node.js, więc witryna nie może dostać także ich poprawek. WordPress sam zaleca PHP 8.3 albo nowsze, a o starszych wersjach pisze, że osiągnęły już oficjalny koniec cyklu życia i mogą narazić witrynę na podatności. Stary runtime nie jest już wtedy osobnym problemem, tylko warstwą, która nie pozwala rozwiązać wszystkich pozostałych.

Gdy coś się stanie, koszt jest znacznie wyższy niż przy planowanej aktualizacji. Zhakowana witryna oznacza czyszczenie, odtworzenie z kopii zapasowej, wymianę haseł i kluczy, a jeżeli zostały dotknięte dane osobowe klientów, także ocenę, czy o naruszeniu ochrony danych osobowych trzeba zawiadomić organ nadzorczy, Prezesa UODO, i wszystko to dzieje się w pośpiechu, gdy witryna nie działa albo pokazuje odwiedzającym obcą treść. Przejście i w tej sytuacji trzeba wykonać, tylko teraz wypada je robić po włamaniu, a nie przed nim, i bez możliwości spokojnego sprawdzenia wszystkiego w środowisku testowym.

Dlaczego starej wersji PHP nie da się po prostu zmienić w panelu hostingu

W panelu hostingu przejście na nowszą wersję PHP zajmuje jedno kliknięcie i właśnie dlatego jest zwodnicze: jeżeli kod nie jest na to gotowy, witryna przestaje działać w następnej sekundzie, często z pustą stroną albo z komunikatem o błędzie. Przy przejściu na następne duże wydanie PHP świadomie usuwa funkcje, które przez długie lata były przestarzałe. PHP 7.0 usunęło stare PHP extension mysql, na którym opierało się wiele starszych witryn, a PHP 8.0 w swoim wykazie zmian niekompatybilnych usunęło między innymi funkcje each() i create_function(), które w starszym kodzie wciąż się spotyka.

W świecie Node.js klasycznym przykładem jest release line 17, w której runtime przeszedł na OpenSSL 3.0. W ogłoszeniu wydania Node.js ostrzegał, że aplikacja, która sama albo której moduły używają algorytmu albo długości klucza, których OpenSSL 3.0 domyślnie już nie dopuszcza, dostanie błąd ERR_OSSL_EVP_UNSUPPORTED, i jako rozwiązanie tymczasowe zaproponował parametr uruchomieniowy --openssl-legacy-provider. Błąd często brał się nie z własnego kodu projektu, tylko z jednej z jego zależności, więc trzeba było poprawiać kod, którego zespół projektu wcale sam nie napisał.

Dlatego przejście jest pracą programistyczną, a nie ustawieniem. Kod trzeba sprawdzić na nowym runtime, przestarzałe funkcje zastąpić, zależności zaktualizować do wydań, które go obsługują, i wszystko wypróbować w środowisku testowym, zanim zobaczą to klienci. Dla niewielkiej witryny na utrzymywanej platformie może to być praca na kilka godzin, ale dla systemu, którego framework stracił wsparcie kilka lat temu, przejście często oznacza także wymianę frameworka, i wtedy jest to już projekt z własnym budżetem i harmonogramem, a nie zadanie, które da się zrobić między innymi pracami.

Trzy ścieżki: zaktualizować, przebudować albo trzymać pod ochroną

Ścieżkę wyznaczają dwie rzeczy: jak daleko kod został w tyle za wspieraną wersją i jak długo witryna ma jeszcze służyć. Jeżeli witrynę i tak za rok planuje się zastąpić nową, dużego przejścia w starym kodzie nie warto robić, ale jeżeli jest codziennym narzędziem pracy firmy, z którego będą korzystać jeszcze co najmniej pięć lat, rozwiązanie tymczasowe tylko odsuwa to, co nieuniknione, i czyni to droższym. W tabeli są trzy ścieżki, które realnie są dostępne, oraz to, co każda z nich rozwiązuje i czego nie rozwiązuje.

Aktualizacja jest właściwym wyborem, jeżeli witryna opiera się na utrzymywanej platformie, na przykład WordPress albo Laravel, a od wspieranego release branch dzielą ją jeden albo dwa duże kroki. Praca jest wtedy przewidywalna: trzeba zaktualizować framework i wtyczki, poprawić to, co znajdą narzędzia kontrolne, i przełączyć PHP. Przebudowa jest najuczciwszą ścieżką, jeżeli sam framework jest bez wsparcia, jeżeli witryna jest napisana na PHP 5.x bez żadnego frameworka albo jeżeli kodu nikt już nie rozumie, bo wtedy koszt aktualizacji szybko zbliża się do kosztu nowej witryny, a wynikiem wciąż jest stary kod.

Trzecia ścieżka jest omawiana rzadziej. Starą witrynę można trzymać na platformie, która jej runtime wciąż przygotowuje backport poprawek zabezpieczeń, izoluje ją od innych witryn i blokuje znane wzorce ataku jeszcze przed poprawką. To nie jest zamiennik przejścia i sam Node.js takie wsparcie nazywa rozwiązaniem tymczasowym, ale to uczciwy sposób, żeby zyskać czas: przejście można zrobić w zaplanowanym tempie, a nie w tydzień po kolejnym ogłoszeniu bezpieczeństwa. Najważniejsze słowo jest tutaj „termin”, bo bez niego rozwiązanie tymczasowe staje się stałe.

Czym jest backport i dlaczego numer wersji nic o nim nie mówi

Backport oznacza, że poprawkę zabezpieczeń opracowaną dla nowszego wydania ktoś dostosowuje i wbudowuje w starsze wydanie, którego użytkownik już używa. Red Hat, który w ten sposób utrzymuje pakiety swoich dystrybucji Linuksa, pisze, że po samym numerze wersji klient nie może ocenić, czy jego system jest podatny, bo poprawka zmienia pakiet, ale nie numer wersji. Właśnie dlatego skanery podatności, które patrzą tylko na numer, w takich systemach często błędnie zgłaszają problemy, które są już usunięte.

W przypadku PHP i Node.js robi to kilku dostawców. Dystrybucje Linuksa robią backport poprawek do swoich pakietów PHP i Node.js przez cały czas wsparcia dystrybucji. CloudLinux dla swoich pakietów alt-php, z których korzystają serwery hostingowe z CloudLinux, robi backport także dla release branch, którym wsparcie PHP dawno się skończyło: w przypadku PHP2Shell jego strona statusu 21 października ogłosiła, że przygotowuje poprawione pakiety dla wszystkich release branch alt-php od 5.2 do 8.5, i w ciągu następnej nocy były one dostępne. Pakiety te są teraz częścią rozszerzonego wsparcia firmy TuxCare, a w jego warunkach dla podatności o wysokim i krytycznym poziomie zagrożenia jako cel podano poprawkę w ciągu 14 dni od upublicznienia.

Dla release line Node.js bez wsparcia taką samą usługę oferują partnerzy komercyjni, których sam Node.js wymienia na swojej stronie o końcu wsparcia: HeroDevs, NodeSource i TuxCare. Node.js od razu dodaje, że takie wsparcie należy traktować jako rozwiązanie tymczasowe, a celem zawsze powinno być przejście na wspieraną wersję. CloudLinux przy październikowym wydaniu Node.js z 2026 roku zrobił backport poprawek także do swoich pakietów release line 16, 18 i 20, które klienci hostingu wybierają w sekcji Setup Node.js App w cPanel.

Po numerze wersji sprawdzić tego nie można. Komenda php -v albo node -v po backporcie pokazuje dokładnie to samo co przed nim, i CloudLinux w swoim ogłoszeniu o Node.js pisze to otwarcie: dla release line bez wsparcia numer po aktualizacji się nie zmienia. Zmienia się release number pakietu, który widzi tylko administrator serwera, więc na hostingu współdzielonym odpowiedzi może udzielić wyłącznie dostawca hostingu.

Granicę trzeba powiedzieć równie jasno. Backport chroni samo PHP albo samo Node.js, ale nie chroni wtyczki WordPressa, której autor zaprzestał aktualizacji, własnego kodu ze wstrzyknięciem SQL ani pakietu npm, którego nowsze wydania starego Node.js już nie obsługują. Dostawcy robią poza tym backport dla każdej release line osobno, więc przy każdej konkretnej trzeba sprawdzić, czy w ogóle jest na liście, a TuxCare w swoich warunkach zastrzega sobie prawo, by zamiast poprawki zaproponować środek ograniczający ryzyko.

Kiedy stary jest nie runtime, tylko sama platforma

Czasem problem nie leży w runtime, tylko w samej platformie, na której witryna jest zbudowana, i wtedy backport poprawek PHP pomaga tylko częściowo. Najlepszym przykładem jest Drupal 7: jego wsparcie bezpieczeństwa skończyło się 5 stycznia 2025 i od tego czasu sam projekt Drupal nie wydaje dla niego ani poprawek zabezpieczeń, ani aktualizacji zgodności. Witryna na Drupalu 7 może działać na w pełni poprawionym PHP, ale jej rdzeń, moduły i motyw i tak zostają ze wszystkimi podatnościami, które jeszcze zostaną w nich znalezione, bo za darmo nikt ich już nie poprawia.

Także tutaj jest płatne rozwiązanie tymczasowe: organizacja Drupal Association utworzyła program rozszerzonego wsparcia bezpieczeństwa, w którym płatne wsparcie oferują sprawdzeni dostawcy, na przykład HeroDevs i Tag1 Consulting. To ta sama zasada co przy backporcie poprawek PHP, tylko o warstwę wyżej, i ma te same ograniczenia: odsuwa przejście, ale go nie rozwiązuje, a każdy rok na starej platformie czyni przejście droższym, bo rośnie odległość do bieżącego wydania i maleje liczba programistów, którzy starą platformę jeszcze znają.

Dlatego przed jakąkolwiek decyzją warto sprawdzić wszystkie warstwy, nie tylko PHP: runtime, platformę albo framework, wtyczki albo moduły i własny kod. Jeżeli przestarzałe jest tylko PHP, a WordPress, Laravel albo inna platforma jest utrzymywana, przejście zwykle jest pracą o przewidywalnym zakresie. Jeżeli stara jest sama platforma, pytanie nie dotyczy już release branch PHP, tylko tego, czy przenieść witrynę na nowe wydanie platformy, czy zbudować ją od nowa, i właśnie tutaj zadaniem backportu jest dać czas, żeby podjąć tę decyzję bez pośpiechu.

Jak trzymamy stare PHP i Node.js na naszym serwerze

Nasz Managed Hosting to miejsce na naszym własnym serwerze, który działa na CloudLinuxie, a wersję PHP każdej witryny wybiera się osobno w panelu hostingu. Obecnie dostępne jest tam PHP od 5.4 do 8.4, a dla aplikacji Node.js zarówno wspierane release line 22 i 24, jak i stare release line 16, 18 i 20. To znaczy, że starą witrynę można przenieść do nas z tym samym PHP albo Node.js, na którym działa teraz, i najpierw ją ustabilizować, zamiast w dniu przenosin zmieniać od razu także kod, co jest najbezpieczniejszym sposobem, żeby przy przenosinach niczego nie zepsuć.

Jak to działa w praktyce, w październiku 2026 mogliśmy zmierzyć sami. Poprawki PHP2Shell wyszły 21 października po południu i na naszym serwerze wszystkie stare release branch PHP od 5.4 do 8.1 działają teraz na pakietach, które CloudLinux przebudował w nocy tego samego dnia, w mniej niż dobę po wydaniu PHP, i które zawierają backport tej poprawki. Release branch od 8.2 do 8.4 przeszły na oficjalne poprawione wydania 8.2.35, 8.3.36 i 8.4.27, a release line Node.js 16, 18 i 20 dostały 22 października pakiety CloudLinux z backportem poprawek, choć sam projekt Node.js poprawek dla nich nie wydał. Na starych release branch numer się nie zmienił, więc sprawdziliśmy to nie po numerze, lecz po tym, kiedy przebudowano pliki wykonywalne.

To nie wszystko, co robi platforma. CloudLinux umieszcza każde konto hostingowe w osobnym izolowanym środowisku o nazwie CageFS, czyli account isolation, w którym użytkownicy nie widzą innych użytkowników serwera ani nawet ich nazw użytkowników, co utrudnia rozprzestrzenienie się włamania z jednego konta na pozostałe. Zapora aplikacji internetowych (WAF) Imunify360 w przypadku PHP2Shell zaczęła blokować znane wzorce ataku 21 października, kilka godzin przed publikacją poprawionego PHP. Żadna z tych warstw nie czyni starej witryny wolną od podatności, ale razem skracają czas, w którym znaną podatność da się wykorzystać, i ograniczają, jak daleko mogą sięgnąć skutki włamania.

Dlatego przeniesienie starej witryny do nas radzimy traktować jako rozwiązanie tymczasowe z terminem, a nie jako cel końcowy. Witrynę przenosimy z tym samym runtime, sprawdzamy, że wszystko działa tak jak wcześniej, i potem wraz z Państwem ustalamy, do której daty i w jakiej kolejności przejdzie na wspieraną wersję, żeby rozwiązanie tymczasowe nie stało się stałe. Nasz Managed Hosting zaczyna się od 45 € miesięcznie, a utrzymywane runtime, account isolation i zapora aplikacji internetowych są częścią tego, za co w tej kwocie się płaci. Jeżeli mają Państwo witrynę ze starą wersją PHP albo Node.js, proszę przysłać nam jej adres, a powiemy, która z trzech ścieżek do niej pasuje i od czego zacząć.

Jak ustalić, którą wersję PHP albo Node.js ma Państwa strona internetowa

Najszybsza droga to panel hostingu. W hostingu na cPanel z CloudLinux sekcja Select PHP Version pokazuje wersję wybraną dla całego konta, a MultiPHP Manager pokazuje wersję każdej domeny osobno i jeżeli domena ma tam ustawioną własną wersję, rozstrzyga właśnie ona. Aplikacjom Node.js to samo pokazuje sekcja Setup Node.js App, w której każda aplikacja ma własny wiersz. Warto patrzeć na każdą witrynę, nie tylko na główną, bo na jednym koncie często jest kilka witryn z różnymi release branch PHP, a zapomniana kopia testowa albo stara podstrona kampanii nierzadko wciąż jest dostępna z internetu.

Na witrynie WordPressa widać to także w panelu administracyjnym: w sekcji Narzędzia → Stan witryny, na zakładce Informacja, w bloku Serwer podana jest wersja PHP, na której witryna działa. Jeżeli panelu nie ma, można utworzyć plik z funkcją phpinfo() i otworzyć go w przeglądarce, ale potem plik koniecznie trzeba usunąć, bo każdemu odwiedzającemu pokazuje konfigurację serwera. Komenda php -v pomaga tu mniej, niż się wydaje, bo pokazuje PHP z wiersza poleceń, a żądania WWW często obsługuje inny release branch, wybrany w panelu hostingu. W projekcie Node.js pożądaną release line często podaje package.json, a w nim pole engines, albo plik .nvmrc, ale to tylko życzenie, i tego, który Node.js naprawdę uruchamia aplikację, trzeba szukać tam, gdzie proces jest uruchamiany.

Jeżeli dostępu nie ma wcale, pytanie trzeba zadać dostawcy hostingu albo programiście, który witrynę utrzymuje. Sformułowanie, które skraca wymianę wiadomości: „Która wersja PHP albo Node.js obsługuje naszą witrynę? Jeżeli jej wsparcie się skończyło, czy dostaje backport poprawek zabezpieczeń, skąd one pochodzą i kiedy pakiet był ostatnio aktualizowany? Do której daty rekomendują Państwo przejście?” Odpowiedź na ostatnie pytanie dużo mówi także o samym dostawcy, bo jeżeli daty nie ma, zwykle nie ma też planu.

Przejście na wspieraną wersję: jak zrobić je bez niespodzianek

Przejście zaczyna się od inwentaryzacji, a nie od przełączenia. Trzeba zapisać, który release branch PHP i które PHP extension są witrynie potrzebne, jakie zaplanowane zadania uruchamiają ją w tle, z jakimi systemami zewnętrznymi się komunikuje i które jej części są krytyczne dla biznesu, na przykład formularz zamówień, płatności albo wysyłka faktur. Wersję docelową warto wybrać z zapasem: PHP 8.4 będzie dostawać poprawki zabezpieczeń do 31 grudnia 2028, PHP 8.3 do końca 2027, a przejście na PHP 8.2, którego wsparcie kończy się już z końcem 2026, oznaczałoby kolejne przejście całkiem niedługo. W przypadku Node.js celem w większości wypadków jest release line 24.

Drugi krok to sprawdzenie kodu, a przy kodzie PHP da się je w dużej mierze zautomatyzować. PHPCompatibility to zestaw reguł PHP_CodeSniffer, który sprawdza, czy kod jest zgodny z konkretną wersją PHP, a Rector część potrzebnych zmian potrafi wykonać automatycznie. Żadne z nich nie zastępuje kontroli człowieka, ale szybko pokazują, czy zakres pracy liczy się w godzinach, czy w tygodniach, i właśnie tego potrzeba, żeby zdecydować między aktualizacją a przebudową. Na witrynie WordPressa najpierw trzeba zaktualizować wtyczki i motyw, a dopiero potem przełączyć PHP.

Trzeci krok to środowisko testowe, czyli kopia witryny z nowym PHP albo Node.js, na której sprawdza się wszystkie krytyczne działania: formularze, płatności, wysyłkę e-maili, import i eksport. Dziennik błędów jest na tym etapie ważniejszy niż kontrola wizualna, bo ostrzeżenia o przestarzałych funkcjach pojawiają się tam długo przed tym, zanim coś się zatrzyma. Czwarty krok to przełączenie w czasie niskiego obciążenia, z możliwością powrotu: na hostingu z wyborem wersji droga powrotna to to samo jedno kliknięcie, którym wersję przełączono, więc ryzyko jest małe, o ile kopia zapasowa jest świeża i ktoś przez pierwszy tydzień śledzi dziennik błędów.

Dla aplikacji Node.js logika jest ta sama, inne są tylko narzędzia. Przejście między dużymi release line warto robić po jednej, po każdej uruchamiając testy aplikacji, a szczególną uwagę trzeba zwrócić na pakiety ze skompilowanym kodem, bo buduje się je pod konkretną release line Node.js i po przejściu trzeba je przebudować. Najpierw trzeba zaktualizować zależności, które nowej release line jeszcze nie obsługują, i dopiero potem zmienić sam runtime, bo inaczej błędy z obu stron mieszają się i trudno zrozumieć, który co spowodował.