DIN RAPPORT
Vi hjelper deg med oppgradering og flytting, og tar vare på nettsiden din videre. Send oss nettadressen, så finner vi en løsning sammen.
Headerne kan være skjult, endret eller komme fra en mellomtjener. Sammenligningen gjelder PHP2Shell-rettelsene fra 21. oktober 2026, kontrollert 23. oktober.
PHP-SÅRBARHETEN ENKELT FORKLART
To alvorlige sikkerhetshull i PHP har ført til midlertidig stenging av nettsider og hastetiltak hos leverandører. Her er bakgrunnen, konsekvensene for virksomheter og hva som må oppdateres.
Sist oppdatert .
Les hos NRK: Nettsider nede etter sikkerhetsalarm ↗Det er funnet to alvorlige sikkerhetshull i PHP, programvaren mange nettsider er avhengige av. En angriper kan i verste fall få kontroll over nettsiden uten å logge inn. Feilene kalles ofte PHP2Shell.
Etter sikkerhetsoppdateringen 21. oktober er bildet ulikt: Noen leverandører har oppdatert og åpnet tjenestene igjen. Andre nettsider kan fortsatt trenge arbeid før de kan åpnes. Det er også rapportert om midlertidige begrensninger på filopplasting.
For bedriften din kan en stengt side bety at kunder ikke får sendt forespørsler, bestilt eller brukt tjenester. Stenging som et sikkerhetstiltak betyr ikke i seg selv at nettsiden er hacket. Be leverandøren bekrefte hva som er oppdatert, og hva som gjenstår.
Det kan gjelde både WordPress og andre publiseringssystemer. Det avgjørende er hvilken PHP-programvare som kjører på serveren, og om den er oppdatert. Du trenger ikke vite versjonen selv – vi kan undersøke det.
Manglende sikkerhetsrutiner og uklart ansvar kan gjøre at oppdateringer blir utsatt. Men det kan også være nettsiden som holder igjen: Et gammelt publiseringssystem, et tema, en utvidelse eller egenutviklet kode kan slutte å fungere med nyere PHP. Da må mer enn serveren oppdateres.
WordPress i seg selv anbefaler PHP 8.3 eller nyere. Likevel kan eldre installasjoner og tillegg trenge arbeid før overgangen. For egenutviklede systemer kan deler av koden måtte bygges om. Det koster tid og penger, og en nettside som fortsatt fungerer, kan derfor bli stående uten en plan for oppgradering.
En avtale om plass på en server betyr ikke nødvendigvis at noen oppgraderer publiseringssystemet og koden din. Spør hvem som følger med på sikkerhetsvarsler, hvem som tester nye PHP-versjoner, og om slikt arbeid faktisk er inkludert i avtalen. Når ansvaret faller mellom kunden og leverandøren, kan nødvendig vedlikehold bli utsatt.
Basert på W3Techs’ versjonstall 24. oktober 2026 beregner vi at omtrent 48 % av PHP-nettsidene i målingen kjører PHP eldre enn 8.2. Disse grenene får ikke lenger ordinære sikkerhetsoppdateringer fra PHP-prosjektet. Tallene viser et stort oppgraderingsbehov, men forteller ikke hvor mange nettsider som er inkompatible med nyere PHP.
PHP 8.2 mister også sikkerhetsstøtten 31. desember 2026. Bruker nettsiden din denne versjonen, bør neste oppgradering planlegges nå.
W3Techs oppgir at PHP brukes av 69,3 % av nettsteder der de kjenner programmeringsspråket på serveren. Av målte PHP-nettsteder bruker 34,6 % PHP eldre enn 8. Blant dem som bruker PHP 8, bruker 20,9 % versjon 8.0 eller 8.1. Vår beregning er 34,6 % + (65,4 % × 20,9 %) ≈ 48,3 % av PHP-nettstedene, eller omtrent 33,5 % av nettsteder med kjent serverspråk. Dette er ikke en måling av alle verdens nettsider, kompatibilitet eller installerte leverandørrettelser.
Kilder: W3Techs: PHP-bruk · Fordeling av PHP 8-versjoner · PHPs støttedatoer · WordPress’ anbefalinger.
Imperva rapporterte 22. oktober om over 482 000 forespørsler knyttet til PHP2Shell det første døgnet, rettet mot nesten 22 000 nettsteder i deres målinger. Dette var registrert trafikk og angrepsforsøk, ikke bekreftede innbrudd. Aktiviteten var i stor grad automatisert. Små bedrifter kan dermed også bli funnet av verktøy som leter bredt etter sårbare nettsider.
Kilde: Impervas målinger fra det første døgnet.
Hvis vi ikke kan oppdatere med en gang, vurderer vi tiltak som reduserer risikoen. De gir ingen garanti mot angrep. I noen tilfeller må nettsiden skjermes eller stenges midlertidig til sikkerhetsrettelsen er på plass.
Sårbarhetene er CVE-2026-109618 og CVE-2026-109619. PHP publiserte rettelser 21. oktober 2026 i versjonene 8.2.35, 8.3.36, 8.4.27 og 8.5.12. Enkelte leverandører har også rettelser for eldre versjoner. PHP har publisert begrensede kildekodepatcher for 7.4, 8.0 og 8.1; dette gir ikke ordinær støtte til disse versjonene. Vi kontrollerer at oppdateringen gjelder den aktuelle installasjonen.
Tekniske kilder: PHP-prosjektet · CERT-EU
PRAKTISK GUIDE
Slik kan virksomheten og leverandøren håndtere PHP-sårbarheten, fra første avklaring til oppdatert nettside.
Be leverandøren bekrefte hvilken PHP-versjon nettsiden bruker, og om rettelsene for begge sårbarhetene er installert. Start med PHP-sjekken vår ↑. Leverandøren må bekrefte den faktiske statusen.
Installer en PHP-versjon med rettelsene, eller en dokumentert sikkerhetsoppdatering fra leverandøren. Hvis nettsiden ikke støtter nyere PHP, må publiseringssystem, tillegg eller egen kode oppgraderes. Ta sikkerhetskopi og test viktige funksjoner før overgangen.
Dette er aktuelt når motoren bak nettsiden – publiseringssystemet og koden – ikke støtter PHP-versjonene med sikkerhetsrettelsen, og derfor må oppgraderes først.
La leverandøren vurdere begrensning av filopplasting, filtrering av trafikk og andre serverinnstillinger. Slike tiltak erstatter ikke en sikkerhetsrettelse. Ved behov må tilgangen begrenses eller nettsiden stenges midlertidig til den er oppdatert.
Vi satte opp et filter i Caddy 2 som blokkerte forespørsler av typen multipart/form-data, som brukes ved blant annet filopplasting, før de nådde PHP.
Bare IP-adresser på en midlertidig tillatelsesliste fikk slippe gjennom.
Når en kunde logget inn i publiseringssystemet, la en egen innloggingskobling kundens IP-adresse på listen i noen timer. Kunden kunne dermed laste opp bilder og filer som vanlig.
Etter at tiden var ute, ble adressen automatisk fjernet. Ny innlogging ga en ny periode med tilgang.
Slik kunne vi begrense hvem som fikk sende opplastinger til nettsiden, samtidig som kundene kunne arbeide videre. Filteret reduserte eksponeringen for denne typen forespørsler, men var et midlertidig tiltak mens en varig oppdatering ble gjennomført.
Bekreft at oppdateringen er aktiv, og test skjemaer, innlogging, bestillinger og filopplasting der det er relevant. Undersøk logger og uventede endringer ved mistanke om angrep. En oppdatering fjerner ikke nødvendigvis skade fra et tidligere innbrudd.
Avklar ansvar for sikkerhetsvarsler, sikkerhetskopier og oppgraderinger. Lag en plan for eldre kode og PHP-versjoner som nærmer seg slutten av støtteperioden. Informer kunder om eventuelle driftsavbrudd og alternative kontaktmåter.
Faglig grunnlag: PHPs sikkerhetsvarsel og CERT-EUs anbefalinger.
EN TRYGGERE VEI VIDERE
Når du flytter til oss, ser vi på hele nettsiden. Vi finner ut hva som må oppdateres, hva vi kan ta vare på, og hvilke tiltak som passer for deg. Du får forklart løsningen og prisen før vi starter.
Vi planlegger flyttingen, tar backup og kontrollerer nettsiden før og etter overgangen. Vi sjekker blant annet at nettadressen peker riktig, og at kontaktskjemaer og andre viktige funksjoner virker.
Snakk med oss om flytting ↗PHP er en del av programvaren nettsiden kjører på. Vi oppdaterer den til en versjon med sikkerhetsrettelser. For eldre versjoner undersøker vi om det finnes en egnet sikkerhetsoppdatering.
Les den enkle forklaringen ↓Støtter ikke nettsiden din nyere PHP? Vi kan oppgradere og tilpasse selve nettsidekoden, slik at den kan fungere med en nyere versjon. Vi undersøker omfanget og tester viktige funksjoner før overgangen.
Få vurdert nettsiden din ↗Hvis oppgraderingen tar tid, kan vi begrense uønsket trafikk og filopplasting og skjerme nettsiden. Tiltakene reduserer risikoen mens vi jobber med en varig løsning.
Snakk med oss om sikring ↗Vi avtaler videre vedlikehold, backup og oppfølging. Du får en kontaktperson og en tydelig plan for det som må oppdateres videre.
Finn en løsning for din side ↗SPØRSMÅL OG SVAR OM PHP-SÅRBARHETEN
Det finnes ikke et sikkert tall for hvor mange nettsider som fortsatt mangler rettelsene. PHP er svært utbredt, men bruk av PHP betyr ikke at siden fortsatt er sårbar. W3Techs’ tall fra 24. oktober 2026 gir et beregnet anslag på rundt 48 % av målte PHP-nettsider som bruker eldre PHP enn 8.2. Det viser bruk av eldre versjoner, ikke hvor mange som er hacket, mangler en leverandørrettelse eller ikke kan oppgraderes.
Det avhenger av PHP-installasjonen og om sikkerhetsrettelsene er installert. Start med sjekken øverst på siden. Den leser versjonen nettsiden oppgir offentlig. Hvis resultatet er uklart eller viser en eldre versjon, bør leverandøren bekrefte status.
Den oppgitte versjonen er eldre enn de ordinære PHP-versjonene med rettelser for PHP2Shell. Be leverandøren oppdatere eller dokumentere at de nødvendige rettelsene er installert. Et rødt resultat er en oppfordring til å undersøke, ikke et bevis på at nettsiden er hacket.
Nettsiden oppgir en versjon som inneholder rettelsene for de to PHP2Shell-sårbarhetene. Resultatet forutsetter at den oppgitte versjonen stemmer. Det er ikke en kontroll av alle sikkerhetshull i nettsiden, publiseringssystemet eller tilleggene.
Mange leverandører skjuler versjonen, og en brannmur eller mellomtjener kan svare på vegne av nettsiden. Siden kan også være bygget uten PHP. Manglende versjon betyr derfor verken at siden er trygg eller sårbar. Be leverandøren bekrefte hvilken programvare som kjører og om den er oppdatert.
Rettelsene publisert 21. oktober 2026 finnes i PHP 8.2.35, 8.3.36, 8.4.27 og 8.5.12, og senere oppdateringer i de samme grenene. Enkelte leverandører har også sikkerhetsrettelser for eldre versjoner. Leverandøren må kunne bekrefte at begge sårbarhetene er rettet.
WordPress bruker PHP og kan derfor være berørt dersom PHP på serveren mangler rettelsene. Det samme gjelder andre PHP-baserte publiseringssystemer og egenutviklede nettsider. Å oppdatere WordPress eller tilleggene alene tetter ikke disse hullene i PHP.
Ja. At nettsiden ikke har et synlig opplastingsskjema, betyr ikke at serveren avviser slike forespørsler. Filtrering før forespørslene når PHP kan redusere eksponeringen, men erstatter ikke sikkerhetsrettelsene.
Nei. Noen nettsider ble stengt midlertidig som et sikkerhetstiltak mens leverandøren oppdaterte. Spør leverandøren hvorfor siden er stengt, hva som gjenstår, og når den kan åpnes igjen. Ved mistanke om innbrudd må hendelsen undersøkes i tillegg til at PHP oppdateres.
Da kan publiseringssystemet, tilleggene eller selve nettsidekoden trenge en oppgradering. Vi kan undersøke hva som må endres, avtale omfang og pris og teste viktige funksjoner før overgangen. Midlertidige tiltak kan være nødvendige mens arbeidet pågår.
PHP-prosjektets ordinære sikkerhetsstøtte for PHP 8.2 varer til 31. desember 2026. En nettside på denne grenen bør derfor ha en plan for overgang til en nyere støttet gren, selv om PHP2Shell-rettelsen allerede er installert.
Be om bekreftelse på hvilken PHP-versjon nettsiden bruker, at rettelsene for CVE-2026-109618 og CVE-2026-109619 er installert, og at viktige funksjoner er testet. Hvis oppdateringen ikke er mulig nå, be om en konkret tiltaksplan og avklaring av hvem som har ansvar for arbeidet.
Ja. Vi vurderer flytting, oppdatering av PHP, tilpasning av gammel nettsidekode og eventuell midlertidig sikring. Send oss nettadressen, så avklarer vi hva som trengs og gir et uforpliktende tilbud før arbeidet starter.
Faktagrunnlag kontrollert 24. oktober 2026: PHPs sikkerhetsvarsel · PHPs støttedatoer · W3Techs.
Fortell oss hva du har i dag og hva du trenger hjelp med. Vi finner en vei videre — enten du vil bytte leverandør eller få mer ut av nettsiden.
Akutt driftshendelse? Vakttelefon: 92 85 34 79