Mida teha veebilehega, millel on vana PHP või Node.js versioon?

Lühike vastus on järgmine: veebilehel, millel on vana PHP või Node.js versioon, on kolm teed — kohandada kood toetatud väljalaskele, ehitada veebileht uuesti üles või hoida seda mõnda aega platvormil, mis vanale runtime'ile endiselt turvapaiku backport'ib, ja samal ajal rahulikult üleminekut planeerida. Neljandat teed, jätta kõik nii, nagu on, sest veebileht ju töötab, tegelikult ei ole, sest PHP 8.1 ja vanemad release branch'id ei saa PHP projektist enam turvapaiku, Node.js-i 18. ja 20. release line'id samuti mitte, ja 2026. aasta oktoober näitas mõlemal juhul, mida see praktikas tähendab.

Vana PHP versiooniga veebileht ei ole tavaliselt ei erand ega mingi eriline hooletus. See tehti viis või kaheksa aastat tagasi, arendaja, kes selle ehitas, töötab ammu mujal, ja veebileht on kõik need aastad toiminud ilma suuremate probleemideta: võtnud vastu päringuid, näidanud hindu ja saatnud arveid. W3Techsi andmetel töötas 2026. aasta oktoobris 26,8% PHP-d kasutavatest veebilehtedest PHP 7 peal ja veel 7,7% PHP 5 peal, nii et enam kui kolmandik neist kasutab PHP-d, mis on juba mitu aastat end of life'is. Küsimus tekib tavaliselt alles siis, kui majutaja saadab hoiatuse või kui mõni turvanõrkus jõuab uudistesse.

Millal PHP või Node.js versioon vanaks muutub

„Vana“ ei ole siin maitse küsimus, sest nii PHP kui ka Node.js avaldavad graafiku, kus on kirjas, millise kuupäevani iga release branch või release line turvapaiku saab. PHP annab igale release branch'ile kaks aastat Active support'i ja veel kaks aastat security-only support'i, mille jooksul ilmuvad ainult kriitiliste turvanõrkuste turvapaigad, ja pärast seda ei toetata seda enam mingil viisil. Node.js-i pikaajalise toe release line'idel on lõpus Maintenance LTS, ja kui see lõpeb, ei tule enam ühtegi väljalaset, isegi siis, kui uus turvanõrkus puudutab just seda line'i.

Tabelis on release branch'id ja release line'id, millega tänapäeval kõige sagedamini kokku puututakse, ja nende seis 2026. aasta oktoobris. Kuupäevad on võetud PHP toe lõpu nimekirjast ja Node.js-i väljalaskegraafikust, ja mõlemat allikat tuleb ka edaspidi kontrollida, sest igal aastal ilmuvad sinna uued read.

Kahte rida selles tabelis tasub lugeda veel kord. PHP 8.2 kaotab toe 2026. aasta 31. detsembril, nii et veebileht, mis 2026. aasta sügisel näib ajakohane, on 2027. aasta jaanuaris samas olukorras kui veebileht PHP 7.4 peal, ja üleminekut tasub planeerida juba praegu, kuni seda saab teha ilma kiirustamata. Node.js 20 release line oli veel 2024. aasta sügisel Active LTS release line, millele alustati paljusid uusi projekte, kuid 2026. aasta 30. aprillil kaotas see toe. Vananemine ei toimu tasapisi: ühel kindlal päeval läheb runtime seisust „saab turvapaiku“ seisusse „ei saa midagi“, ja veebilehel ei muutu sel hetkel midagi, mida oleks võimalik märgata.

Miks töötav veebileht on ikkagi ohus

Versioon, mis on end of life'is, ei muutu ohtlikuks sel päeval, kui tugi lõpeb, vaid sel päeval, kui avaldatakse turvanõrkus, mis puudutab ka seda. Toetatud release branch'ide turvapaik ilmub koos kirjeldusega, ja niipea kui see on avalik, saavad ründajad võrrelda parandatud koodi parandamata koodiga ning aru saada, kus auk on. Node.js ütleb oma toe lõpu lehel seda otse: kui turvanõrkus puudutab ka release line'i, millel tuge ei ole, ei tule sellele uut väljalaset, ja need, kes sellisele line'ile jäävad, on kohe kaitseta rünnakute vastu, mis kasutavad avaldatud turvanõrkust.

2026. aasta oktoobris juhtus just see mõlema platvormiga peaaegu ühel ajal. 21. oktoobril andis PHP välja erakorralised turvapaigad kahele kriitilisele turvanõrkusele, mida tuntakse nimega PHP2Shell, ja ametlikud väljalasked said ainult release branch'id 8.2-st 8.5-ni, kuid release branch'idele 7.4, 8.0 ja 8.1 valmistas turvameeskond erandkorras üksnes minimaalsed lähtekoodi turvapaigad neile, kes PHP-d ise ehitavad. Samal päeval andis Node.js välja turvapaigad kümnele turvanõrkusele, ja 18. ning 20. release line'id ei saanud neid projektilt endalt üldse. Mõlemat juhtumit oleme täpsemalt kirjeldanud eraldi: PHP2Shelli artiklis ja Node.js-i turvauuenduse artiklis.

Teine risk on vähem nähtav, kuid pikemas plaanis suurem. Vana runtime ei lase uuendada midagi, mis asub selle peal: WordPressi pistikprogrammid, Composer'i ja npm-i paketid ning raamistik ise lõpetavad uutes väljalasetes vana PHP ja Node.js-i toetamise järk-järgult, seepärast ei saa veebileht ka nende turvapaiku. WordPress ise soovitab PHP 8.3 või uuemat ja kirjutab vanemate release branch'ide kohta, et nende ametlik tugi on lõppenud ja need võivad jätta veebilehe kaitseta. Nii ei ole vana runtime enam üks eraldi probleem, vaid kiht, mis ei lase lahendada kõiki teisi.

Kui midagi juhtub, on hind tublisti kõrgem kui planeeritud uuendamisel. Sissemurtud veebileht tähendab puhastamist, taastamist varukoopiast, paroolide ja võtmete vahetamist ja, kui puudutati klientide isikuandmeid, ka hinnangut, kas isikuandmetega seotud rikkumisest tuleb teatada järelevalveasutusele, ning kõik see toimub kiirustades, samal ajal kui veebileht ei tööta või näitab külastajatele võõrast sisu. Üleminek tuleb selles olukorras niikuinii ära teha, ainult et nüüd pärast sissemurdmist, mitte enne seda, ja ilma võimaluseta rahulikult kõike testkeskkonnas kontrollida.

Miks vana PHP versiooni ei saa majutuspaneelis lihtsalt ära vahetada

Majutuspaneelis võtab üleminek uuemale PHP versioonile ühe klõpsu, ja just seepärast on see salakaval: kui kood selleks valmis ei ole, lakkab veebileht töötamast järgmisel sekundil, sageli tühja lehe või veateatega. Järgmisele põhiversioonile üle minnes eemaldab PHP teadlikult funktsioonid, mis olid aastaid aegunud. PHP 7.0 eemaldas vana mysql PHP extension'i, millele toetusid paljud vanemad veebilehed, PHP 8.0 aga oma ühildumatute muudatuste nimekirjas eemaldas muu hulgas funktsioonid each() ja create_function(), mida vanemas koodis ikka veel leidub.

Node.js-i maailmas on klassikaline näide 17. release line, kus runtime läks üle OpenSSL 3.0-le. Väljalasketeates hoiatas Node.js, et rakendus, mis ise või mille moodulid kasutavad algoritmi või võtme pikkust, mida OpenSSL 3.0 vaikimisi enam ei luba, saab vea ERR_OSSL_EVP_UNSUPPORTED, ja ajutise lahendusena pakkus käivitusparameetrit --openssl-legacy-provider. Sageli ei põhjustanud viga mitte projekti enda kood, vaid mõni selle sõltuvustest, seepärast tuli parandada koodi, mida projekti meeskond ise polnudki kirjutanud.

Seepärast on üleminek arendustöö, mitte seadistus. Kood tuleb uue runtime'i vastu üle kontrollida, aegunud funktsioonid asendada, sõltuvusi uuendada väljalaseteni, mis seda toetavad, ja kõik testkeskkonnas läbi proovida, enne kui kliendid seda näevad. Väikesele veebilehele toetatud platvormil võib see olla mõne tunni töö, kuid süsteemil, mille raamistiku tugi lõppes mitu aastat tagasi, tähendab üleminek sageli ka raamistiku väljavahetamist, ja siis on see juba projekt oma eelarve ja ajakavaga, mitte ülesanne, mille saab teiste tööde vahel ära teha.

Kolm teed: uuendada, ümber ehitada või hoida kaitstuna

Tee määravad kaks asja: kui kaugele kood toetatud versioonist maha on jäänud ja kui kaua veebileht veel teenima peab. Kui veebileht nagunii aasta pärast uuega asendatakse, ei tasu vanas koodis suurt üleminekut teha, kuid kui see on ettevõtte igapäevane töövahend, mida kasutatakse veel vähemalt viis aastat, lükkab ajutine lahendus paratamatu ainult edasi ja teeb selle kallimaks. Tabelis on kolm teed, mis tegelikult olemas on, ja see, mida igaüks neist lahendab ja mida mitte.

Uuendamine on õige valik, kui veebileht põhineb toetatud platvormil, näiteks WordPressil või Laravelil, ja toetatud release branch'ist lahutab seda üks või kaks põhiversiooni. Siis on töö etteaimatav: tuleb uuendada raamistikku ja pistikprogramme, parandada see, mida kontrolliriistad leiavad, ja PHP ümber lülitada. Ümber ehitamine on ausaim tee, kui raamistik ise on toeta, kui veebileht on kirjutatud PHP 5.x peale ilma ühegi raamistikuta või kui koodi ei mõista enam keegi, sest siis läheneb uuendamise hind kiiresti uue veebilehe hinnale, tulemus on aga ikkagi vana kood.

Kolmandat teed arutatakse harvem. Vana veebilehte saab hoida platvormil, mis selle runtime'ile endiselt turvapaiku backport'ib, isoleerib selle teistest veebilehtedest ja blokeerib teadaolevad ründemustrid juba enne turvapaika. See ei asenda üleminekut, ja Node.js ise nimetab sellist tuge ajutiseks lahenduseks, kuid see on aus viis aega võita: ülemineku saab teha planeeritud tempos, mitte nädal pärast järjekordset turvateadet. Kõige tähtsam sõna siin on „tähtaeg“, sest ilma selleta muutub ajutine lahendus püsivaks.

Mis on backport ja miks versiooninumber selle kohta midagi ei ütle

Backport tähendab, et turvapaik, mis on tehtud uuemale väljalaskele, kohandatakse ja ehitatakse sisse vanemasse väljalaskesse, mida kasutaja juba kasutab. Red Hat, kes hoiab oma Linuxi distributsiooni pakette just nii, kirjutab, et ainult versiooninumbri järgi ei saa klient otsustada, kas tema süsteemil on turvanõrkus, sest parandus muudab paketti, kuid mitte versiooninumbrit. Just seepärast kipuvad turvanõrkuste skannerid, mis vaatavad ainult numbrit, sellistes süsteemides ekslikult teatama probleemidest, mis on juba kõrvaldatud.

PHP ja Node.js-i puhul teevad seda mitu tarnijat. Linuxi distributsioonid backport'ivad turvapaiku oma PHP ja Node.js-i pakettidele kogu distributsiooni toe aja. CloudLinux backport'ib oma alt-php pakettidele, mida CloudLinuxiga majutusserverid kasutavad, turvapaiku ka neile release branch'idele, mille PHP tugi ammu lõppes: PHP2Shelli puhul teatas selle olekuleht 21. oktoobril, et valmistab parandatud paketid kõigile alt-php release branch'idele 5.2-st 8.5-ni, ja järgmise öö jooksul olid need saadaval. Need paketid on nüüd osa ettevõtte TuxCare laiendatud toest (ELS), mille tingimustes on kõrge ja kriitilise ohtlikkusega turvanõrkuste eesmärgiks nimetatud turvapaik 14 päeva jooksul pärast avalikustamist.

Toeta Node.js-i release line'idele pakub sama teenust kommertspartnerid, keda Node.js ise oma toe lõpu lehel nimetab: HeroDevs, NodeSource ja TuxCare. Node.js lisab kohe, et sellist tuge tuleb pidada ajutiseks lahenduseks ja eesmärk peab alati olema üleminek toetatud versioonile. CloudLinux backport'is turvapaigad 2026. aasta oktoobri Node.js-i väljalaske ajal ka oma 16., 18. ja 20. release line'i pakettidele, mida majutuskliendid valivad cPaneli jaotises Setup Node.js App.

Versiooninumbri järgi seda kontrollida ei saa. Käsk php -v või node -v näitab pärast backport'i täpselt sedasama, mida enne seda, ja CloudLinux kirjutab oma Node.js-i teadaandes seda otse: toeta line'idel number pärast uuendamist ei muutu. Muutub release number, mida näeb ainult serveri administraator, seepärast saab virtuaalserveris vastuse anda üksnes majutaja.

Piir tuleb öelda sama selgelt. Backport kaitseb PHP-d või Node.js-i ennast, kuid ei kaitse WordPressi pistikprogrammi, mille autor lõpetas selle uuendamise, ise kirjutatud koodi, milles on SQL-i süstimine, ega npm-i paketti, mille uuemad väljalasked vana Node.js-i enam ei toeta. Pealegi backport'ivad tarnijad turvapaiku igale release line'ile eraldi, seepärast tuleb igaühe puhul kontrollida, kas see üldse nimekirjas on, ja TuxCare jätab oma tingimustes endale õiguse pakkuda turvapaiga asemel riski vähendavat meedet.

Kui vana ei ole runtime, vaid platvorm ise

Mõnikord ei ole probleem runtime'is, vaid platvormis endas, millele veebileht on ehitatud, ja siis aitavad PHP backport'id ainult osaliselt. Parim näide on Drupal 7: selle turvatugi lõppes 2025. aasta 5. jaanuaril, ja pärast seda ei anna Drupal projekt ise sellele enam välja ei turvapaiku ega ühilduvusuuendusi. Drupal 7 veebileht võib töötada täielikult parandatud PHP peal, kuid Drupali tuum, moodulid ja teema jäävad ikkagi kõigi turvanõrkustega, mis neis veel leitakse, sest tasuta ei paranda neid enam keegi.

Ka siin on olemas tasuline ajutine lahendus: Drupal Association on loonud Extended Security Support Provider Program'i, kus tasulist tuge pakuvad kontrollitud tarnijad, näiteks HeroDevs ja Tag1 Consulting. See on sama põhimõte mis PHP backport'idel, ainult ühe kihi võrra kõrgemal, ja sellel on samad piirid: see lükkab ülemineku edasi, kuid ei lahenda seda, ja iga aasta vanal platvormil teeb ülemineku kallimaks, sest vahemaa praeguse väljalaskeni kasvab ja kahaneb nende arendajate hulk, kes vana platvormi veel tunnevad.

Seepärast tasub enne iga otsust kontrollida kõiki kihte, mitte ainult PHP-d: runtime'i, platvormi või raamistikku, pistikprogramme või mooduleid ja ise kirjutatud koodi. Kui aegunud on ainult PHP, kuid WordPress, Laravel või muu platvorm on toetatud, on üleminek tavaliselt etteaimatav töö. Kui vana on platvorm ise, ei ole küsimus enam PHP release branch'is, vaid selles, kas veebileht viia platvormi uuele väljalaskele või ehitada uuesti, ja just siin on backport'ide ülesanne anda aega see otsus kiirustamata vastu võtta.

Kuidas me vana PHP-d ja Node.js-i oma serveris hoiame

Meie hallatav veebimajutus on koht meie enda serveris, mis töötab CloudLinuxil, ja igale veebilehele valitakse PHP versioon eraldi majutuspaneelis. Praegu on seal saadaval PHP 5.4-st 8.4-ni, Node.js-i rakendustele aga nii toetatud 22. ja 24. release line'id kui ka vanad 16., 18. ja 20. release line'id. See tähendab, et vana veebilehe saab meile kolida sama PHP või Node.js-iga, millega see praegu töötab, ja kõigepealt selle stabiliseerida, mitte kolimise päeval ühtlasi koodi muuta, mis on kõige kindlam viis kolimise ajal mitte midagi katki teha.

Kuidas see praktikas töötab, saime 2026. aasta oktoobris ise mõõta. PHP2Shelli turvapaigad ilmusid 21. oktoobri pärastlõunal, ja meie serveris töötavad nüüd kõik vanad PHP release branch'id 5.4-st 8.1-ni pakettidel, mille CloudLinux sama päeva öösel ümber ehitas, vähem kui ööpäev pärast PHP väljalaset, ja milles turvapaik on backport'itud. Release branch'id 8.2-st 8.4-ni läksid üle ametlikele parandatud väljalasetele 8.2.35, 8.3.36 ja 8.4.27, Node.js-i 16., 18. ja 20. release line'id aga said 22. oktoobril CloudLinuxi paketid backport'itud turvapaikadega, ehkki Node.js-i projekt ise neile turvapaiku välja ei andnud. Vanadel release branch'idel number ei muutunud, seepärast kontrollisime mitte numbri, vaid selle järgi, millal käivitatavad failid ümber ehitati.

See ei ole kõik, mida platvorm teeb. CloudLinux paneb iga majutuskonto eraldi isoleeritud keskkonda nimega CageFS, mis on account isolation: seal ei näe kasutajad teisi serveri kasutajaid ega isegi nende kasutajanimesid, mis raskendab sissemurdmise levikut ühelt kontolt teistele. Imunify360 veebirakenduse tulemüür (WAF) hakkas PHP2Shelli puhul teadaolevaid ründemustreid blokeerima 21. oktoobril, mitu tundi enne parandatud PHP avaldamist. Ükski neist kihtidest ei muuda vana veebilehte haavamatuks, kuid koos kitsendavad need aega, mille jooksul teadaolevat turvanõrkust saab ära kasutada, ja piiravad, kui kaugele sissemurdmise tagajärjed ulatuvad.

Seepärast soovitame vana veebilehe kolimist meile võtta ajutise lahendusena, millel on tähtaeg, mitte lõppeesmärgina. Kolime veebilehe sama runtime'iga, kontrollime, et kõik töötab nagu varem, ja lepime seejärel koos teiega kokku, millise kuupäevani ja mis järjekorras see läheb üle toetatud versioonile, et ajutine lahendus püsivaks ei muutuks. Meie hallatav veebimajutus algab 45 € kuus, ja hooldatud runtime'id, account isolation ning veebirakenduse tulemüür on osa sellest, mille eest selles summas makstakse. Kui teil on veebileht vana PHP või Node.js-i versiooniga, saatke meile selle aadress, ja me ütleme, milline kolmest teest sellele sobib ja millest alustada.

Kuidas teada saada, milline PHP või Node.js-i versioon teie veebilehel on

Kiireim tee on majutuspaneel. cPaneli majutuses CloudLinuxiga näitab jaotis Select PHP Version versiooni, mis on valitud kogu kontole, MultiPHP Manager aga versiooni igale domeenile eraldi, ja kui domeenile on seal oma versioon määratud, on määrav just see. Node.js-i rakendustele näitab sedasama jaotis Setup Node.js App, kus igal rakendusel on oma rida. Vaadata tasub iga veebilehte, mitte ainult peamist, sest ühel kontol on sageli mitu veebilehte erinevatel PHP release branch'idel, ja unustatud testkoopia või vana kampaania leht on internetist tihti endiselt kättesaadav.

WordPressi veebilehel on see näha ka halduspaneelis: jaotises Tööriistad → Saidi tervis, vahekaardil Info, plokis Server on kirjas PHP versioon, millel veebileht töötab. Kui paneeli ei ole, võib teha faili funktsiooniga phpinfo() ja avada selle brauseris, kuid pärast tuleb fail kindlasti kustutada, sest see näitab igale külastajale serveri seadistust. Käsk php -v aitab siin vähem, kui tundub, sest see näitab käsurea PHP-d, veebipäringuid teenindab aga sageli teine release branch, mis on majutuspaneelis valitud. Node.js-i projektis nimetab soovitud release line'i sageli package.json väli engines või fail .nvmrc, kuid see on ainult soov, ja seda, milline Node.js rakendust tegelikult käitab, tuleb vaadata sealt, kus protsess käivitatakse.

Kui juurdepääsu ei ole üldse, tuleb küsimus esitada majutajale või arendajale, kes veebilehte hoiab. Sõnastus, mis säästab kirjavahetust: „Milline PHP või Node.js-i versioon teenindab meie veebilehte? Kui see on end of life'is, kas see saab turvapaikade backporte, kust need tulevad ja millal paketti viimati uuendati? Millise kuupäevani teie üleminekut soovitate?“ Vastus viimasele küsimusele ütleb palju ka teenusepakkuja enda kohta, sest kui kuupäeva ei ole, ei ole tavaliselt ka plaani.

Üleminek toetatud versioonile: kuidas seda teha ilma üllatusteta

Üleminek algab inventuurist, mitte ümberlülitamisest. Kirja tuleb panna, millist PHP release branch'i ja milliseid PHP extension'eid veebileht vajab, millised ajastatud ülesanded seda taustal käitavad, milliste väliste süsteemidega see suhtleb ja millised selle osad on ärile kriitilised, näiteks tellimuse vorm, maksed või arvete saatmine. Sihtversioon tasub valida varuga: PHP 8.4 saab turvapaiku kuni 2028. aasta 31. detsembrini, PHP 8.3 kuni 2027. aasta lõpuni, üleminek PHP 8.2-le, mille tugi lõpeb juba 2026. aasta lõpus, tähendaks aga üsna pea veel üht üleminekut. Node.js-i puhul on siht enamikul juhtudel 24. release line.

Teine samm on koodi kontroll, ja PHP koodi puhul saab seda suures osas automatiseerida. PHPCompatibility on PHP_CodeSniffer'i reeglite komplekt, mis kontrollib, kas kood sobib kindla PHP versiooniga, Rector aga suudab osa vajalikest muudatustest teha automaatselt. Kumbki neist ei asenda inimese kontrolli, kuid need näitavad kiiresti, kas töö maht on mõõdetav tundides või nädalates, ja just seda on vaja, et otsustada uuendamise ja ümber ehitamise vahel. WordPressi veebilehel tuleb kõigepealt uuendada pistikprogramme ja teemat ning alles seejärel PHP ümber lülitada.

Kolmas samm on testkeskkond, see tähendab veebilehe koopia uue PHP või Node.js-iga, kus proovitakse läbi kõik kriitilised toimingud: vormid, maksed, e-kirjade saatmine, import ja eksport. Vealogi on selles etapis tähtsam kui visuaalne kontroll, sest hoiatused aegunud funktsioonide kohta ilmuvad sinna kaua enne seda, kui miski seiskub. Neljas samm on ümberlülitamine madala koormuse ajal koos võimalusega tagasi pöörduda: majutuses, kus versiooni saab valida, on tagasitee seesama üks klõps, millega see ümber lülitati, seepärast on risk väike, kui varukoopia on värske ja keegi jälgib esimesel nädalal vealogi.

Node.js-i rakendusel on loogika sama, ainult tööriistad on teised. Üleminekut ühelt release line'i põhiversioonilt järgmisele tasub teha ühekaupa, pärast igaüht rakenduse testid käivitades, ja erilist tähelepanu vajavad paketid kompileeritud koodiga, sest need ehitatakse kindlale Node.js-i release line'ile ja pärast üleminekut tuleb need uuesti ehitada. Kõigepealt tuleb uuendada sõltuvusi, mis uut release line'i veel ei toeta, ja alles seejärel muuta runtime'i ennast, muidu segunevad vead mõlemalt poolt ja on raske aru saada, kumb mida põhjustas.