Ką daryti su svetaine, kurioje yra sena PHP arba Node.js versija?

Trumpas atsakymas yra toks: interneto svetainei su sena PHP arba Node.js versija yra trys keliai — pritaikyti kodą palaikomam leidimui, perkurti svetainę iš naujo arba laikinai laikyti ją platformoje, kuri senam runtime vis dar taiko saugumo pataisų backport, ir tuo metu ramiai planuoti perėjimą. Ketvirto kelio — palikti viską, kaip yra, nes svetainė juk veikia — iš tikrųjų nėra, nes PHP 8.1 ir senesni release branch iš PHP projekto pataisų nebegauna, 18 ir 20 release line taip pat ne, o 2026 metų spalis abiem atvejais parodė, ką tai reiškia praktikoje.

Svetainė su sena PHP versija paprastai nėra nei išimtis, nei koks ypatingas aplaidumas. Ji buvo sukurta prieš penkerius arba aštuonerius metus, kūrėjas, kuris ją sukūrė, seniai dirba kitur, ir visus šiuos metus svetainė tarnavo be didelių problemų: priimdavo paraiškas, rodydavo kainas ir siųsdavo sąskaitas. Pagal W3Techs duomenis 2026 metų spalį 26,8 % svetainių, kurios naudoja PHP, veikė su PHP 7 ir dar 7,7 % su PHP 5, taigi daugiau nei trečdalis jų naudoja PHP, kurio palaikymas baigėsi prieš kelerius metus. Klausimas paprastai kyla tik tada, kai hostingo teikėjas atsiunčia įspėjimą arba kai koks nors pažeidžiamumas patenka į naujienas.

Kada PHP arba Node.js versija pasensta

„Sena“ čia nėra skonio klausimas, nes ir PHP, ir Node.js skelbia grafiką, kuriame nurodyta, iki kurios datos kiekvienas release branch arba release line gauna pataisas. PHP kiekvienam release branch skiria dvejus metus Active support ir dar dvejus metus security-only support, kuriais išeina tik kritinių saugumo klaidų pataisos, o paskui release branch nebepalaikomas jokiu būdu. Node.js ilgalaikio palaikymo (LTS) release line pabaigoje yra Maintenance LTS, ir kai jis baigiasi, release line nebegauna nė vieno leidimo, net jei naujas pažeidžiamumas paliečia būtent ją.

Lentelėje yra release branch ir release line, su kuriais šiandien tenka susidurti dažniausiai, ir jų būsena 2026 metų spalį. Datos paimtos iš PHP end of life sąrašo ir Node.js leidimų grafiko, ir abu šaltinius reikia tikrinti ir toliau, nes kiekvienais metais juose atsiranda naujų eilučių.

Dvi šios lentelės eilutes verta perskaityti dar kartą. PHP 8.2 palaikymą praras 2026 metų gruodžio 31 dieną, taigi svetainė, kuri 2026 metų rudenį atrodo šiuolaikiška, 2027 metų sausį bus tokioje pačioje padėtyje kaip svetainė su PHP 7.4, ir perėjimą verta planuoti jau dabar, kol tai galima padaryti neskubant. Node.js 20 release line 2024 metų rudenį dar buvo aktyvi ilgalaikio palaikymo (LTS) release line, ant kurios buvo pradėta daug naujų projektų, bet 2026 metų balandžio 30 dieną ji palaikymą prarado. Senėjimas nevyksta laipsniškai: vieną konkrečią dieną runtime pereina iš „gauna pataisas“ į „negauna nieko“, ir svetainėje tą akimirką nepasikeičia niekas, ką būtų galima pastebėti.

Kodėl svetainė, kuri veikia, vis tiek yra pavojuje

Versija be palaikymo netampa pavojinga tą dieną, kai palaikymas baigiasi, o tą dieną, kai paskelbiamas pažeidžiamumas, kuris paliečia ir ją. Pataisa palaikomiems release branch išeina kartu su aprašymu, ir kai tik ji yra vieša, užpuolikai gali palyginti pataisytą kodą su nepataisytu ir suprasti, kur yra spraga. Node.js savo puslapyje apie palaikymo pabaigą tai sako tiesiai: jei pažeidžiamumas paliečia ir release line be palaikymo, jai naujas leidimas neišeis, ir tie, kurie tokioje release line pasilieka, iš karto yra neapsaugoti nuo atakų, kurios naudoja paskelbtą pažeidžiamumą.

2026 metų spalį būtent tai nutiko abiem platformoms beveik vienu metu. Spalio 21 dieną PHP išleido neeilines pataisas dviem kritiniams pažeidžiamumams, žinomiems PHP2Shell pavadinimu, ir oficialius leidimus gavo tik release branch nuo 8.2 iki 8.5, o tiems release branch 7.4, 8.0 ir 8.1 saugumo komanda išimties tvarka parengė tik minimalias šaltinio kodo pataisas tiems, kurie PHP pasistato patys. Tą pačią dieną Node.js išleido pataisas dešimčiai pažeidžiamumų, ir 18 bei 20 release line iš paties projekto jų negavo visai. Abu atvejus esame aprašę atskirai: straipsnyje apie PHP2Shell ir straipsnyje apie Node.js saugumo atnaujinimą.

Antroji rizika yra mažiau matoma, bet ilguoju laikotarpiu didesnė. Senas runtime neleidžia atnaujinti nieko, kas yra virš jo: WordPress įskiepiai, Composer ir npm paketai ir pats karkasas savo naujuose leidimuose seną PHP ir Node.js pamažu nustoja palaikyti, todėl svetainė negali gauti ir jų pataisų. Pats WordPress rekomenduoja PHP 8.3 arba naujesnę ir apie senesnius release branch rašo, kad jų oficialus palaikymas baigėsi ir jie gali padaryti svetainę neapsaugotą. Taip senas runtime nebėra viena atskira problema, o sluoksnis, kuris neleidžia išspręsti visų kitų.

Kai kas nors nutinka, kaina yra gerokai didesnė už suplanuotą atnaujinimą. Nulaužta svetainė reiškia valymą, atkūrimą iš atsarginės kopijos, slaptažodžių ir raktų keitimą ir, jei buvo paliesti klientų asmens duomenys, taip pat įvertinimą, ar apie asmens duomenų saugumo pažeidimą reikia pranešti priežiūros institucijai, ir visa tai vyksta skubant, kol svetainė neveikia arba rodo lankytojams svetimą turinį. Perėjimą šioje situacijoje vis tiek reikia atlikti, tik dabar jį tenka daryti po įsilaužimo, o ne prieš jį, ir be galimybės ramiai viską patikrinti testinėje aplinkoje.

Kodėl senos PHP versijos negalima tiesiog pakeisti hostingo skydelyje

Hostingo skydelyje perėjimas prie naujesnės PHP versijos atliekamas vienu spustelėjimu, ir būtent todėl jis klastingas: jei kodas tam neparuoštas, svetainė nustoja veikti kitą sekundę, dažnai su tuščiu puslapiu arba klaidos pranešimu. Pereinant prie kito pagrindinio leidimo, PHP sąmoningai išima funkcijas, kurios ilgus metus buvo pasenusios. PHP 7.0 išėmė seną mysql PHP extension, kuriuo rėmėsi daugelis senesnių svetainių, o PHP 8.0 savo nesuderinamų pakeitimų sąraše be kita ko išėmė funkcijas each() ir create_function(), kurios senesniame kode vis dar pasitaiko.

Node.js pasaulyje klasikinis pavyzdys yra 17 release line, kurioje runtime perėjo prie OpenSSL 3.0. Leidimo pranešime Node.js įspėjo, kad programa, kuri pati arba kurios moduliai naudoja algoritmą ar rakto ilgį, kurio OpenSSL 3.0 pagal numatymą nebeleidžia, gaus klaidą ERR_OSSL_EVP_UNSUPPORTED, ir kaip laikiną sprendimą pasiūlė paleidimo parametrą --openssl-legacy-provider. Klaidą neretai sukeldavo ne paties projekto kodas, o kuri nors iš jo priklausomybių, todėl ją tekdavo taisyti kode, kurio projekto komanda pati nė nebuvo rašiusi.

Todėl perėjimas yra kūrimo darbas, o ne nustatymas. Kodą reikia patikrinti su nauju runtime, pasenusias funkcijas pakeisti, priklausomybes atnaujinti iki leidimų, kurie jį palaiko, ir viską išbandyti testinėje aplinkoje, prieš klientams tai pamatant. Nedidelei svetainei prižiūrimoje platformoje tai gali būti kelių valandų darbas, o sistemai, kurios karkaso palaikymas baigėsi prieš kelerius metus, perėjimas neretai reiškia ir karkaso keitimą, ir tada tai jau yra projektas su savo biudžetu ir grafiku, o ne užduotis, kurią galima atlikti tarp kitų darbų.

Trys keliai: atnaujinti, perkurti arba laikyti apsaugotą

Kelią lemia du dalykai: kiek kodas yra atsilikęs nuo palaikomos versijos ir kiek ilgai svetainė dar turi tarnauti. Jei svetainę po metų vis tiek planuojama pakeisti nauja, imtis didelio perėjimo senajame kode neverta, o jei tai yra įmonės kasdienio darbo įrankis, kurį naudos dar bent penkerius metus, laikinas sprendimas tik atideda neišvengiamybę ir padaro ją brangesnę. Lentelėje yra trys keliai, kurie iš tikrųjų yra prieinami, ir tai, ką kiekvienas iš jų išsprendžia ir ko ne.

Atnaujinimas yra teisingas pasirinkimas, jei svetainė remiasi prižiūrima platforma, pavyzdžiui, WordPress arba Laravel, ir nuo palaikomo release branch ją skiria vienas arba du pagrindiniai žingsniai. Tada darbas yra nuspėjamas: reikia atnaujinti karkasą ir įskiepius, pataisyti tai, ką randa tikrinimo įrankiai, ir perjungti PHP. Perkūrimas yra sąžiningiausias kelias, jei pats karkasas nebeturi palaikymo, jei svetainė parašyta su PHP 5.x be jokio karkaso arba jei kodo nebesupranta niekas, nes tada atnaujinimo kaina greitai priartėja prie naujos svetainės kainos, o rezultatas vis tiek yra senas kodas.

Trečiasis kelias aptariamas rečiau. Seną svetainę galima laikyti platformoje, kuri jos runtime vis dar taiko saugumo pataisų backport, izoliuoja ją nuo kitų svetainių ir blokuoja žinomus atakos pavyzdžius dar prieš pataisą. Tai nėra perėjimo pakaitalas, ir pats Node.js tokį palaikymą vadina laikinu sprendimu, tačiau tai yra sąžiningas būdas gauti laiko: perėjimą galima atlikti suplanuotu tempu, o ne per savaitę po eilinio saugumo pranešimo. Svarbiausias žodis čia yra „terminas“, nes be jo laikinas sprendimas tampa nuolatiniu.

Kas yra backport ir kodėl versijos numeris apie tai nieko nepasako

Backport reiškia, kad saugumo pataisą, sukurtą naujesniam leidimui, kas nors pritaiko ir įdeda į senesnį leidimą, kurį naudotojas jau naudoja. Red Hat, kuris taip prižiūri savo Linux distribucijų paketus, rašo, kad vien pagal versijos numerį klientas negali spręsti, ar jo sistema yra pažeidžiama, nes pataisa pakeičia paketą, bet ne versijos numerį. Būtent todėl pažeidžiamumų skeneriai, kurie žiūri tik į numerį, tokiose sistemose neretai klaidingai praneša apie problemas, kurios jau yra pašalintos.

PHP ir Node.js atveju tai daro keli tiekėjai. Linux distribucijos savo PHP ir Node.js paketams taiko backport visą distribucijos palaikymo laiką. CloudLinux savo alt-php paketams, kuriuos naudoja hostingo serveriai su CloudLinux, backport taiko ir tiems release branch, kurių PHP palaikymas seniai baigėsi: PHP2Shell atveju jo būsenos puslapis spalio 21 dieną pranešė, kad ruošia pataisytus paketus visiems alt-php release branch nuo 5.2 iki 8.5, ir kitos nakties metu jie jau buvo prieinami. Šie paketai dabar yra įmonės TuxCare išplėstinio palaikymo dalis, kurio sąlygose kaip tikslas aukšto ir kritinio pavojingumo pažeidžiamumams nurodyta pataisa per 14 dienų nuo paskelbimo.

Node.js release line, kurios nebeturi palaikymo, tokią pačią paslaugą siūlo komerciniai partneriai, kuriuos pats Node.js įvardija savo palaikymo pabaigos puslapyje: HeroDevs, NodeSource ir TuxCare. Tačiau Node.js iškart priduria, kad toks palaikymas laikytinas laikinu sprendimu ir tikslas visada turi būti perėjimas prie palaikomos versijos. CloudLinux 2026 metų spalio Node.js leidimo metu pritaikė backport ir savo 16, 18 bei 20 release line paketams, kuriuos hostingo klientai renkasi cPanel skyriuje Setup Node.js App.

Patikrinti to pagal versijos numerį negalima. Komanda php -v arba node -v po backport rodo lygiai tą patį, ką ir prieš jį, ir CloudLinux savo Node.js pranešime tai rašo atvirai: nepalaikomų release line numeris po atnaujinimo nesikeičia. Keičiasi paketo release number, kurį mato tik serverio administratorius, todėl talpinime atsakymą gali duoti tik hostingo teikėjas.

Ribą reikia pasakyti taip pat aiškiai. Backport apsaugo patį PHP arba Node.js, bet neapsaugo WordPress įskiepio, kurio autorius nustojo jį atnaujinti, pačių rašyto kodo su SQL injekcija arba npm paketo, kurio naujesni leidimai seno Node.js nebepalaiko. Be to, tiekėjai backport taiko kiekvienai release line atskirai, todėl kiekvieną konkrečią reikia patikrinti, ar ji apskritai yra sąraše, ir TuxCare savo sąlygose pasilieka teisę vietoj pataisos pasiūlyti riziką mažinančią priemonę.

Kai sena yra ne runtime, o pati platforma

Kartais problema yra ne runtime, o pačioje platformoje, ant kurios svetainė pastatyta, ir tada PHP backport padeda tik iš dalies. Geriausias pavyzdys yra Drupal 7: jo saugumo palaikymas baigėsi 2025 metų sausio 5 dieną, ir nuo to laiko pats Drupal projektas jam nebeišleidžia nei saugumo, nei suderinamumo atnaujinimų. Drupal 7 svetainė gali veikti su visiškai pataisytu PHP, bet jos branduolys, moduliai ir tema vis tiek lieka su visais pažeidžiamumais, kurie juose dar bus rasti, nes nemokamai jų nebetaiso niekas.

Ir čia yra mokamas laikinas sprendimas: Drupal Association yra sukūrusi išplėstinio saugumo palaikymo programą, kurioje mokamą palaikymą siūlo patikrinti tiekėjai, pavyzdžiui, HeroDevs ir Tag1 Consulting. Tai tas pats principas kaip PHP backport, tik vienu sluoksniu aukščiau, ir jam galioja tie patys apribojimai: jis atideda perėjimą, bet jo neišsprendžia, ir kiekvieni metai senoje platformoje daro perėjimą brangesnį, nes auga atstumas iki dabartinio leidimo ir mažėja skaičius kūrėjų, kurie seną platformą dar išmano.

Todėl prieš bet kokį sprendimą verta patikrinti visus sluoksnius, ne tik PHP: runtime, platformą arba karkasą, įskiepius arba modulius ir pačių rašytą kodą. Jei pasenęs yra tik PHP, o WordPress, Laravel ar kita platforma yra prižiūrima, perėjimas paprastai yra nuspėjamas darbas. Jei sena yra pati platforma, klausimas jau ne apie PHP release branch, o apie tai, ar svetainę perkelti į platformos naują leidimą, ar statyti iš naujo, ir būtent čia backport užduotis yra duoti laiko šį sprendimą priimti neskubant.

Kaip seną PHP ir Node.js laikome savo serveryje

Mūsų profesionalus hostingas yra vieta mūsų pačių serveryje, kuris veikia su CloudLinux, ir kiekvienai svetainei PHP versija pasirenkama atskirai hostingo skydelyje. Šiuo metu šiame hostinge yra PHP nuo 5.4 iki 8.4, o Node.js programoms tiek palaikomos 22 ir 24 release line, tiek senos 16, 18 ir 20 release line. Tai reiškia, kad seną svetainę pas mus galima perkelti su tuo pačiu PHP arba Node.js, su kuriuo ji veikia dabar, ir pirmiausia ją stabilizuoti, o ne perkėlimo dieną kartu keisti ir kodą, ir tai yra saugiausias būdas perkėlimo metu nieko nesulaužyti.

Kaip tai veikia praktikoje, 2026 metų spalį galėjome išmatuoti patys. PHP2Shell pataisos išėjo spalio 21 dienos popietę, ir mūsų serveryje visi seni PHP release branch nuo 5.4 iki 8.1 dabar veikia su paketais, kuriuos CloudLinux surinko iš naujo tos pačios dienos naktį, mažiau nei per parą po PHP leidimo, ir kuriuose pataisa įdėta kaip backport. Release branch nuo 8.2 iki 8.4 perėjo prie oficialių pataisytų leidimų 8.2.35, 8.3.36 ir 8.4.27, o Node.js 16, 18 ir 20 release line spalio 22 dieną gavo CloudLinux paketus su backport, nors pats Node.js projektas joms pataisų neišleido. Senų release branch numeris nepasikeitė, todėl tai tikrinome ne pagal numerį, o pagal tai, kada vykdomieji failai buvo surinkti iš naujo.

Tai dar ne viskas, ką platforma daro. CloudLinux kiekvieną hostingo paskyrą įdeda į atskirą izoliuotą aplinką (account isolation), vadinamą CageFS, ir joje naudotojai nemato kitų serverio naudotojų ir net jų naudotojų vardų, o tai apsunkina įsilaužimo plitimą iš vienos paskyros į kitas. Imunify360 žiniatinklio programų ugniasienė (WAF) PHP2Shell atveju pradėjo blokuoti žinomus atakos pavyzdžius spalio 21 dieną, kelias valandas prieš pataisyto PHP paskelbimą. Nė vienas iš šių sluoksnių nepadaro seną svetainę nepažeidžiamą, tačiau kartu jie susiaurina laiką, per kurį žinomas pažeidžiamumas yra išnaudojamas, ir apriboja, kaip toli įsilaužimo pasekmės gali siekti.

Todėl senos svetainės perkėlimą pas mus rekomenduojame laikyti laikinu sprendimu su terminu, o ne galutiniu tikslu. Svetainę perkeliame su tuo pačiu runtime, patikriname, kad viskas veikia taip pat kaip anksčiau, ir paskui kartu su Jumis susitariame, iki kurios datos ir kokia tvarka ji pereina prie palaikomos versijos, kad laikinas sprendimas netaptų nuolatiniu. Mūsų profesionalus hostingas prasideda nuo 45 € per mėnesį, ir prižiūrimi runtime, account isolation bei ugniasienė yra dalis to, už ką šioje sumoje mokama. Jei Jums yra svetainė su sena PHP arba Node.js versija, atsiųskite mums jos adresą, ir mes pasakysime, kuris iš trijų kelių jai tinka ir nuo ko pradėti.

Kaip sužinoti, kuri PHP arba Node.js versija yra Jūsų svetainėje

Greičiausias kelias yra hostingo skydelis. cPanel hostinge su CloudLinux skyrius Select PHP Version rodo versiją, pasirinktą visam kontui, o MultiPHP Manager rodo versiją kiekvienam domenui atskirai, ir jei domenui ten nurodyta sava versija, lemiama yra ji. Node.js programoms tą patį rodo skyrius Setup Node.js App, kur kiekviena programa turi savo eilutę. Žiūrėti verta į kiekvieną svetainę, ne tik į pagrindinę, nes vienoje paskyroje neretai būna kelios svetainės su skirtingais PHP release branch, o pamiršta testinė kopija arba senas kampanijos puslapis neretai tebėra pasiekiamas iš interneto.

WordPress svetainėje tai galima pamatyti ir administravimo skydelyje: skyriuje Tools → Site Health, skirtuke Info, bloke Server nurodyta PHP versija, su kuria svetainė veikia. Jei skydelio nėra, galima sukurti failą su funkcija phpinfo() ir atidaryti jį naršyklėje, tačiau paskui failą būtina ištrinti, nes jis kiekvienam lankytojui parodo serverio konfigūraciją. Komanda php -v čia padeda mažiau, nei atrodo, nes ji rodo komandinės eilutės PHP, o žiniatinklio užklausas dažnai aptarnauja kitas release branch, pasirinktas hostingo skydelyje. Node.js projekte pageidaujamą release line dažnai nurodo package.json laukas engines arba failas .nvmrc, bet tai tėra pageidavimas, o kuris Node.js programą iš tikrųjų paleidžia, matyti ten, kur procesas yra paleidžiamas.

Jei prieigos nėra iš viso, klausimą reikia užduoti hostingo teikėjui arba kūrėjui, kuris svetainę prižiūri. Formuluotė, kuri sutaupo susirašinėjimą: „Kuri PHP arba Node.js versija aptarnauja mūsų svetainę? Jei jos palaikymas baigėsi, ar ji gauna saugumo pataisų backport, iš kur jie ateina ir kada paketas paskutinį kartą buvo atnaujintas? Iki kurios datos Jūs rekomenduojate perėjimą?“ Atsakymas į paskutinį klausimą daug pasako ir apie patį teikėją, nes jei datos nėra, paprastai nėra ir plano.

Perėjimas prie palaikomos versijos: kaip jį atlikti be staigmenų

Perėjimas prasideda nuo inventorizacijos, o ne nuo perjungimo. Reikia užsirašyti, kuris PHP release branch ir kurie PHP extension svetainei reikalingi, kokios suplanuotos užduotys ją paleidžia fone, su kokiomis išorinėmis sistemomis ji susisiekia ir kurios jos dalys yra kritinės verslui, pavyzdžiui, užsakymo forma, mokėjimai arba sąskaitų siuntimas. Tikslinę versiją verta rinktis su atsarga: PHP 8.4 saugumo pataisas gaus iki 2028 metų gruodžio 31 dienos, PHP 8.3 iki 2027 metų pabaigos, o perėjimas prie PHP 8.2, kurios palaikymas baigiasi jau 2026 metų pabaigoje, reikštų dar vieną perėjimą visai greitai. Node.js atveju tikslas daugeliu atvejų yra 24 release line.

Antrasis žingsnis yra kodo patikra, ir PHP kodui ją galima didele dalimi automatizuoti. PHPCompatibility yra PHP_CodeSniffer taisyklių rinkinys, kuris tikrina, ar kodas suderinamas su konkrečia PHP versija, o Rector dalį reikiamų pakeitimų gali atlikti automatiškai. Nė vienas iš jų nepakeičia žmogaus patikros, tačiau jie greitai parodo, ar darbo apimtis matuojama valandomis, ar savaitėmis, ir būtent tai reikalinga, kad būtų galima rinktis tarp atnaujinimo ir perkūrimo. WordPress svetainei pirmiausia reikia atnaujinti įskiepius ir temą, ir tik paskui perjungti PHP.

Trečiasis žingsnis yra testinė aplinka, tai yra svetainės kopija su nauju PHP arba Node.js, kurioje išbandomi visi kritiniai veiksmai: formos, mokėjimai, elektroninio pašto siuntimas, importas ir eksportas. Klaidų žurnalas šiame etape yra svarbesnis už vizualinę patikrą, nes įspėjimai apie pasenusias funkcijas ten pasirodo dar gerokai prieš tai, kai kas nors sustoja. Ketvirtasis žingsnis yra perjungimas mažos apkrovos metu su galimybe grįžti: hostinge su versijos pasirinkimu kelias atgal yra tas pats vienas spustelėjimas, kuriuo ji buvo perjungta, todėl rizika nedidelė, jei tik atsarginė kopija yra šviežia ir kas nors pirmą savaitę seka klaidų žurnalą.

Node.js programai logika yra ta pati, tik įrankiai kiti. Perėjimą tarp pagrindinių release line verta daryti po vieną, po kiekvieno paleidžiant programos testus, ir ypatingą dėmesį reikia skirti paketams su sukompiliuotu kodu, nes jie kuriami konkrečiai Node.js release line ir po perėjimo juos reikia surinkti iš naujo. Pirmiausia reikia atnaujinti priklausomybes, kurios naują release line dar nepalaiko, ir tik paskui keisti patį runtime, kitaip klaidos iš abiejų pusių susimaišo ir sunku suprasti, kuri iš jų ką sukėlė.