Vad gör du med en webbplats som har en gammal PHP- eller Node.js-version?

Det korta svaret är detta: en webbplats med en gammal PHP- eller Node.js-version har tre vägar — att anpassa koden till en utgåva som har stöd, att bygga om webbplatsen från grunden eller att tills vidare hålla den på en plattform som fortfarande backportar säkerhetsuppdateringar till den gamla runtimen, och under tiden planera övergången i lugn och ro. En fjärde väg, att lämna allt som det är för att webbplatsen ju fungerar, finns i praktiken inte, eftersom PHP 8.1 och äldre release branches inte längre får några rättningar från PHP-projektet, och inte heller Node.js release line 18 och 20, och oktober 2026 visade i båda fallen vad det betyder i praktiken.

En webbplats med en gammal PHP-version är vanligtvis varken ett undantag eller någon särskild försummelse. Den byggdes för fem eller åtta år sedan, utvecklaren som byggde den har sedan länge arbetat någon annanstans, och under alla dessa år har webbplatsen fungerat utan större problem: den har tagit emot förfrågningar, visat priser och skickat fakturor. Enligt W3Techs uppgifter körde i oktober 2026 26,8 % av de webbplatser som använder PHP på PHP 7, och ytterligare 7,7 % på PHP 5, så mer än en tredjedel av dem använder en PHP vars stöd tog slut för flera år sedan. Frågan brukar uppstå först när hostingleverantören skickar en varning eller när en sårbarhet hamnar i nyheterna.

När en PHP- eller Node.js-version blir gammal

”Gammal” är här ingen smakfråga, eftersom både PHP och Node.js publicerar ett schema som anger till vilket datum varje release branch eller release line får rättningar. PHP ger varje release branch två år av Active support och ytterligare två år med endast säkerhetsfixar för kritiska fel, och därefter stöds den release branchen inte längre på något sätt. Release lines med långtidssupport i Node.js har i slutet fasen Maintenance LTS, och när den tar slut får linjen inte längre någon utgåva, inte ens om en ny sårbarhet träffar just den.

I tabellen står de release branches och release lines som man oftast stöter på i dag, och deras läge i oktober 2026. Datumen är hämtade från PHP:s lista över end of life och Node.js releaseschema, och båda källorna behöver kontrolleras även framöver, eftersom det varje år tillkommer nya rader.

Två rader i den här tabellen är värda att läsa en gång till. PHP 8.2 förlorar stödet den 31 december 2026, så en webbplats som hösten 2026 ser modern ut befinner sig i januari 2027 i samma läge som en webbplats med PHP 7.4, och övergången är värd att planera redan nu, medan den kan göras utan brådska. Node.js release line 20 var ännu hösten 2024 den aktiva linjen för långtidssupport (Active LTS), den som många nya projekt startades på, men den 30 april 2026 förlorade den stödet. Åldrandet sker inte gradvis: på en bestämd dag går runtimen från ”får rättningar” till ”får ingenting”, och på webbplatsen förändras i det ögonblicket ingenting som går att lägga märke till.

Varför en webbplats som fungerar ändå är utsatt

En version utan stöd blir inte farlig den dag stödet tar slut, utan den dag en sårbarhet publiceras som träffar även den. Rättningen för de release branches som har stöd kommer tillsammans med en beskrivning, och så snart den är offentlig kan angripare jämföra rättad kod med orättad och se var bristen sitter. Node.js säger det rakt ut på sin sida om end of life: om en sårbarhet också träffar en release line utan stöd kommer ingen ny utgåva för den, och den som stannar kvar på en sådan linje är genast oskyddad mot angrepp som utnyttjar den publicerade sårbarheten.

I oktober 2026 hände just det med båda plattformarna, nästan samtidigt. Den 21 oktober släppte PHP akuta rättningar för två kritiska sårbarheter som går under namnet PHP2Shell, och bara release branches från 8.2 till 8.5 fick officiella utgåvor, medan säkerhetsteamet undantagsvis bara tog fram minimala källkodsrättningar för release branches 7.4, 8.0 och 8.1, åt den som bygger PHP själv. Samma dag släppte Node.js rättningar för tio sårbarheter, och release line 18 och 20 fick inga alls från själva projektet. Båda fallen har vi beskrivit närmare var för sig: i artikeln om PHP2Shell och i artikeln om Node.js-säkerhetsuppdateringen.

Den andra risken syns mindre, men är på längre sikt större. En gammal runtime låter ingenting uppdateras av det som ligger ovanpå den: WordPress-tillägg (plugin), Composer- och npm-paket och själva ramverket slutar i sina nya utgåvor efter hand att stödja gammal PHP och Node.js, och därför kan webbplatsen inte få deras rättningar heller. WordPress rekommenderar själv PHP 8.3 eller nyare och skriver om äldre release branches att deras officiella stöd har tagit slut och att de kan göra webbplatsen oskyddad. Då är den gamla runtimen inte längre ett enskilt problem, utan ett lager som hindrar att alla de andra problemen löses.

När något händer är priset betydligt högre än för en planerad uppdatering. En hackad webbplats betyder städning, återställning från en säkerhetskopia, byte av lösenord och nycklar och, om kundernas personuppgifter berördes, också en bedömning av om personuppgiftsincidenten ska anmälas till tillsynsmyndigheten, och allt det sker under tidspress, medan webbplatsen ligger nere eller visar besökarna främmande innehåll. Övergången måste ändå göras i det läget, bara att den nu får göras efter intrånget och inte före det, och utan möjlighet att lugnt prova allt i en testmiljö.

Varför en gammal PHP-version inte går att byta i hostingpanelen

I hostingpanelen tar övergången till en nyare PHP-version ett enda klick, och just därför är den lömsk: om koden inte är redo för den slutar webbplatsen fungera i nästa sekund, ofta med en tom sida eller ett felmeddelande. När PHP går till nästa stora utgåva tar det medvetet bort funktioner som i många år har varit föråldrade. PHP 7.0 tog bort den gamla PHP extension mysql, som många äldre webbplatser vilade på, och PHP 8.0 tog i sin lista över inkompatibla ändringar bland annat bort funktionerna each() och create_function(), som fortfarande förekommer i äldre kod.

I Node.js-världen är det klassiska exemplet release line 17, där runtimen gick över till OpenSSL 3.0. I utgåvans meddelande varnade Node.js för att en applikation som själv, eller vars moduler, använder en algoritm eller en nyckellängd som OpenSSL 3.0 i standardläget inte längre tillåter får felet ERR_OSSL_EVP_UNSUPPORTED, och som tillfällig lösning erbjöd startparametern --openssl-legacy-provider. Felet orsakades ofta inte av projektets egen kod utan av något av dess beroenden, så det fick rättas i kod som projektets team inte ens själva hade skrivit.

Därför är övergången utvecklingsarbete, inte en inställning. Koden måste kontrolleras mot den nya runtimen, de föråldrade funktionerna ersättas, beroendena uppdateras till utgåvor som stöder den, och allt provas i en testmiljö innan kunderna ser det. För en liten webbplats på en plattform som underhålls kan det vara några timmars arbete, men för ett system vars ramverk förlorade stödet för flera år sedan innebär övergången ofta också att ramverket byts, och då är det redan ett projekt med egen budget och egen tidsplan, inte en uppgift som går att klara av mellan andra arbeten.

Tre vägar: uppdatera, bygga om eller hålla den skyddad

Vägen bestäms av två saker: hur långt koden har halkat efter en version som har stöd, och hur länge webbplatsen fortfarande ska tjäna. Om webbplatsen ändå ska ersättas med en ny om ett år är en stor övergång i den gamla koden inte värd att göra, men om den är företagets vardagsverktyg och ska användas i minst fem år till skjuter en tillfällig lösning bara upp det oundvikliga och gör det dyrare. I tabellen står de tre vägar som faktiskt finns, och vad var och en av dem löser och inte löser.

Uppdatering är det rätta valet om webbplatsen vilar på en plattform som underhålls, till exempel WordPress eller Laravel, och ett eller två stora steg skiljer den från en release branch med stöd. Då är arbetet förutsägbart: ramverket och tilläggen ska uppdateras, det som kontrollverktygen hittar ska rättas, och PHP ska slås om. En ombyggnad är den ärligaste vägen om själva ramverket saknar stöd, om webbplatsen är skriven på PHP 5.x utan något ramverk alls eller om ingen längre förstår koden, eftersom kostnaden för en uppdatering då snabbt närmar sig kostnaden för en ny webbplats, medan resultatet fortfarande är gammal kod.

Den tredje vägen diskuteras mer sällan. En gammal webbplats kan hållas på en plattform som fortfarande backportar säkerhetsuppdateringar till dess runtime, isolerar den från andra webbplatser och blockerar kända attackmönster redan innan rättningen finns. Det ersätter inte övergången, och Node.js själv kallar ett sådant stöd för en tillfällig lösning, men det är ett ärligt sätt att vinna tid: övergången kan göras i planerad takt, inte veckan efter nästa säkerhetsmeddelande. Det viktigaste ordet här är ”slutdatum”, eftersom en tillfällig lösning utan det blir permanent.

Vad en backport är och varför versionsnumret inte säger något om den

En backport betyder att en säkerhetsuppdatering som tagits fram för en nyare utgåva anpassas av någon och byggs in i en äldre utgåva som användaren redan kör. Red Hat, som underhåller paketen i sina Linux-distributioner på det här sättet, skriver att kunden enbart utifrån versionsnumret inte kan avgöra om systemet är sårbart, eftersom rättningen ändrar paketet men inte versionsnumret. Just därför brukar sårbarhetsskannrar som bara tittar på numret i sådana system felaktigt rapportera problem som redan är åtgärdade.

För PHP och Node.js gör flera leverantörer detta. Linux-distributioner backportar rättningar till sina PHP- och Node.js-paket under hela distributionens stödtid. CloudLinux backportar rättningar till sina alt-php-paket, som hostingservrar med CloudLinux använder, även för release branches där PHP:s stöd tog slut för länge sedan: i fallet PHP2Shell meddelade dess statussida den 21 oktober att den tog fram rättade paket för alla release branches i alt-php från 5.2 till 8.5, och under den följande natten fanns de tillgängliga. De paketen ingår nu i företaget TuxCares utökade stöd, vars villkor anger en rättning inom 14 dagar efter publiceringen som mål för sårbarheter av hög och kritisk allvarlighetsgrad.

För Node.js-release lines utan stöd erbjuder kommersiella partner som Node.js själv nämner på sin sida om end of life samma sorts tjänst: HeroDevs, NodeSource och TuxCare. Node.js tillägger genast att ett sådant stöd ska ses som en tillfällig lösning och att målet alltid ska vara en övergång till en version som har stöd. Under Node.js-utgåvan i oktober 2026 backportade CloudLinux rättningar även till sina paket för release line 16, 18 och 20, som hostingkunder väljer i cPanel-avsnittet Setup Node.js App.

Det går inte att kontrollera utifrån versionsnumret. Kommandot php -v eller node -v visar efter en backport exakt detsamma som före den, och CloudLinux skriver det öppet i sitt Node.js-meddelande: för release lines utan stöd ändras inte numret efter uppdateringen. Det som ändras är paketets release number, som bara serveradministratören ser, och därför kan bara hostingleverantören ge svaret i ett webbhotell.

Gränsen måste sägas lika tydligt. En backport skyddar själva PHP eller Node.js, men den skyddar inte ett WordPress-tillägg vars författare har slutat uppdatera det, egen kod med en SQL-injektion eller ett npm-paket vars nyare utgåvor inte längre stöder gammal Node.js. Dessutom backportar leverantörerna rättningar för varje release line för sig, så för varje enskild linje måste man kontrollera om den alls står på listan, och TuxCare förbehåller sig i sina villkor rätten att i stället för en rättning erbjuda en riskminskande åtgärd.

När det inte är runtimen som är gammal, utan själva plattformen

Ibland sitter problemet inte i runtimen utan i själva plattformen som webbplatsen är byggd på, och då hjälper backportade PHP-säkerhetsuppdateringar bara delvis. Det tydligaste exemplet är Drupal 7: dess säkerhetsstöd tog slut den 5 januari 2025, och sedan dess släpper själva Drupal-projektet varken säkerhetsuppdateringar eller kompatibilitetsuppdateringar för den. En webbplats på Drupal 7 kan köra på en PHP som är helt rättad, men dess kärna, moduler och tema blir ändå kvar med alla sårbarheter som fortfarande kommer att hittas i dem, eftersom ingen längre rättar dem utan betalning.

Också här finns en betald tillfällig lösning: Drupal Association har byggt upp ett program för utökat säkerhetsstöd, där granskade leverantörer, till exempel HeroDevs och Tag1 Consulting, erbjuder betalt stöd. Det är samma princip som för backportar av PHP, bara ett lager högre upp, och den har samma gränser: den skjuter upp övergången men löser den inte, och varje år på en gammal plattform gör övergången dyrare, eftersom avståndet till den aktuella utgåvan växer och antalet utvecklare som fortfarande kan den gamla plattformen minskar.

Därför är det värt att inför varje beslut kontrollera alla lager, inte bara PHP: runtimen, plattformen eller ramverket, tilläggen eller modulerna och den egenskrivna koden. Om det bara är PHP som är föråldrat, men WordPress, Laravel eller en annan plattform underhålls, är övergången vanligtvis ett förutsägbart arbete. Om det är själva plattformen som är gammal handlar frågan inte längre om PHP:s release branch, utan om huruvida webbplatsen ska flyttas till plattformens nya utgåva eller byggas från grunden, och just här är uppgiften för en backport att ge tid att fatta det beslutet utan brådska.

Hur vi håller gammal PHP och Node.js på vår server

Vår managed hosting är en plats på vår egen server, som kör CloudLinux, och för varje webbplats väljs PHP-versionen för sig i hostingpanelen. Just nu finns där PHP från 5.4 till 8.4, och för Node.js-applikationer både de release lines som har stöd, 22 och 24, och de gamla, 16, 18 och 20. Det betyder att en gammal webbplats kan migreras till oss med samma PHP eller Node.js som den körs med nu, och först stabiliseras, i stället för att koden också ändras på flyttdagen, vilket är det säkraste sättet att inte ha sönder något under migreringen.

Hur det fungerar i praktiken kunde vi själva mäta i oktober 2026. PHP2Shell-rättningarna kom på eftermiddagen den 21 oktober, och på vår server kör nu alla gamla release branches för PHP från 5.4 till 8.1 med paket som CloudLinux byggde om natten samma dygn, mindre än ett dygn efter PHP-utgåvan, och där rättningen är backportad. Release branches från 8.2 till 8.4 gick över till de officiella rättade utgåvorna 8.2.35, 8.3.36 och 8.4.27, medan Node.js release line 16, 18 och 20 den 22 oktober fick CloudLinux-paket med backportade rättningar, trots att själva Node.js-projektet inte släppte några rättningar för dem. För de gamla release branches ändrades inte numret, så vi kontrollerade inte numret utan när de körbara filerna hade byggts om.

Det är inte allt plattformen gör. CloudLinux lägger varje hostingkonto i en egen isolerad miljö som heter CageFS, och där ser användarna inte andra användare på servern och inte ens deras användarnamn, vilket försvårar att ett intrång sprider sig från ett konto till andra. Imunify360:s webbapplikationsbrandvägg (WAF) började i fallet PHP2Shell blockera kända attackmönster den 21 oktober, flera timmar innan den rättade PHP-versionen publicerades. Inget av de här lagren gör en gammal webbplats osårbar, men tillsammans kortar de tiden då en känd sårbarhet går att utnyttja, och de begränsar hur långt följderna av ett intrång kan nå.

Därför rekommenderar vi att migreringen av en gammal webbplats till oss ses som en tillfällig lösning med ett slutdatum, inte som ett mål. Vi migrerar webbplatsen med samma runtime, kontrollerar att allt fungerar som tidigare, och kommer sedan överens med dig om till vilket datum och i vilken ordning den går över till en version som har stöd, så att den tillfälliga lösningen inte blir permanent. Vår managed hosting börjar på 45 € i månaden, och underhållna runtimes, account isolation och en webbapplikationsbrandvägg är en del av det som den summan betalar för. Om du har en webbplats med en gammal PHP- eller Node.js-version, skicka oss adressen, så säger vi vilken av de tre vägarna som passar den och vad du ska börja med.

Hur du tar reda på vilken PHP- eller Node.js-version din webbplats har

Den snabbaste vägen är hostingpanelen. I cPanel-hosting med CloudLinux visar avsnittet Select PHP Version den version som är vald för hela kontot, medan MultiPHP Manager visar versionen för varje domän för sig, och om en domän har en egen version angiven där är det den som gäller. För Node.js-applikationer visar avsnittet Setup Node.js App samma sak, med en egen rad för varje applikation. Det är värt att titta på varje webbplats, inte bara den huvudsakliga, eftersom ett konto ofta har flera webbplatser på olika release branches för PHP, och en bortglömd testkopia eller en gammal kampanjsida fortfarande ofta går att nå från internet.

På en WordPress-webbplats syns det också i administrationspanelen: under Verktyg → Hälsokontroll för webbplats, på fliken Info, i avsnittet Server står den PHP-version som webbplatsen körs på. Om du inte har någon panel kan du skapa en fil med funktionen phpinfo() och öppna den i webbläsaren, men filen måste sedan absolut tas bort, eftersom den visar serverkonfigurationen för varje besökare. Kommandot php -v hjälper mindre här än det verkar, eftersom det visar kommandoradens PHP, medan webbförfrågningar ofta betjänas av en annan release branch, den som är vald i hostingpanelen. I ett Node.js-projekt anges den önskade release line ofta av fältet engines i package.json eller av filen .nvmrc, men det är bara en önskan, och vilken Node.js som faktiskt kör applikationen syns där processen startas.

Om du inte har någon åtkomst alls får frågan ställas till hostingleverantören eller till utvecklaren som underhåller webbplatsen. En formulering som sparar brevväxlingen: ”Vilken PHP- eller Node.js-version kör vår webbplats? Om stödet har tagit slut, får den backportade säkerhetsuppdateringar, varifrån kommer de och när uppdaterades paketet senast? Till vilket datum rekommenderar ni övergången?” Svaret på den sista frågan säger också en hel del om leverantören själv, för om det inte finns något datum finns det vanligtvis inte heller någon plan.

Övergång till en version med stöd: så gör du den utan överraskningar

Övergången börjar med en inventering, inte med att slå om. Det som ska antecknas är vilken release branch av PHP och vilka PHP extensions webbplatsen behöver, vilka schemalagda uppgifter som kör den i bakgrunden, vilka externa system den talar med och vilka delar som är kritiska för verksamheten, till exempel beställningsformuläret, betalningarna eller fakturautskicket. Målversionen är värd att välja med marginal: PHP 8.4 får säkerhetsuppdateringar till den 31 december 2028, PHP 8.3 till slutet av 2027, medan en övergång till PHP 8.2, vars stöd tar slut redan i slutet av 2026, skulle betyda ännu en övergång alldeles snart. För Node.js är målet i de flesta fall release line 24.

Det andra steget är en kontroll av koden, och för PHP-kod kan den till stor del automatiseras. PHPCompatibility är en regeluppsättning för PHP_CodeSniffer som kontrollerar om koden är kompatibel med en viss PHP-version, medan Rector kan utföra en del av de ändringar som behövs automatiskt. Inget av dem ersätter en mänsklig kontroll, men de visar snabbt om arbetsmängden mäts i timmar eller veckor, och just det behövs för att välja mellan uppdatering och ombyggnad. På en WordPress-webbplats ska tilläggen och temat uppdateras först, och PHP slås om först därefter.

Det tredje steget är en testmiljö, alltså en kopia av webbplatsen med den nya PHP- eller Node.js-versionen, där alla kritiska moment provas: formulär, betalningar, e-postutskick, import och export. Felloggen är i det skedet viktigare än den visuella kontrollen, eftersom varningar om föråldrade funktioner dyker upp där långt innan något stannar. Det fjärde steget är att slå om vid låg belastning, med en möjlighet att gå tillbaka: i en hosting där versionen kan väljas är vägen tillbaka samma enda klick som användes för att slå om, så risken är liten, så länge säkerhetskopian är färsk och någon följer felloggen den första veckan.

För en Node.js-applikation är logiken densamma, bara verktygen är andra. Övergången mellan stora release lines är värd att göra en i taget, och applikationens tester körs efter varje, med särskild uppmärksamhet på paket med kompilerad kod, eftersom de byggs för en bestämd Node.js release line och måste byggas om efter övergången. Först uppdateras de beroenden som ännu inte stöder den nya linjen, och först därefter byts själva runtimen, annars blandas felen från båda hållen och det blir svårt att se vilket av dem som orsakade vad.