Hva gjør du med et nettsted som har en gammel PHP- eller Node.js-versjon?

Det korte svaret er dette: et nettsted med en gammel PHP- eller Node.js-versjon har tre veier — å tilpasse koden til en utgivelse med støtte, å bygge nettstedet på nytt, eller å holde det en tid på en plattform som fortsatt backporter sikkerhetsoppdateringer til den gamle runtime, altså miljøet koden kjører i, og i mellomtiden planlegge overgangen i ro. En fjerde vei, der du lar alt stå som det står fordi nettstedet jo virker, finnes egentlig ikke, for PHP 8.1 og eldre release branches får ikke lenger sikkerhetsoppdateringer fra PHP-prosjektet, det gjør heller ikke release line 18 og 20 hos Node.js, og oktober 2026 viste i begge tilfellene hva det betyr i praksis.

Et nettsted med en gammel PHP-versjon er vanligvis verken et unntak eller en særlig forsømmelse. Det ble laget for fem eller åtte år siden, utvikleren som bygde det, har for lengst en jobb et annet sted, og nettstedet har i alle disse årene vært i drift uten store problemer: det har tatt imot henvendelser, vist priser og sendt fakturaer. Etter tallene fra W3Techs kjørte i oktober 2026 26,8 % av nettstedene som bruker PHP, på PHP 7, og ytterligere 7,7 % på PHP 5, slik at mer enn en tredjedel av dem bruker PHP som nådde end of life, altså der støtten er slutt, for flere år siden. Spørsmålet dukker vanligvis opp først når hostingleverandøren sender en advarsel, eller når en sårbarhet kommer i nyhetene.

Når en PHP- eller Node.js-versjon blir gammel

«Gammel» er her ikke et spørsmål om smak, for både PHP og Node.js publiserer en plan som sier til hvilken dato hver release branch eller release line får sikkerhetsoppdateringer. PHP gir hver release branch to år med Active support og deretter to år med kun sikkerhetsfikser, og etter det har release branch nådd end of life og får ingen støtte i det hele tatt. Release lines med langtidsstøtte hos Node.js har til slutt fasen Maintenance LTS, og når den er over, får linjen ingen flere utgivelser, heller ikke når en ny sårbarhet treffer nettopp den.

Tabellen viser de release branches og release lines du oftest møter i dag, og statusen deres i oktober 2026. Datoene er hentet fra PHPs liste over end of life og Node.js sin utgivelsesplan, og begge kildene må sjekkes også videre, for hvert år kommer det til nye rader i dem.

To rader i denne tabellen er verdt å lese en gang til. PHP 8.2 når end of life 31. desember 2026, så et nettsted som høsten 2026 ser moderne ut, er i januar 2027 i samme situasjon som et nettsted på PHP 7.4, og overgangen er verdt å planlegge allerede nå, mens den kan gjøres uten hastverk. Release line 20 hos Node.js var høsten 2024 fortsatt Active LTS, den linjen mange nye prosjekter ble startet på, men 30. april 2026 nådde den end of life. Foreldelsen skjer ikke gradvis: på én bestemt dag går runtime fra «får sikkerhetsoppdateringer» til «får ingenting», og på nettstedet er det da ingenting som endrer seg, som du kunne ha lagt merke til.

Hvorfor et nettsted som virker, likevel er utsatt

En versjon uten støtte blir ikke farlig den dagen støtten tar slutt, men den dagen det publiseres en sårbarhet som også rammer den. Sikkerhetsoppdateringen til release branches med støtte kommer sammen med en beskrivelse, og så snart den er offentlig, kan angripere sammenligne rettet kode med urettet kode og se hvor hullet er. Node.js sier det rett ut på siden om end of life: hvis en sårbarhet også rammer en release line uten støtte, kommer det ingen ny utgivelse til den, og de som blir stående på en slik linje, er med en gang utsatt for angrep som utnytter den publiserte sårbarheten.

I oktober 2026 skjedde nettopp dette med begge plattformene nesten samtidig. 21. oktober ga PHP ut hastende sikkerhetsoppdateringer for to kritiske sårbarheter kjent under navnet PHP2Shell, og offisielle utgivelser gikk bare til release branches fra 8.2 til 8.5, mens sikkerhetsteamet unntaksvis laget minimale rettelser i kildekoden for release branches 7.4, 8.0 og 8.1, til dem som bygger PHP selv. Samme dag ga Node.js ut sikkerhetsoppdateringer for ti sårbarheter, og release line 18 og 20 fikk ingen av dem fra prosjektet selv. Begge tilfellene har vi beskrevet nærmere hver for seg: artikkelen om PHP2Shell og artikkelen om Node.js-sikkerhetsoppdateringen.

Den andre risikoen er mindre synlig, men større på lang sikt. En gammel runtime lar deg ikke oppdatere noe av det som ligger over den: WordPress-utvidelser, Composer- og npm-pakker og selve rammeverket slutter i nye utgivelser etter hvert å støtte gammel PHP og Node.js, så nettstedet kan heller ikke få sikkerhetsoppdateringene deres. WordPress anbefaler selv PHP 8.3 eller nyere, og om eldre release branches skriver de at den offisielle støtten har tatt slutt og at de kan gjøre nettstedet ubeskyttet. Da er den gamle runtime ikke lenger ett enkelt problem, men et lag som hindrer deg i å løse alle de andre.

Når noe først skjer, er prisen betraktelig høyere enn en planlagt oppdatering. Et hacket nettsted betyr opprydding, gjenoppretting fra sikkerhetskopi, bytte av passord og nøkler, og, hvis kundenes personopplysninger ble berørt, også en vurdering av om et brudd på personopplysningssikkerheten skal meldes til Datatilsynet, og alt dette skjer i hastverk mens nettstedet er nede eller viser de besøkende andres innhold. Overgangen må uansett gjøres i den situasjonen, bare nå etter innbruddet og ikke før, og uten mulighet til å sjekke alt i ro i et testmiljø.

Hvorfor du ikke bare kan bytte en gammel PHP-versjon i kontrollpanelet

I kontrollpanelet tar byttet til en nyere PHP-versjon ett klikk, og nettopp derfor er det lumskt: hvis koden ikke er klar, slutter nettstedet å virke i neste sekund, ofte med en tom side eller en feilmelding. Når PHP går til neste store utgivelse, fjerner det med vilje funksjoner som i mange år har vært foreldet. PHP 7.0 fjernet den gamle PHP extension mysql, som mange eldre nettsteder bygde på, mens PHP 8.0 i listen over inkompatible endringer blant annet fjernet funksjonene each() og create_function(), som fortsatt finnes i eldre kode.

I Node.js-verdenen er det klassiske eksempelet release line 17, der runtime gikk over til OpenSSL 3.0. I utgivelsesmeldingen advarte Node.js om at en applikasjon som selv, eller gjennom modulene sine, bruker en algoritme eller en nøkkellengde som OpenSSL 3.0 ikke lenger tillater som standard, får feilen ERR_OSSL_EVP_UNSUPPORTED, og som midlertidig løsning tilbød de oppstartsparameteren --openssl-legacy-provider. Feilen kom ofte ikke fra prosjektets egen kode, men fra en av avhengighetene, så den måtte rettes i kode som prosjektets eget team ikke hadde skrevet.

Derfor er overgangen utviklingsarbeid, ikke en innstilling. Koden må sjekkes mot den nye runtime, foreldede funksjoner må byttes ut, avhengigheter må oppdateres til utgivelser som støtter den, og alt må prøves i et testmiljø før kundene ser det. For et lite nettsted på en plattform som vedlikeholdes, kan det være noen timers arbeid, men for et system hvis rammeverk nådde end of life for flere år siden, betyr overgangen ofte også at rammeverket må byttes, og da er det et prosjekt med eget budsjett og egen tidsplan, ikke en oppgave du får unnagjort mellom andre gjøremål.

Tre veier: oppdatere, bygge på nytt eller holde det beskyttet

Veien avgjøres av to ting: hvor langt koden har sakket etter en versjon med støtte, og hvor lenge nettstedet fortsatt skal være i bruk. Hvis nettstedet uansett skal byttes ut med et nytt om et år, er det ikke verdt å gjøre en stor overgang i den gamle koden, men hvis det er verktøyet bedriften bruker i det daglige arbeidet og skal bruke i minst fem år til, utsetter en midlertidig løsning bare det uunngåelige og gjør det dyrere. Tabellen viser de tre veiene som faktisk finnes, og hva hver av dem løser og ikke løser.

Oppdatering er det riktige valget hvis nettstedet står på en plattform som vedlikeholdes, for eksempel WordPress eller Laravel, og ett eller to store steg skiller det fra en release branch med støtte. Da er arbeidet forutsigbart: du oppdaterer rammeverket og utvidelsene, retter det verktøyene for sjekk finner, og bytter PHP. Å bygge på nytt er den ærligste veien hvis selve rammeverket er uten støtte, hvis nettstedet er skrevet på PHP 5.x uten noe rammeverk i det hele tatt, eller hvis ingen lenger forstår koden, for da nærmer kostnaden ved oppdatering seg raskt kostnaden for et nytt nettsted, mens resultatet fortsatt er gammel kode.

Den tredje veien blir sjeldnere diskutert. Et gammelt nettsted kan holdes på en plattform som fortsatt backporter sikkerhetsoppdateringer til runtime, isolerer det fra andre nettsteder og blokkerer kjente angrepsmønstre allerede før sikkerhetsoppdateringen. Det er ikke en erstatning for overgangen, og Node.js selv kaller slik støtte en midlertidig løsning, men det er en ærlig måte å kjøpe tid på: overgangen kan skje i et planlagt tempo, ikke i uken etter neste sikkerhetsmelding. Det viktigste ordet her er «frist», for uten den blir den midlertidige løsningen permanent.

Hva en backport er, og hvorfor versjonsnummeret ikke sier noe om den

En backport betyr at en sikkerhetsoppdatering som er laget for en nyere utgivelse, blir tilpasset og bygd inn i en eldre utgivelse som brukeren allerede kjører. Red Hat, som vedlikeholder pakkene i Linux-distribusjonene sine på denne måten, skriver at kunden ikke ut fra versjonsnummeret alene kan avgjøre om systemet er sårbart, fordi sikkerhetsoppdateringen endrer pakken, men ikke versjonsnummeret. Nettopp derfor pleier sårbarhetsskannere som bare ser på nummeret, å varsle feilaktig om problemer som allerede er rettet, på slike systemer.

For PHP og Node.js gjør flere leverandører dette. Linux-distribusjoner backporter sikkerhetsoppdateringer til sine PHP- og Node.js-pakker gjennom hele tiden distribusjonen har støtte. CloudLinux backporter også til sine alt-php-pakker, som hostingservere med CloudLinux bruker, for release branches der PHP-støtten tok slutt for lenge siden: i PHP2Shell-tilfellet varslet statussiden deres 21. oktober at de forberedte rettede pakker for alle release branches av alt-php fra 5.2 til 8.5, og i løpet av natten etter var de tilgjengelige. Disse pakkene er nå en del av den utvidede støtten hos TuxCare, og i vilkårene er målet for sårbarheter med høy og kritisk alvorlighetsgrad en sikkerhetsoppdatering innen 14 dager etter offentliggjøring.

For release lines hos Node.js uten støtte tilbyr kommersielle partnere den samme tjenesten, og Node.js selv nevner dem på siden om end of life: HeroDevs, NodeSource og TuxCare. Node.js legger likevel til med en gang at slik støtte må ses som en midlertidig løsning, og at målet alltid skal være overgang til en versjon med støtte. Under Node.js-utgivelsen i oktober 2026 backportet CloudLinux sikkerhetsoppdateringer også til sine pakker for release line 16, 18 og 20, som hostingkunder velger i cPanel-seksjonen Setup Node.js App.

Det lar seg ikke sjekke ut fra versjonsnummeret. Kommandoen php -v eller node -v viser etter en backport nøyaktig det samme som før, og CloudLinux skriver det åpent i Node.js-meldingen sin: for linjer uten støtte endrer nummeret seg ikke etter oppdateringen. Det som endrer seg, er pakkens release number, som bare serveradministratoren ser, så på et webhotell kan bare hostingleverandøren gi svaret.

Grensen må sies like tydelig. En backport beskytter selve PHP eller Node.js, men den beskytter ikke en WordPress-utvidelse som forfatteren sluttet å oppdatere, egen kode med en SQL-injeksjon, eller en npm-pakke hvis nyeste utgivelser ikke lenger støtter gammel Node.js. Leverandørene backporter dessuten til hver linje for seg, så for hver konkrete linje må du sjekke om den i det hele tatt står på listen, og TuxCare forbeholder seg i vilkårene sine retten til å tilby et risikoreduserende tiltak i stedet for en sikkerhetsoppdatering.

Når det er plattformen som er gammel, ikke runtime

Noen ganger ligger problemet ikke i runtime, men i selve plattformen nettstedet er bygd på, og da hjelper en backport til PHP bare delvis. Det beste eksempelet er Drupal 7: sikkerhetsstøtten tok slutt 5. januar 2025, og siden da gir Drupal-prosjektet selv ikke lenger ut verken sikkerhetsoppdateringer eller kompatibilitetsoppdateringer til det. Et nettsted på Drupal 7 kan kjøre på PHP som er fullstendig rettet, men kjernen, modulene og temaet blir likevel stående med alle sårbarhetene som fortsatt blir funnet i dem, for gratis retter ingen dem lenger.

Også her finnes det en betalt midlertidig løsning: Drupal Association har opprettet et program for utvidet sikkerhetsstøtte, der sjekkede leverandører tilbyr betalt støtte, for eksempel HeroDevs og Tag1 Consulting. Det er det samme prinsippet som en backport til PHP, bare ett lag høyere, og det har de samme grensene: det utsetter overgangen, men løser den ikke, og hvert år på en gammel plattform gjør overgangen dyrere, fordi avstanden til den gjeldende utgivelsen vokser og antallet utviklere som fortsatt kan den gamle plattformen, krymper.

Derfor lønner det seg å sjekke alle lagene før noen beslutning, ikke bare PHP: runtime, plattformen eller rammeverket, utvidelsene eller modulene, og koden du har skrevet selv. Hvis det bare er PHP som er foreldet, mens WordPress, Laravel eller en annen plattform vedlikeholdes, er overgangen vanligvis arbeid du kan forutse. Hvis det er selve plattformen som er gammel, handler spørsmålet ikke lenger om en PHP release branch, men om du skal flytte nettstedet til plattformens nye utgivelse eller bygge det på nytt, og nettopp her er oppgaven til en backport å gi tid til å ta den beslutningen uten hastverk.

Slik holder vi gammel PHP og Node.js på serveren vår

Den administrerte serverdriften vår er plass på vår egen server, som kjører CloudLinux, og PHP-versjonen for hvert nettsted velges for seg i kontrollpanelet. Akkurat nå ligger PHP fra 5.4 til 8.4 der, og for Node.js-applikasjoner både release line 22 og 24, som har støtte, og de gamle release lines 16, 18 og 20. Det betyr at et gammelt nettsted kan flyttes til oss med den samme PHP eller Node.js som det kjører på nå, og stabiliseres først, i stedet for at koden også endres på flyttedagen, som er den sikreste måten å ikke ødelegge noe på under flyttingen.

Hvordan det virker i praksis, kunne vi måle selv i oktober 2026. Sikkerhetsoppdateringene for PHP2Shell kom ettermiddagen 21. oktober, og på serveren vår kjører alle gamle PHP release branches fra 5.4 til 8.1 nå med pakker som CloudLinux bygde på nytt natten samme døgn, mindre enn ett døgn etter PHP-utgivelsen, og der sikkerhetsoppdateringen er lagt inn som backport. Release branches fra 8.2 til 8.4 gikk over til de offisielle rettede utgivelsene 8.2.35, 8.3.36 og 8.4.27, mens release line 16, 18 og 20 hos Node.js 22. oktober fikk CloudLinux-pakker med backport, selv om Node.js-prosjektet selv ikke ga ut sikkerhetsoppdateringer til dem. For de gamle release branches endret nummeret seg ikke, så vi sjekket ikke ut fra nummeret, men ut fra når de kjørbare filene ble bygd på nytt.

Det er ikke alt plattformen gjør. CloudLinux legger hver hostingkonto i et eget isolert miljø som kalles CageFS, og der ser brukerne ikke andre brukere på serveren, ikke engang brukernavnene deres, noe som gjør det vanskeligere for et innbrudd å spre seg fra én konto til andre. Brannmuren for webapplikasjoner i Imunify360 begynte i PHP2Shell-tilfellet å blokkere kjente angrepsmønstre 21. oktober, flere timer før den rettede PHP-en ble publisert. Ingen av disse lagene gjør et gammelt nettsted usårbart, men sammen korter de inn tiden en kjent sårbarhet kan utnyttes i, og de begrenser hvor langt følgene av et innbrudd kan nå.

Derfor anbefaler vi at du ser på flytting av et gammelt nettsted til oss som en midlertidig løsning med en frist, ikke som et endepunkt. Vi flytter nettstedet med den samme runtime, sjekker at alt virker som før, og blir deretter enige med deg om hvilken dato det skal over på en versjon med støtte, og i hvilken rekkefølge, slik at den midlertidige løsningen ikke blir permanent. Administrert serverdrift hos oss starter på 45 € i måneden, og vedlikeholdte runtimes, account isolation og brannmur for webapplikasjoner er en del av det du betaler for i det beløpet. Hvis du har et nettsted med en gammel PHP- eller Node.js-versjon, send oss adressen, så sier vi hvilken av de tre veiene som passer, og hva du bør begynne med.

Slik finner du ut hvilken PHP- eller Node.js-versjon nettstedet ditt kjører

Den raskeste veien er kontrollpanelet. På cPanel-hosting med CloudLinux viser seksjonen Select PHP Version versjonen som er valgt for hele kontoen, mens MultiPHP Manager viser versjonen for hvert domene for seg, og hvis domenet har sin egen versjon der, er det den som gjelder. For Node.js-applikasjoner viser seksjonen Setup Node.js App det samme, med en egen rad for hver applikasjon. Det lønner seg å se på hvert nettsted, ikke bare det viktigste, for én konto har ofte flere nettsteder med ulike PHP release branches, og en glemt testkopi eller en gammel kampanjeside er ofte fortsatt tilgjengelig fra internett.

På et WordPress-nettsted kan du også se det i administrasjonsgrensesnittet: under Verktøy → Nettstedshelse, på fanen Info, i blokken Server, står PHP-versjonen nettstedet kjører på. Hvis du ikke har tilgang til grensesnittet, kan du lage en fil med funksjonen phpinfo() og åpne den i nettleseren, men filen må absolutt slettes etterpå, for den viser serverkonfigurasjonen til enhver besøkende. Kommandoen php -v hjelper mindre her enn det kan se ut til, for den viser PHP på kommandolinjen, mens webforespørsler ofte betjenes av en annen release branch, valgt i kontrollpanelet. I et Node.js-prosjekt står den ønskede linjen ofte i package.json-feltet engines eller i filen .nvmrc, men det er bare et ønske, og hvilken Node.js som faktisk kjører applikasjonen, må du se der prosessen blir startet.

Hvis du ikke har tilgang i det hele tatt, må spørsmålet stilles til hostingleverandøren eller til utvikleren som vedlikeholder nettstedet. En formulering som sparer en runde med e-post: «Hvilken PHP- eller Node.js-versjon betjener nettstedet vårt? Hvis den har nådd end of life, får den sikkerhetsoppdateringer som backport, hvor kommer de fra, og når ble pakken sist oppdatert? Til hvilken dato anbefaler du overgangen?» Svaret på det siste spørsmålet sier også mye om leverandøren selv, for hvis det ikke finnes en dato, finnes det vanligvis heller ingen plan.

Overgang til en versjon med støtte: slik gjør du det uten overraskelser

Overgangen begynner med en kartlegging, ikke med et bytte. Skriv ned hvilken PHP release branch og hvilke PHP extensions nettstedet trenger, hvilke planlagte oppgaver som kjører det i bakgrunnen, hvilke eksterne systemer det snakker med, og hvilke deler som er kritiske for virksomheten, for eksempel bestillingsskjemaet, betalinger eller utsending av fakturaer. Målversjonen bør du velge med margin: PHP 8.4 får sikkerhetsoppdateringer til 31. desember 2028, PHP 8.3 til utgangen av 2027, mens en overgang til PHP 8.2, som når end of life allerede ved utgangen av 2026, ville bety enda en overgang ganske snart. For Node.js er målet i de fleste tilfellene release line 24.

Det andre steget er å sjekke koden, og for PHP-kode kan det i stor grad automatiseres. PHPCompatibility er et regelsett for PHP_CodeSniffer som sjekker om koden er kompatibel med en bestemt PHP-versjon, mens Rector kan gjøre en del av de nødvendige endringene automatisk. Ingen av dem erstatter en gjennomgang gjort av et menneske, men de viser raskt om arbeidsmengden måles i timer eller uker, og det er nettopp det som trengs for å velge mellom oppdatering og å bygge på nytt. På et WordPress-nettsted oppdaterer du først utvidelsene og temaet, og bytter PHP først etterpå.

Det tredje steget er et testmiljø, altså en kopi av nettstedet med den nye PHP- eller Node.js-versjonen, der du prøver alle kritiske handlinger: skjemaer, betalinger, sending av e-post, import og eksport. Feilloggen er viktigere i denne fasen enn en visuell sjekk, for advarsler om foreldede funksjoner dukker opp der lenge før noe stopper. Det fjerde steget er å bytte i en periode med liten belastning, med mulighet til å gå tilbake: på hosting der du kan velge versjon, er veien tilbake det samme ene klikket som byttet ble gjort med, så risikoen er liten, så lenge sikkerhetskopien er fersk og noen følger feilloggen den første uken.

For en Node.js-applikasjon er logikken den samme, bare verktøyene er andre. Overgangen mellom store linjer bør du ta én om gangen, og kjøre applikasjonens tester etter hver, og pakker med kompilert kode trenger særlig oppmerksomhet, for de bygges for en bestemt Node.js release line og må bygges på nytt etter overgangen. Først oppdaterer du avhengighetene som ennå ikke støtter den nye linjen, og først deretter bytter du selve runtime, ellers blander feil fra begge sider seg, og det blir vanskelig å se hvilken av dem som forårsaket hva.